1704180777
小故事：语言与沟通——巴别塔的故事——选自《圣经》
1704180778
1704180779
大洪水劫后，天上出现了第一道彩虹，上帝走过来说：“我把彩虹放在云彩中，这就可作为我与大地立约的记号，我使云彩遮盖大地的时候，必有虹现在云彩中，我便纪念我与你们和各样有血肉的活物所立的约；水就不再泛滥，不再毁坏一切有血肉的活物了”。上帝以彩虹与地上的人们定下约定，不再用大洪水毁灭大地。此后，天下人都讲一样的语言，都有一样的口音。诺亚的子孙越来越多，遍布地面，于是向东迁移。在示拿地（古巴比伦附近），他们遇见一片平原，定居下来。
1704180780
1704180781
有一天，有人提出一个问题：我们怎么知道不会再有诺亚时代的洪水将我们淹死，就像淹死我们祖先那样？“这有彩虹为证啊”，有人回答道，“当我们看到彩虹，就会想起上帝的诺言，说他永远不会再用洪水毁灭世界。”“但是没有理由要把我们的将来以及我们子孙的前途寄托在彩虹上呀”，另一个人争辩说，“我们应该做点什么，以免洪水再发生”。于是，他们彼此商量说：“来吧，我们要做砖，把砖烧透了。”于是他们拿砖当石头，又拿石漆当灰泥。他们又说：“来吧，我们要建造一座城和一座塔，塔顶通天，为传扬我们的名，免得我们分散在全地上。”由于大家语言相通、同心协力，建成的巴比伦城繁华而美丽，高塔直插云霄，似乎要与天公一比高低。没想到此举惊动了上帝！上帝发觉自己的誓言受到了怀疑，上帝不允许人类怀疑自己的誓言，就像我们不喜欢别人怀疑自己那样，上帝决定惩罚这些忘记约定的人们，就像惩罚偷吃了禁果的亚当和夏娃一样。他看到人们这样齐心协力，统一强大，心想：如果人类真的修成宏伟的通天塔，那以后还有什么事干不成呢？一定得想办法阻止他们。
1704180782
1704180783
于是他悄悄地离开天国来到人间，改变并区别开了人类的语言，使他们因为语言不通而分散在各处，那座塔于是半途而废了。
1704180784
1704180785
1704180786
1704180787
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
[
上一页 ]
[ :1.704180777e+09 ]
[
下一页 ]