1704180789
精益求精：卓越的互联网产品设计与管理 2.5 需求管理
1704180790
1704180791
如同世界上大多数事物一样，需求也是动态的、有章可循的，并且有自己的个性。它的个性给我们的管理带来不少的麻烦，但是也是由于它总是在不停地变化，世界便充满了机会。抓住了需求就等于抓住了机会，不过前提条件是我们能够管理它。
1704180792
1704180793
需求必须被管理。需求是可分类的、变更的、需要组织和跟踪的，所以我们需要系统的方法对需求进行管理。需求管理主要分为几个方面：需求层次的标识与分类、需求文档的管理、需求跟踪与变更管理。之前我们详细说明了需求文档的构建，下面我们主要来介绍需求层次的标识与分类、需求跟踪与变更管理。
1704180794
1704180795
2.5.1 需求层次的标识与分类
1704180796
1704180797
需求是复杂的。任何一个系统都包括了上千或者上万个看似简单的需求，所以为了高效地管理如此大数量的需求，我们必须对需求进行标识，并将其进行分类。通常，我们只需要按照某种标识方案进行编号即可。下面我来介绍两个标识方案。
1704180798
1704180799
1.序列号法
1704180800
1704180801
最简单的方法是赋予每个需求一个唯一的序列号，例如SRS-13。当一个新的需求加入商业需求管理工具的数据库之后，这些管理工具就会为其分配一个序列号（许多这样的工具也支持层次化编号）。序列号的前缀代表了需求类型，例如SRS代表“软件需求说明”。由于序列号不能重用，所以把需求从数据库中删除时，并不释放其所占据的序列号，而新的需求只能得到下一个可用的序列号。这种简单的编号方法并不能提供任何相关需求在逻辑上或层次上的区别，而且需求的标识不能提供任何有关每个需求内容的信息。
1704180802
1704180803
2.层次化编码法
1704180804
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
[
上一页 ]
[ :1.704180788e+09 ]
[
下一页 ]