1704180805
这也许是最常用的方法。如果功能需求出现在软件需求规格说明的第3.2部分，那么它们将具有诸如3.2.4.3这样的标识号。标识号中的数字越多则表示该需求越详细，属于较低层次上的需求。即使在一个中型的软件需求规格说明中，这些标识号也会扩展到许多位数字，并且这些标识也不提供任何有关每个需求目的的信息。如果你要插入一个新的需求，那么该需求所在部分其后所有需求的序号将要增加。删除或移去一个需求，那么该需求所在部分其后所有需求的序号将要减少。但其他地方的引用将混乱，对于这种简单的层次化编号的改进方法是对需求中主要部分进行层次化编号，然后对于每个部分中的单一功能需求用一个简短文字代码加上一个序列号来识别。例如，软件需求规格说明可能包含“第3.2.5部分——编辑功能”，并将此部分编写成子模块文档，然后配置管理。
1704180806
1704180807
我们还需要将不同的功能分为功能性需求、数据需求、性能需求、安全需求或者其他需求，这样我们就可以从多个维度来对需求进行分类和管理。
1704180808
1704180809
此外，我们需要注意，对需求进行分类的目的是为了得到更好的管理和更高效的查询，是为了对需求变更管理和需求跟踪提供必要的支持，所以并没有任何一种标识和分类的方法是绝对完美的，每套方案都有赞成者和反对者，我们需要的方法是适合我们自身项目的方法，只要是高效的、能够减少管理成本的方法就是最好的方法。
1704180810
1704180811
1704180812
1704180813
1704180814
精益求精：卓越的互联网产品设计与管理 2.5.2 需求跟踪与变更管理
1704180815
1704180816
需求是变更的。在产品开发的任何阶段，当我们立足于满足当前用户需求的同时，需求已经发生了改变，就好比哲学认为人不可能跨入同一条河流一样。Macquarie认为，“由于需求变更而将项目沿着开发轨迹向回拖的下游开销总是增长的，且是呈指数增长的。改变一个刚创建的、还没和其他需求链接的需求仅仅是直接编辑的工作，而当同一个需求已经实现后再去改变它，就可能是令人望而却步的昂贵代价。”事实上，变更本身并不是问题，而如果没有进行变更管理却会带来很多麻烦。
1704180817
1704180818
任何原因都有可能导致需求的变更，比如市场竞争的变化、政策的变化、流行因素等。为了使产品开发能够适应需求的快速变更，我们需要有力的变更管理方案建立变更体系，包括变更请求流程、变更预测、变更影响分析以及变更实现流程。
1704180819
1704180820
每个业务变更流程必须有一套对应的变更说明文档，包括了规范化的业务用例文档、技术可能性分析说明文档、对项目整体影响的说明文档和变更成本文档。一旦需求变更的业务需求被接受，我们就需要将之结合到相关的业务模型，跟踪并管理实现情况。在很多大型项目中，建议使用需求管理工具帮助我们进行管理。
1704180821
1704180822
此外，为了保证需求文档到各种文档和模型的正确性和一致性，我们的需求必须可跟踪，至少应该保持用例需求和故障之间的可跟踪性。我们也可以使用需求跟踪矩阵的方法来进行需求的跟踪，其跟踪的条目可以是文本描述或者图形模型，我们可以在跟踪条目上添加外部链接，这样将使需求开发的全景图型更加清晰。
1704180823
1704180824
1704180825
1704180826
1704180828
精益求精：卓越的互联网产品设计与管理 第3章 以用户为中心的信息架构与快速原型设计
1704180829
1704180830
自从有了互联网，大量的信息就好像雪片一样蜂拥而至。我们痴迷于不断获得信息，但是过多的信息也在分散我们的注意力。虽然我们内心深处对有价值信息深深地渴望，但是我们的眼睛总是在抗拒。为什么科技的进步却带来了焦虑呢？因为在信息泛滥的互联网时代，并不缺乏好的信息，但很难找到它，我们寻找和识别的成本伴随着信息总量的增加而多倍增加。我们开始怀念在图书馆寻找信息的日子，面对琳琅满目的分类书籍我们倍感兴奋而不是焦虑，因为我们知道我们想看的书放在哪里。我们在互联网上总是有着类似的行为——努力挑选有价值的信息，但内心却充满了焦虑——我们想知道需要的信息是什么样子的、它躲在哪里，但是太多网站混乱的架构使我们抗拒。
1704180831
1704180832
没错，网站是信息堆砌的建筑，而信息架构就像是建筑的根基。为什么我们需要信息架构？因为每一个信息单元都渴望在网站建筑中找到自己的空间，而好的信息架构正是支持这种渴望的框架。信息构筑就好像设计建筑一样，这是一种思维的艺术。
1704180833
1704180834
Peter Morville和Louis Rosenfeld在他们的著作《Web信息架构》中提到：“就像建筑物一样，网站的架构也会影响我们的行为。”“每一种建筑都有其特定的用途。结构、设计、建造、装潢、住户以及地点都是塑造整体感受的主要因素，这些因素必须整合在一起。对于成功的建筑物而言，建筑物整体大于各部分之和。”
1704180835
1704180836
我们发现信息架构多么类似于建筑设计，它们都是空间的艺术，它们都是理性的。如果你意识到这点，我相信你的思维正在发生变化，我相信你对网站信息的构筑变得立体，而信息则不断填充到这个空间中。那么信息构筑又与建筑设计有什么不同呢？
1704180837
1704180838
从产品规划的角度看，信息架构的艺术在于构筑，而这种构筑不仅仅在于网站本体，而且也在于用户客体。一方面，对于主体，我们要组建一个合理的、能承载大量信息单元的、信息空间被充分利用架构；另一方面，对于客体，我们要有目的、有计划地去干预用户印象和用户行为。所以信息架构设计充满了模糊性和复杂性，我们必须依赖实验、数据、经验、直觉和创造力来构筑“信息建筑的艺术”。
1704180839
1704180840
从产品战略的角度看，信息架构是战略设计的艺术，我们不仅仅要求架构的灵活性、可扩展性，更需要具有预见未来的思维能力。我们总是只能设计相对稳定的架构，因为在互联网的世界里，唯一的不变就是变化，唯一的真理就是不断改进，“我们的需求一直在变，意外才是唯一法则。”
1704180841
1704180842
现在，你已经知道一些信息架构的来龙去脉了，现在马上进入信息架构之旅吧！
1704180843
1704180845
3.1 “决定性的工作”
1704180846
1704180847
六个星期过去了，Joe对自己的进度颇为满意，他的需求调研项目虽然没有完全让公司的产品管理走向科学化，但是在Mike的支持下，项目阻力减少了大半，并且他也从调研中获得了充分的数据——目前的产品规划存在很大问题。
1704180848
1704180849
“我是不是应该找Tim谈谈呢？”Joe希望知道自己的工作有多大成效，是不是被团队大多数人所支持。Tim是集团战略经理，他似乎从未提出过任何特别的观点，但是他总能够正确把握时局，提出恰当的想法。他总是用充满智慧的眼睛看着你，慢慢地听你说完，然后非常精练地表达他的观点，他的观点总是很有建设性，可惜他似乎并不怎么对他的观点负责，这是一个让人难以琢磨的家伙。Joe心想，如果能与Tim达成共识，那么就事半功倍了。几天后，Joe抓住了一个机会邀请到Tim,Tim也爽快地答应了Joe的邀请。他们随后集中讨论了调研和产品战略的问题，后来，事实证明这次谈话是卓有成效的……
1704180850
1704180851
Tim向Joe提出了一个建议：“Joe，你应该仔细想想这个问题：如果你的调研结论是正确的，那么我们的产品战略应该做多大的改变，我们将走多长的回头路？我想，一个好的产品并不是一天之内做出来的，不断地发现、不断地改进是非常好的。”
1704180852
1704180853
Joe耸了耸肩，摆出一个无奈的手势。Joe之前面临的问题只是如何开始一次研究，但是现在却要将整个规划的错误暴露出来，而他现在得非常小心谨慎，他并不知道其他高级经理怎么看这个问题。Joe面临的问题比之前更加复杂了，Joe似乎有些走神了。
1704180854
[
上一页 ]
[ :1.704180805e+09 ]
[
下一页 ]