软件开发之一、什么是需求（转贴）

老猫

软件需求

   对大多数人来说，若要建一幢数百万元的房子，他一定会与建房者详细讨论各种细节，他们都明白完工以后的修改会造成损失，以及变更细节的危害性。然而，涉及到软件开发，人们却变得“大大咧咧”起来。软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根”(Leffingwell 1997)。可许多组织仍在那些基本的项目功能上采用一些不合规范的方法，这样导致的后果便是一条鸿沟(期望差异)—开发者开发的与用户所想得到的软件存在着巨大期望差异。

   在软件工程中，所有的风险承担者(stakeholder)(这个词很有意思，原义是赌金保管者。我看过很多的翻译，有翻译成涉众的，也有的翻译成参与者的，但是我想他的主要意思就是和这个项目有密切相关利益的人)都感兴趣的就是需求分析阶段。这些风险承担者包括客户、用户、业务或需求分析员(负责收集客户需求并编写文档，以及负责客户与开发机构之间联系沟通的人)、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。这部分工作若处理好了，能开发出很出色的产品，同时会使客户感到满意，开发者也倍感满足、充实。若处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价值上的威胁。因为需求分析奠定了软件工程和项目管理的基础，所以所有风险承担者最好是采用有效的需求分析过程。

软件需求的定义

   IEEE软件工程标准词汇表(1997年)中定义需求为：

   (1)用户解决问题或达到目标所需的条件或权能(Capability)。
   (2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
   (3)一种反映上面(1)或(2)所描述的条件或权能的文档说明。

需求的层次

   下面这些定义是需求工程领域中常见术语的定义说明。

   软件需求包括三个不同的层次—业务需求、用户需求和功能需求—也包括非功能需求。业务需求( business requirement)反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例(use case)文档或方案脚本(scenario)说明中予以说明。功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性(feature)是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。软件需求各组成部分之间的关系如图所示。

   作为补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。

   值得注意的一点是，需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。

   Frederick Brooks在他1987年的经典的文章“No Silver Bullet：Essence and Accidents ofSoftware Engineering ”中充分说明了需求过程在软件项目中扮演的重要角色：

   开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难。

   为什么这么说呢，因为在大多数的软件系统中，最终用户可能都不清楚他的需求是什么，这是千真万确的。如果你的用户告诉你需求就是这些了，不要相信他，继续刨根问底，直到你们都筋疲力尽了。

   虽然听上去有些不可思议，但这是教训之谈，在我从事的项目之中，没有一个用户在软件接近完成的时候打电话对我说，我看了你们的软件，我想我必须改动一些地方。在那些日子中，我甚至得了一种电话铃音恐惧症。

需求风险

   下面列出了在做需求分析时一些很危险的做法，如果你发现你的一些做法与之相似，那么，给自己一些时间，好好思考一下，这些做法会对你的软件产生致命的影响。

   1. 无足够用户参与

   客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫，开发人员可能也不重视用户的参与。究其原因：一是因为与用户合作不如编写代码有意思；二是因为开发人员觉得已经明白用户的需求了。在某些情况下，与实际使用产品的用户直接接触很困难，而客户也不太明白自己的真正需求。但还是应让具有代表性的用户在项目早期直接参与到开发队伍中，并一同经历整个开发过程。

   最重要的就是用户必须要重视他的软件，必须让他明白：如果失败，他的损失最大(当然你的损失也不小，但这时候你必须让他重视这项工作)。如果用户不够重视，想办法解决，否则你就不用再继续了。

   2. 用户需求的不断增加

   在开发中若不断地补充需求，项目就越变越庞大以致超过其计划及预算范围。这使得问题更难解决。实际上，问题根源在于用户需求的改变和开发者对新需求所作的修改。要想把需求变更范围控制到最小，必须一开始就对项目视图、范围、目标、约束限制和成功标准给予明确说明，并将此说明作为评价需求变更和新特性的参照框架。说明中包括了对每种变更进行变更影响因素分析的变更控制过程，有助于所有风险承担者明白业务决策的合理性，即为何进行某些变更，相应消耗的时间、资源或特性上的折中。

   产品开发中不断延续的变更会使其整体结构日渐紊乱，补丁代码也使得整个程序难以理解和维护。插入补丁代码使模块违背强内聚、松耦合的设计原则，特别是如果项目配置管理工作不完善的话，收回变更和删除特性会带来问题。如果你尽早地区别这些可能带来变更的特性，你就能开发一个更为健壮的结构，并能更好地适应它。这样设计阶段需求变更不会直接导致补丁代码，同时也有利于减少因变更导致质量的下降。

   最糟糕的莫过于用户觉得如果不再加点什么功能就对不起自己。我曾经看过一个数据仓库的一期工程，在设计阶段没有很好的定义范围，当我向项目管理者提出这个问题的时候，他认为都已经说好了，合同上也写清楚了，并没有加以重视。可是最后，用户提出的修改意见已经远远超出了范围，项目时间也延长了一倍。整个的项目组成员疲惫不堪，可是却不断的接到用户投诉说项目失败。

   3. 模棱两可的需求

   模棱两可是需求规格说明中最为可怕的问题(Lawrence 1996)。它的一层含义是指诸多读者对需求说明产生了不同的理解；另一层含义是指单个读者能用不止一个方式来解释某个需求说明。

   模棱两可的需求会使不同的风险承担者产生不同的期望，它会使开发人员为错误问题而浪费时间，并且使测试者与开发者所期望的不一致。一位系统测试人员曾告诉我，她所在的测试组经常对需求理解有误，以致不得不重写许多测试用例并重做许多测试。

   模棱两可的需求带来不可避免的后果便是返工—重做一些你认为已做好的事情。返工会耗费开发总费用的40%，而70%～85%的重做是由于需求方面的错误所导致的(leffingwell 1997)。想像一下如果你能减少一半的返工会是怎样的情况？你能更快地开发出产品，在同样的时间内开发更多、更好的产品，甚至能偶尔回家休息休息。

   处理模棱两可需求的一种方法是组织好负责从不同角度审查需求的队伍。仅仅简单浏览一下需求文档是不能解决模棱两可问题的。如果不同的评审者从不同的角度对需求说明给予解释，但每个评审人员都真正了解需求文档，这样二义性就不会直到项目后期才被发现，那时再发现的话会使得更正代价很大。

   4. 不必要的特性

   “画蛇添足”是指开发人员力图增加一些“用户欣赏”但需求规格说明中并未涉及的新功能。经常发生的情况是用户并不认为这些功能性很有用，以致在其上耗费的努力“白搭”了。

   开发人员应当为客户构思方案并为他们提供一些具有创新意识的思路，具体提供哪些功能要在客户所需与开发人员在允许时限内的技术可行性之间求得平衡，开发人员应努力使功能简单易用，而不要未经客户同意，擅自脱离客户要求，自作主张。

   同样，客户有时也可能要求一些看上去很“酷”，但缺乏实用价值的功能，而实现这些功能只能徒耗时间和成本。为了将“画蛇添足”的危害尽量减小，应确信：你明白为什么要包括这些功能，以及这些功能的“来龙去脉”，这样使得需求分析过程始终是注重那些能使用户完成他们业务任务的核心功能。

   时刻记住：软件成功的标准是是否解决用户的问题，而不是它有多Cool的功能。

   5. 过于精简的规格说明

   有时，客户并不明白需求分析有如此重要，于是只作一份简略之至的规格说明，仅涉及了产品概念上的内容，然后让开发人员在项目进展中去完善，结果很可能出现的是开发人员先建立产品的结构之后再完成需求说明。这种方法可能适合于尖端研究性的产品或需求本身就十分灵活的情况(McConnell 1996)，不过商业应用大多都不是这种情况。在大多数情况下，这会给开发人员带来挫折(使他们在不正确的假设前提和极其有限的指导下工作)，也会给客户带来烦恼(他们无法得到他们所设想的产品)。

   6. 忽略了用户分类

   大多数产品是由不同的人使用其不同的特性，使用频繁程度也有所差异，使用者受教育程度和经验水平也不尽相同。如果你不能在项目早期就针对所有这些主要用户进行分类的话，必然导致有的用户对产品感到失望。例如，菜单驱动操作对高级用户太低效了，但含义不清的命令和快捷键又会使不熟练的用户感到困难。

   7. 不准确的计划

   “上述是我对新产品的看法，好，现在你能告诉我你什么时候能完成吗？”许多开发人员都遇到这种难题。对需求分析缺乏理解会导致过分乐观的估计，而当不可避免的超支发生时，会带来颇多麻烦。据报道，导致需求过程中软件成本估计极不准确的原因主要有以下五点：频繁的需求变更、遗漏的需求、与用户交流不够、质量低下的需求规格说明和不完善的需求分析(Davis 1995)。

   对不准确的要求所提问题的正确响应是“等我真正明白你的需求时，我就会来告诉你”。基于不充分信息和未经深思的对需求不成熟的估计很容易为一些因素左右。要作出估计时，最好还是给出一个范围(如最好的情况下，很可能的，最坏情况下)或一个可信赖的程度(我有9 0 %的把握，我能在8周内完成)。未经准备的估计通常是作为一种猜测给出的，听者却认为是一种承诺。因此我们要尽力给出可达到的目标并坚持完成它。

什么是优秀的需求

   讨论软件需求的文章有很多，对于需求的标准也不尽相同，这里我想用NASA的软件开发过程中的概念，软件需求过程的标准是：清楚(Clear)、完整(Complete)、一致(Consistent)、可测试(Testable)，此外还有其他的概念，如可跟踪的、可修改的等等。

   清楚：目前大多数的需求分析采用的仍然是自然语言（因为如果采用形式化语言的话，和用户的沟通将成为一个大问题，这意味着客户在开发软件之前必须先进行形式化语言培训，这是不现实的）。自然语言对需求分析最大的弊病就是它的二义性。所以我们不得不对需求分析中采用的语言做某些限制。例如尽量采用主语＋动作的简单表达方式。说白了，需求分析中的描述让人看上去像是刚学习写作的小孩子就对了，千万不要采用疑问句、修饰这些华丽的表达方式。

   除了语言的二义性之外，主意不要使用行话，就是计算机术语。需求分析最重要的是和用户沟通，可是用户多半不是计算机的专业人士，如果在需求分析中使用了行话，就会造成用户理解上的困难。

   打个比方，如果你要做一个银行的信用卡系统，你就可以这样描述软件需求：银行的卡部管理信用卡，每张信用卡只属于一个帐户。信用卡有卡号、余额。一张信用卡有多笔的交易记录。

   完整：再也没有什么比软件开发接近完成是发现遗漏了一项需求更糟的事情了。需求的完整性是非常非常重要的，想象一下遗漏需求而不得不返工，这简直就是恶梦。可是令人遗憾的是，需求的遗漏是很经常发生的事情，不仅仅是你的问题，更多的问题发生在用户那里，他们不知道该做些什么。要做到需求的完整性是很艰难的一件事情，它涉及到需求分析过程的各方各面，贯穿了整个过程，从最初的计划制定到最后的需求评审。至于完整性的详细讨论，我们会在下面的章节中讨论，现在你只需要拼命的想象缺乏完整性的坏处，直到你出了一身的冷汗。出了吗？好，那我们继续。

   一致：一致性也是一个比较大的概念，很难用几句话讲清楚。还记得我们在开始的时候提到的需求的层次吗？简单的来说，就是用户需求必须和业务需求一致，功能需求必须和用户需求一致。严格的遵守不同层次间的一致性关系，就可以保证最后开发出来的软件系统不会偏离最初的实现目标。在实现过程中，我们还必须把一致性关系细化。比如说用户需求不能超出先前指定的范围。

   可测试：大家觉得一个项目的测试从什么时候开始呢？有人说从编码完成后开始。更清楚一点的说是编码的时候同时进行单元测试，编码完成后进行系统测试。这些都没有错。但是实际上测试是从需求分析过程就开始了。需求分析是测试计划的输入和参照。这就要求需求分析是可测试的。什么是可测试呢？“我们要用新的系统完成报表自动化处理”，你觉得这个需求是可测试的吗？当然不是，报表包括哪些？自动化处理的标准是什么？这些在需求中都没有说明。因此这项需求是无法测试的，就是不具有可测试性。说到这里，大家可能就会明白之前的需求的几项标准都是为了保证需求的可测试性的。事实就是这样，只有系统的所有需求是可以被测试的，才能够保证软件始终围绕着用户的需要，保证软件系统是成功的。大家真正在应用一些科学的方法的时候也应该记住，任何的方法都是为了保证软件的成功，不要偏离这个目标，千万不要走火入魔了，呵呵，很容易的。

5M

哈哈，不错，可从没想过这些，只想到了MONEY.

老猫

前些日子有一个朋友向我要一份需求的标准文档，因为他现在正在负责一个项目。我对
他说，我的需求文档只适合我用，并不适合你用。如果你是真的想在开发过程中引入科学的
管理方法，静下心来，认真的学习需求的方法论，仔细的思考适合你们自身的方法。如果你
只是需要一份好看的模版来哄哄Boss的话，那你就随便去找一份文档来修改一下就行了，保
证糊弄得住人。最后我的朋友毅然的找了一份漂亮的文档走了。

   朋友走后我思考了很久，中国目前有很多的软件公司都很有实力，可是他们在管理方法
上却很成问题。上半年在业界炒得沸沸扬扬的CMM是个什么东西呢？说穿了，就是一套适合
软件行业的管理方法。这套管理方法并不是说你花了大堆的票子去过了CMM的评估或是购买
了Rational公司的什么产品，而是在于你是不是真的理解了里面的管理精髓。前些日子看一
篇报道联想实施ERP系统的文章，里面一句很不起眼的话给了我很大的感触。它说，联想在
实施ERP之前，虽然也有大量的管理规范，但都是空谈的管理，公司主要还是靠“人治”。
而我们现在很多的软件公司还是处于“人治”。“人治”的后果是很严重的，必将导致你的
软件企业成本居高不下，管理上不传，下不达，企业无法快速发展。软件行业历来以利润高
出名，利润是高，你想想软件的边际成本才多少（拷贝一份软件需要多少钱？）。可是中国
的软件行业却做的不好。看看我们的台湾同胞们，虽然他们在软件平台的研究方面并不出
色，但是在软件应用水平上是很了不起的。当然，台湾有他的历史原因：深受美国文化影
响，属于美国制造外包的主要地区。

   上面说了一大堆的废话，我们还是回到我们的需求上面来。

沟通是一切

   需求是一个过程，一个在软件生命周期中很重要的过程。在上一篇中，我们讨论了需求
的层次、需求的风险、需求的特点。而在这么多需求要素之上的要素只有一个：沟通。沟通
是什么，说小了是需求过程的重要技巧，说大了是软件企业的生命线。一个项目失败的原因
有很多，而绝大多数都可以总结到沟通不畅。需求过程中充满了沟通：需求分析员和用户的
沟通，不同的用户之间的沟通，需求分析员和需求审核人员的沟通，项目经理和需求分析员
的沟通。沟通到一个什么程度，是需求成功与否的标志。

   曾经和几个老同学聊天的时候说起他们去用户哪里做需求调研，用户报来一堆资料，和
他们聊了半天，他们就回去开始设计、编码。我说你后面肯定吃苦头了。果不其然，项目返
工的时间差不多等于整个项目的时间。这太可怕了，意味着这个项目企业极可能亏本。为什
么会这样呢？项目好比一座大楼，如果设计师连大楼要盖多少层都不清楚，那你说盖出来的
会是个什么东西。

   《软件需求》一书中提到了一个很有意思的概念：软件客户需求义务和权利

   优秀的软件产品是建立在优秀的需求基础之上的。而高质量的需求来源于客户与开发人
员之间有效的交流与合作。通常，开发人员与客户或客户代理人，如市场人员间的关系反而
会成为一种对立关系。双方的管理者都只想自己的利益而搁置用户提供的需求从而产生摩
擦，在这种情况下，不会给双方带来一点益处。

   只有当双方参与者都明白要成功自己需要什么，同时也应知道要成功合作方需要什么
时，才能建立起一种合作关系。由于项目压力与日渐增，所有风险承担者有着一个共同的目
标这一点容易被遗忘。其实大家都想开发出一个既能实现商业价值，又能满足用户需要，还
能使开发者感到满足的优秀软件产品。

   软件客户需求权利书列出了十条关于客户在项目需求工程实施中与分析人员、开发人员
交流时的合法要求。每一项权利都对应着软件开发人员、分析人员的义务。而软件客户需求
义务书也列出了十条关于客户在需求过程中应承担的义务。如果愿意，可以将其作为开发人
员的权利书。

   软件客户需求权利书

   1. 要求分析人员使用符合客户语言习惯的表达。
   2. 要求分析人员了解客户系统的业务及目标。
   3. 要求分析人员组织需求获取期间所介绍的信息，并编写软件需求规格说明。
   4. 要求开发人员对需求过程中所产生的工作结果进行解释说明。
   5. 要求开发人员在整个交流过程中保持和维护一种合作的职业态度。
   6. 要求开发人员对产品的实现及需求都要提供建议，拿出主意。
   7. 描述产品使其具有易用、好用的特性。
   8. 可以调整需求，允许重用已有的软件组件。
   9. 当需要对需求进行变更时，对成本、影响、得失（trade-off）有个真实可信的评
估。
   10. 获得满足客户功能和质量要求的系统，并且这些要求是开发人员同意的。

   软件客户需求义务书

   1. 给分析人员讲解业务及说明业务方面的术语等专业问题。
   2. 抽出时间清楚地说明需求并不断完善。
   3. 当说明系统需求时，力求准确详细。
   4. 需要时要及时对需求做出决策。
   5. 要尊重开发人员的成本估算和对需求的可行性分析。
   6. 对单项需求、系统特性或使用实例划分优先级。
   7. 评审需求文档和原型。
   8. 一旦知道要对项目需求进行变更，要马上与开发人员联系。
   9. 在要求需求变更时，应遵照开发组织确定的工作过程来处理。
   10. 尊重需求工程中开发人员采用的流程（过程）。

   需求权利和义务规定了客户和开发者双方应该做些什么，双方共同出力，确保需求过程
的有序进行。不过，大多数的软件公司一般都把“客户是上帝”这句话贯彻的很好，客户有
什么样的要求，软件公司就做什么样的修改，最终损害的是客户和自己双方的利益。一次，
我和一个小软件企业的技术总监聊起这方面的事情，请教他的做法。他在经历了几次销售人
员随意答应客户要求的痛苦之后，决定亲自出动，在和客户接触的过程中掌握主动权，判断
客户是不是一个“好”客户，再决定做不做这个软件。实施了一段时间后，发现效果非常的
好，成本大幅度下降，客户也很满意。软件开发过程中软件企业和客户是一对合作者，一荣
俱荣，一损俱损。要达到双方共赢的局面，只能靠充分的沟通。

需求分析和需求管理

   需求的过程包括了两个过程，需求管理和需求分析。如同一个公司开展业务离不开管理
一样，脱离了需求管理的需求过程很难做到顺利的完成需求过程。当然，并不是所有的软件
公司都没有需求管理，例如安排需求的时间也是需求管理的一方面，大多数的软件公司都没
有一个科学的、

   任何活动都离不开管理，需求过程也不例外。需求过程的活动分为需求管理和需求分析
两种。大多数人说不清楚需求管理和需求分析的差别，但是他们在进行需求过程的时候已经
不知不觉的在开展需求管理和需求分析两种活动了。这种行为就有点像一些小企业主，缺乏
科学的、系统的管理知识，但你却不能说他不懂管理，因为他有大量的实践经验。同样的，
一些不够成熟的软件企业在进行需求分析的时候，主要还是靠经验，并没有一个经过验证的
方法。

   需求分析活动包括对一个软件项目需求的获取、分析、规格说明及验证。典型需求分析
的结果是软件需求规格说明（System Requirements Specifications）及相关分析模型。经
评审批准，这些文档就定义了开发工作的需求基线（baseline）。这个基线在客户和开发人
员之间就构筑了计划产品功能需求和非功能需求的一个约定（agreement）。工程项目可能
会有其它的约定，例如可交付性、约束条件、进度安排、预算及合同约定等。但这些并不是
需求过程主要考虑的因素。

   需求约定是需求开发和需求管理之间的桥梁，需求管理包括在工程进展过程中维持需求
约定集成性和精确性的所有活动，如图所示。需求管理强调：

   1、控制对需求基线的变动。
   2、保持项目计划与需求一致。
   3、控制单个需求和需求文档的版本情况。
   4、管理需求和联系链之间的联系或管理单个需求和其它项目可交付品之间的依赖关
系。
   5、跟踪基线中需求的状态。

   和任何的管理活动一样，需求管理的目的也是为了确保需求分析活动按照既定方针执
行。

CMM

   CMM（capability Maturity Model）过程成熟度模型，这个概念是由位于宾夕法尼亚洲
匹兹堡市的卡内基梅隆大学所属的软件工程研究所提出的。CMM是在软件开发机构中被广泛
地用来指导过程改进工作的模型。该方法描述了软件处理能力的五个成熟级别。处于一级的
组织典型地以非正式的方式管理项目进度，要获得成功，主要依靠天才从业者和管理者的英
雄史诗般的奋斗。处于更高成熟度级别的组织把具有创造性、训练有素的员工同软件工程和
项目管理过程结合起来，将持续不断地获得成功。

   过程能力成熟度模型对需求管理是一个有用的指导。为达到软件过程能力成熟度模型的
第二级，组织必须具有在软件开发与管理的六个关键过程域（key process areas，KPA）以
展示达到目标的能力。需求管理是其中之一，它的目标如下：

   1) 把软件需求建立一个基线供软件工程和管理使用。
   2) 软件计划，产品和活动同软件需求保持一致。

   需求管理的关键过程领域不涉及收集和分析项目需求。而是假定已收集了软件需求或已
由更高一级的系统给定了需求。一旦需求到手且文档化了，软件开发团队和有关的团队（例
如质量保证和测试）需要评审文档。发现问题应与客户或其它需求源协商解决，软件开发计
划是基于已确认的需求。

   开发团队在向客户、市场部或经理们作出承诺（commitment）之前，应该确认需求和确
认约束条件、风险、偶然因素、假定条件。也许不得不面对由于技术因素或进度原因而不现
实的需求作出承诺。但是，决不要承诺任何无法实现的事。

   关键处理领域同样建议通过版本控制和变更控制来管理需求文档。版本控制确保随时能
知道在开发和计划中正在使用的需求的版本情况。变更控制提供了支配下的规范的方式来统
一需求变更，并且基于业务和技术的因素来同意或反对建议的变更。当在开发中修改、增
加、减少需求时，软件开发计划应该随时更新以与新的需求保持一致。不反映现实的计划于
事无补。

   必需要强调的一点是，CMM只是推荐方法，并没有说你一定要采用这种方法。仔细的分
析自身的特点，总结适合自身的方法。但是CMM提到的两个目标却是任何需求活动都应该追
寻的目标。事实上，不但各个企业采用的方法不同，即便是企业内部，对于不同的项目，也
不存在一个标准的模式。每个项目都有自身的特点，不能强制性的要求他们采用同样的模
板。所以在项目开始的时候，一般在项目可行性论证的时候，管理小组就会根据本个项目的
特性制定项目计划和需求计划。

需求管理步骤

   开发组织应该定义项目组执行管理他们需求的步骤。文档化编写这些步骤能使组织成员
持续有效地进行必要的项目活动。请考虑选择以下主题：

   1、用于控制各种需求文档和单个需求版本的工具、技术和习惯做法。
   2、建议、处理、协商、通告新的需求和变更给有关的功能域的方法。
   3、如何制定需求基线。
   4、将使用的需求状态，并且是谁允许作出的变更。
   5、需求状态跟踪和报告过程。
   6、分析已建议变动的影响应遵循的步骤。
   7、在何种情况下需求变更将会怎样影响项目计划和约定。

   你可以在一个文档中包含上面所有的信息。或者，你可能喜欢专题分述，例如分成变更
控制过程，影响分析过程，状态跟踪过程。这些过程可能在多个项目中都有用，因为他们反
映每个项目所应遵循的公共功能。

   需求控制的工具有很多，你可以使用专业的Rational公司的RequisistPro，也可以使用
一些可视化的数据库管理工具，甚至你可以只是使用目录结构。用什么样的工具并不是特别
重要，关键还是在于人。上面已经说过，需求的管理最重要的（关键过程域）就是版本控制
和变更管理。这两个方面是密切相关的。需要版本控制的一个重要因素就是需求在不断的变
化。

文档的海洋

   虽然到现在还没有提到任何的具体文档，但是需求过程的产品中大都是文档。文档的产
生目的是为了项目能够被控制。如果为了实现控制项目的目的，而文档却陷入了不可控制的
境地，那就是一条歧途了。想象起来是很可笑，但是这个错误是确实存在的。往往有一些狂
热的技术分子，为了追求完美的实施项目管理，实施了过多的文档，可是这个项目本身并没
有想象的那么庞大。到了最后，是由于文档的失控导致了项目的失控。即便是以完善著称的
RUP（Rational Unifined Process）也并不提倡制作过多的文档。控制好你的计划，使之适
合你的项目。需求分析人员应该专注于需求的获取和分析，而不是写出漂亮的文档。当然，
如果用户有这方面的要求的话，你是应当重视的。

需求管理活动的积累材料

   变更控制过程变更控制过程能够减少因无休止、失控的需求变更引起的混乱。它明确了
一种方法来提出、协商、评估一个新的需求或在已有需求上的一项变更。变更控制通常需要
问题跟踪工具的支持，但请铭记工具并不能替代过程。

   变更控制委员会过程变更控制委员会(CCB)是由风险承担者的主要成员组成的，对提出
的需求变更决定执行哪一项，拒绝哪一项，以及在各产品发行版本中包括哪些变更。CCB过
程描述了变更控制委员会的组成及操作过程。CCB的主要活动是对提出的变更进行影响分
析，为每项变更作出决定，并且告知那些将受到影响的人。

   需求变更影响分析清单和模板估计提出的需求变更的成本费用和影响是决定是否执行变
更的重要步骤。影响分析能帮助CCB作出正确的决定。影响分析清单包括许多自问自答型的
问题，如：要考虑到可能的任务、边界影响、实施所确定的变更引起的相关的潜在风险。一
张参与人员工作表可以作为估计任务工作量的简单方法，从这里就能明白确认变更的复杂
性。

   需求状态跟踪过程需求管理包括监控和报告每项功能需求的状态和状态改变的条件。你
需要一个数据库或一种商业需求管理工具来跟踪一个复杂系统中大量的需求状态。此过程也
描述了当你随时查看收集到的需求状态时输出的报告格式。

   需求跟踪能力矩阵模板需求跟踪能力矩阵列出了SRS中的所有功能需求及相应的设计模
块，源文件和实施需求的过程，还有验证需求实施正确性的测试用例。跟踪能力矩阵应该也
可以指出对应的上一层用户需求或系统需求。


需求分析

   需求分析可分为：问题获取（elicitation）、分析(analysis)、编写规格说明
（specification）和验证（verification）四个阶段（Thayer and Dorfman 1997）。这些
子项包括软件类产品中需求收集、评价、编写文档等所有活动。需求开发活动包括以下几个
方面：

   1、确定产品所期望的用户类。
   2、获取每个用户类的需求。
   3、了解实际用户任务和目标以及这些任务所支持的业务需求。
   4、分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议
解决方法和附加信息。
   5、将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。
   6、了解相关质量属性的重要性。
   7、商讨实施优先级的划分。
   8、将所收集的用户需求编写成规格说明和模型。
   9、评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接
受说明之前将问题都弄清楚。

需求开发过程的积累材料

   1) 项目视图与范围模板项目的视图与范围文档明确了项目的概念性功能，并提供了确
定需求优先级和变更的参考。需求视图与范围文档是简明扼要的、高度概括的新项目业务需
求说明。用统一的方式编写项目视图与范围文档能确保在项目进行过程中作决定时能考虑到
所有应考虑的情况。

   2) 需求开发过程该过程介绍了怎样确定客户及从客户那里获取需求的技术。也描述了
项目。需要创建的各种需求文档和分析模型。这个过程还指明了每项需求包含的信息种类，
比如：优先级、预计的稳定性或计划发行版本号。同时还应指明需求分析及需求文档检验需
要执行的步骤以及确认软件需求规格说明和建立需求基线的步骤。

   3) 需求分配过程把高层的产品需求分成若干特定子系统是非常重要的，尤其是当开发
的系统既含有软件又含有硬件或是包括多个子系统的软件产品时尤为重要（Nelsen
1990）。需求分配是在系统级需求完成和系统体系结构确定后才进行的，这个过程包含的信
息是怎样执行分配以确保功能分配到合适的系统组件中，同时也说明分配的需求怎样才能追
溯回它们的上两级系统需求以及在其它子系统中的相关需求。

   4) 使用实例模板使用实例模板提供了一种把每项用户希望使用软件系统完成的任务编
写成文档的标准方法。使用实例定义包括一个简要的任务介绍，必须处理的异常情况的说明
和描述用户任务特点的附加信息。使用实例可作为软件需求规格说明中一条独立的功能需
求。另外，你也可将使用实例与SRS模板合并为一个文档，既包括产品的使用实例，又包括
软件功能需求。

   5) 软件需求规格说明模板软件需求规格说明模板提供了一种组织功能需求和非功能需
求的结构化方法。采用标准的SRS模板将有助于创建统一且高质量的需求文档。可能要采用
多个模板以适应组织承担的不同类型和规模的项目。这样可减少因一种“万能”模板并不适
合你的项目所带来的障碍。

   6) 需求优先级确定过程，此时为满足进度时限要求，计划的功能不得不放弃掉。我们
需要知道哪些性能、使用实例或功能需求的优先级最低，以便在任何阶段，我们都可适当缩
减范围。
   7) SRS和使用实例审查清单对需求文档的正式审查是保证软件质量的一项重要措施。审
查清单指出在需求文档中发现的一些错误。在审查会议的准备中运用清单将使你的注意力集
中到通常存在问题的地方。

老猫

好象没人看哦?!真的没人需要我就不贴了!!!
:((

carechen

有人看，贴。

老猫

需求分析
   在具体的研究需求分析之前，我们先了解一下软件工程这个概念。软件工程分为三个层
次，过程层、方法层、工具层。在最基础的过程层，最重要的就是一组被称为关键过程区域
（KPAs）的框架（KPA的概念在讨论CMM的书中有详细的概念说明）。关键过程区域构成了软
件项目的管理控制的基础，并且确立了上下文各区域的关系，其中规定了技术方法的采用、
工程产品的，模型、文档、数据、报告、表格等，等的产生、里程碑的建立、质量的保证及
变化的适当管理。方法层主要是过程在技术上的实现。它解决的问题是如何做。软件工程方
法涵盖了一系列的任务：需求分析、设计、编程、测试、维护。同时他还包括了一组基本原
则，控制了每一个的关键过程区域。工具层就很好理解了，他对过程层和方法层提供了自动
和半自动的支持。这些辅助工具就称为CASE。

   可以看到需求分析的位置，但是事实上需求分析是跨越了软件工程的三个层次的。这一
点是和其他的过程是一样的。当然我们这里比较重点强调的是在软件工程的方法层，同时也
涉及到一些过程层的思想，至于工具层则不再我们的讨论之列，但是会提到一些很适合在需
求分析时应用的工具，诸如Word、Excel、Visio等。

方法

   需求分析都包括了哪些方法呢？这里列举出在《需求分析》一书中推荐的一些方法，

   1) 绘制系统关联图，这种关联图是用于定义系统与系统外部实体间的界限和接口的简
单模型。同时它也明确了通过接口的信息流和物质流。

   2) 创建用户接口原型，当开发人员或用户不能确定需求时，开发一个用户接口原型—
一个可能的局部实现—这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型
将使项目参与者能更好地相互理解所要解决的问题。注意要找出需求文档与原型之间所有的
冲突之处。

   3) 分析需求可行性，在允许的成本、性能要求下，分析每项需求实施的可行性，明确
与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。

   4) 确定需求的优先级别，应用分析方法来确定使用实例、产品特性或单项需求实现的
优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时，
在特定的版本中加入每一项变更，并在那个版本计划中作出需要的变更。

   5) 为需求建立模型，需求的图形分析模型是软件需求规格说明极好的补充说明。它们
能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的
模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。

   6) 创建数据字典，数据字典是对系统用到的所有数据项和结构的定义，以确保开发人
员使用统一的数据定义。在需求阶段，数据字典至少应定义客户数据项以确保客户与开发小
组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。

   7) 使用质量功能调配，（QFD）是一种高级系统技术，它将产品特性、属性与对客户的
重要性联系起来。该技术提供了一种分析方法以明确那些是客户最为关注的特性。QFD将需
求分为三类：期望需求，即客户或许并未提及，但如若缺少会让他们感到不满意；普通需
求；兴奋需求，即实现了会给客户带去惊喜，但若未实现也不会受到责备（Zultner
1993;Pardee 1996）。

   记住一点，不要试图在你的项目中把这些方法都用上去，四个现代化并不是一夜就可以
实现的。同样，尝试着使用你认为对你很有帮助的方法，确实收到效果之后，在考虑继续学
习方法。因为上面提到的都是需求分析的大方法，事实上还有很多很多的方法可以采用，例
如，采用SRS模板、指明需求的来源、为每项需求注上标号、记录业务规范、创建需求跟踪
能力矩阵、审查需求文档、以需求为依据编写测试用例、编写用户手册、确定合格的标准。

业务建模

   很多人都没有意识到业务需求阶段应该做些什么事情，实际上业务建模是最重要的一件
事情。不要觉得业务建模这个词很深奥，让人模不着头脑。其实所有做过需求分析的人都做
过业务建模，比如你了解企业的运作模式就是一种你脑海中的业务建模。但是大多数人都没
有科学的、系统的、文档化的做过业务建模。

   业务建模的目的在于：

   了解目标组织（将要在其中部署系统的组织）的结构及机制。
   了解目标组织中当前存在的问题并确定改进的可能性。
   确保客户、最终用户和开发人员就目标组织达成共识。
   导出支持目标组织所需的业务需求。

   上面的话是不是很抽象呢，其实没有什么复杂的：人和电脑是完全不同的思想（思维方
式）。所以，原先适合人的业务流程对于计算机来说可不一定合适的，为了最大限度的利用
计算机，必须要了解原先的业务流程并对此加易改造（流程自动化），当然这些动作需要得
到用户的许可。有些人认为说只有ERP这种大系统才需要对业务流程进行重组，但是实际
上，不论是部门级的MIS系统，还是社会级的电子商务系统，都需要对业务流程进行改造，
所不同的只是改造的程度。

   业务建模很重要的一点是在分析企业流程的同时分析出基础企业对象（Common
Business Object）（这个词我翻译的不好，如果大家有更好的翻译，请告诉我）。任何企
业都有最基础的一些元素，例如银行的CBO就有帐户，制造业的CBO就有订单等。有一次我的
一个在企业应用方面研究多年的朋友告诉我一个秘诀，他说，企业的CBO无非是4个：客户、
员工、产品和供应商（银行的供应商应该称为同业）。其他的所有CBO都是在这四个CBO的基
础上发展起来的。比如说CBO中客户和产品是多对多的关系，根据关系数据的理论，任何多
对多的关系都可以拆分成多个一对多或一对一的关系。你就可以在这两个类之间引入订单
类，客户和订单之间是一对多，订单和产品之间又是一对多，这样一个多对多的关系就拆分
成两个一对多的关系，而新的订单类也就顺理成章的产生了。在订单类产生时，你可能还会
加入一个关联类：业务员类。而业务员类又是从员工类继承下来的。所以呢，企业的四种
CBO通过不同的组合，不同的关系，能够形成企业运作的许许多多的CBO。

   CBO是做业务建模的基础，在此基础上，通过评估业务状态，说明当前业务，确定业务
流程，改进业务流程的定义，设计业务流程实现，改进角色和职责，研究流程自动化，开发
领域模型等一系列在RUP中定义的工作流程实现业务建模的目标。

需求获取

   需求获取(requirement elicitation)是需求工程的主体。对于所建议的软件产品，获
取需求是一个确定和理解不同用户类的需要和限制的过程。获取用户需求位于软件需求三个
层次的中间一层。业务需求决定用户需求，它描述了用户利用系统需要完成的任务。从这些
任务中，分析者能获得用于描述系统活动的特定的软件功能需求，这些系统活动有助于用户
执行他们的任务。

   需求获取是在问题及其最终解决方案之间架设桥梁的第一步。获取需求的一个必不可少
的结果是对项目中描述的客户需求的普遍理解。一旦理解了需求，分析者、开发者和客户就
能探索出描述这些需求的多种解决方案。参与需求获取者只有在他们理解了问题之后才能开
始设计系统，否则，对需求定义的任何改进，设计上都必须大量的返工。把需求获取集中在
用户任务上—而不是集中在用户接口上—有助于防止开发组由于草率处理设计问题而造成的
失误。

   需求获取、分析、编写需求规格说明和验证并不遵循线性的顺序，这些活动是相互隔
开、增量和反复的。当你和客户合作时，你就将会问一些问题，并且取得他们所提供的信息
（需求获取）。同时，你将处理这些信息以理解它们，并把它们分成不同的类别，还要把客
户需求同可能的软件需求相联系（分析）。然后，你可以使客户信息结构化，并编写成文档
和示意图（说明）。下一步，就可以让客户代表评审文档并纠正存在的错误（验证）。这四
个过程贯穿着需求分析的整个阶段。

   需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。需求获取
只有通过有效的客户—开发者的合作才能成功。分析者必须建立一个对问题进行彻底探讨的
环境，而这些问题与产品有关。为了方便清晰地进行交流，就要列出重要的小组，而不是假
想所有的参与者都持有相同的看法。对需求问题的全面考察需要一种技术，利用这种技术不
但考虑了问题的功能需求方面，还可讨论项目的非功能需求。确定用户已经理解：对于某些
功能的讨论并不意味着即将在产品中实现它。对于想到的需求必须集中处理并设定优先级，
以避免一个不能带来任何益处的无限大的项目。

   需求获取是一个需要高度合作的活动，而并不是客户所说的需求的简单誊本。作为一个
分析者，你必须透过客户所提出的表面需求理解他们的真正需求。询问一个可扩充（open-
ended）的问题有助于你更好地理解用户目前的业务过程并且知道新系统如何帮助或改进他
们的工作。调查用户任务可能遇到的变更，或者用户需要使用系统其它可能的方式。想像你
自己在学习用户的工作，你需要完成什么任务？你有什么问题？从这一角度来指导需求的开
发和利用。

   还有，探讨例外的情况：什么会妨碍用户顺利完成任务？对系统错误情况的反映，用户
是如何想的？询问问题时，以“还有什么能” ,”当?时，将会发生什么”“你有没有曾经
想过” ,“有没有人曾经”为开头。记下每一个需求的来源，这样向下跟踪直到发现特定的
客户。

   有些时候，尝试着问一些“愚蠢”的问题也有助于客户打开话匣子。如果你直接要求客
户写出业务是如何实现的，客户十有八九无法完成。但是如果你尝试着问一些实际的问题，
例如：“以我的理解，你们收到订单后，会...”。客户立刻就会指出你的错误，并滔滔不
绝的开始谈论业务，而你，就在一边仔细的聆听吧。这一招就叫做“抛砖引玉”。

   需求讨论会上必须要使用笔记本电脑，还要指定一个打字熟练的人把所有的讨论记录下
来，记录的同时还要做一定的整理。如果不这样做，那么你结束会议的时候就会发现，所有
的讨论只剩下一个模糊的印象，需求对你来说仍然是一件遥远的事情。在座谈讨论之后，记
下所讨论的条目(item)，并请参与讨论的用户评论并更正。及早并经常进行座谈讨论是需求
获取成功的一个关键途径，因为只有提供需求的人才能确定是否真正获取需求。进行深入收
集和分析以消除任何冲突或不一致性。

   尽量把客户所持的假设解释清楚，特别是那些发生冲突的部分。从字里行间去理解以明
确客户没有表达清楚但又想加入的特性或特征。Gause 和Weinberg（1989）提出使用“上下
文无关问题”—这是一个高层次的问题，它可以获取业务问题和可能的解决方案的全部信
息。客户对这些问题的回答诸如“产品要求怎样的精确度”或“你能帮我解释一下你为什么
不同意某人的回答吗？”这些回答可以更直接地认识问题，而这是封闭（close-end）问题
所不能做到的。

   需求获取利用了所有可用的信息来源，这些信息描述了问题域或在软件解决方案中合理
的特性。一个研究表明：比起不成功的项目，一个成功的项目在开发者和客户之间采用了更
多的交流方式（Kiel and Carmel 1995）。与单个客户或潜在的用户组一起座谈，对于业务
软件包或信息管理系统（MIS）的应用来说是一种传统的需求来源。直接聘请用户进行获取
需求的过程是为项目获得支持和买入（buy-in）的一种方式。

   尽量理解用户用于表述他们需求的思维过程。充分研究用户执行任务时作出决策的过
程，并提取出潜在的逻辑关系。流程图和决策树是描述这些逻辑决策途径的好方法。

   在需求获取的过程中，你可能会发现对项目范围的定义存在误差，不是太大就是太小。
如果范围太大，你将要收集比真正需要更多的需求，以传递足够的业务和客户的值，此时获
取过程将会拖延。如果项目范围太小，那么客户将会提出很重要的但又在当前产品范围之外
的需求。当前的范围太小，以致不能提供一个令人满意的产品。需求的获取将导致修改项目
的范围和任务，但作出这样具有深远影响的改变，一定要小心谨慎。

   正如经常所说的，需求主要是关于系统做什么，而解决方案如何实现是属于设计的范
围。这样说虽然很简洁，但似乎过于简单化。需求的获取应该把重点放在“做什么”上，但
在分析和设计之间还是存在一定的距离。你可以使用假设“怎么做”来分类并改善你对用户
需求的理解。在需求的获取过程中，分析模型、屏幕图形和原型可以使概念表达得更加清
楚，然后提供一个寻找错误和遗漏的办法。把你在需求开发阶段所形成的模型和屏幕效果看
成是方便高效交流的概念性建议，而不应该看成是对设计者选择的一种限制。

   需求获取讨论会中如果参与者过多，就会减慢进度。人数大致控制在5到7人是最好的。
这些人包括客户、系统设计者、开发者和可视化设计者等主要工程角色。相反地，从极少的
代表那里收集信息或者只听到呼声最高、最有舆论影响的用户的声音，也会造成问题。这将
导致忽视特定用户类的重要的需求，或者其需求不能代表绝大多数用户的需要。最好的权衡
在于选择一些授权为他们的用户类发言的产品代表者，他们也被同组用户类的其它代表所支
持。

   没有一个简单、清楚的信号暗示你什么时候已完成需求获取。当客户和开发者与他们的
同事聊天、阅读工业和商业上的文献及在早上沐浴时思考时，他们都将对潜在产品产生新的
构思。你不可能全面收集需求，但是下列的提示将会暗示你在需求获取的过程中的返回点。

   1. 如果用户不能想出更多的使用实例，也许你就完成了收集需求的工作。用户总是按
其重要性的顺序来确定使用实例的。

   2. 如果用户提出新的使用实例，但你可以从其它使用实例的相关功能需求中获得这些
新的使用实例，这时也许你就完成了收集需求的工作。这些新的使用实例可能是你已获取的
其它使用实例的可选过程。

   3. 如果用户开始重复原先讨论过的问题，此时，也许你就完成了收集需求的工作。

   4. 如果所提出的新需求比你已确定的需求的优先级都低时，也许你就完成了收集需求
的工作。

   5. 如果用户提出对将来产品的要求，而不是现在我们讨论的特定产品，也许你就完成
了收集需求的工作。

   以上知识大致上讨论需求分析应该如何做，实际上对于需求分析的方法有很多很多，已
经形成了一定的理论，当然这种理论比较偏向与方法学，而方法学的应用主要还是要靠个
人。所以，大家在实际应用的时候，不妨结合自己的实际，有选择性的采用一些方法，那你
就是成功的。

老猫

用例在需求分析中的使用

   多年来，分析者总是利用情节或经历来描述用户和软件系统的交互方式，从而获取需求
（McGraw and Harbison 1997）。Ivar Jacobson（1992）把这种看法系统地阐述成用例
（用例）的方法进行需求获取和建模。虽然用例来源于面向对象的开发环境，但是它也能应
用在具有许多开发方法的项目中，因为用户并不关心你是怎样开发你的软件。而最重要的，
用例的观点和思维过程带给需求开发的改变比起是否画正式的用例图显得更为重要。注意用
户要利用系统做什么远远强于询问用户希望系统为他们做什么这一传统方法。

   用例的重要功能是用画用例图的功能来鉴别和划分系统功能。它把系统分成角色
（actor）和用例（用例）。角色(actor)表示系统用户能扮演的角色（role）。这些用户可
能是人，可能是其他的计算机一些硬件或者甚至是其它软件系统，唯一的标准是它们必须要
在被划分进用例的系统部分以外。它们必须能刺激系统部分并接收返回。用例描述了当角色
给系统特定的刺激时系统的活动。这些活动被文本描述。它描述了触发用例的刺激的本质，
输入和输出到其他活动者，和转换输入到输出的活动。用例文本通常也描述每一个活动在特
殊的活动线时可能的错误和系统应采取的补救措施。

   这样说可能会非常复杂，其实一个用例描述了系统和一个角色（actor）的交互顺序。
用例被定义成系统执行的一系列动作，动作执行的结果能被指定角色察觉到。用例可以:

   用例捕获某些用户可见的需求，实现一个具体的用户目标。
   用例由角色激活，并提供确切的值给角色。

   用例可大可小，但它必须是对一个具体的用户目标实现的完整描述。在UML中，用例表
示为一个椭圆。

   角色是指用户在系统中所扮演的角色。其图形化的表示是一个小人。在某些组织中很可
能有许多角色实例（例如有很多个销售员），但就该系统而言，他们均起着同一种作用，扮
演着相同的角色，所以用一个角色表示。一个用户也可以扮演多种角色。例如，一个高级营
销人员既可以是贸易经理，也可以是普通的营销人员；一个营销人员也可以是售货员。在处
理角色时，应考虑其作用，而不是人或工作名称，这一点是很重要的。

   我们使用不带箭头的线段将角色与用例连接到一起，表示两者之间交换信息，称之为通
信联系。角色触发用例，并与用例进行信息交换。单个角色可与多个用例联系；反过来，一
个用例可与多个角色联系。对同一个用例而言，不同角色有着不同的作用：他们可以从用例
中取值，也可以参与到用例中。需要注意的是角色在用例图中是用类似人的图形来表示，尽
管执行的，但角色未必是人。例如，角色也可以是一个外界系统，该外界系统可能需要从当
前系统中获取信息，与当前系统有进行交互。

   一个用例可能包括完成某项任务的许多逻辑相关任务和交互顺序。因此，一个用例是相
关的用法说明的集合，并且一个说明（scenario）是用例的实例。这种关系就像是类和对象
的关系。在用例中，一个说明被视为事件的普通过程(normal course)，也叫作主过程，基
本过程，普通流，或“满意之路” (happy path)。在描述普通过程时列出执行者和系统之
间相互交互或对话的顺序。当这种交互结束时，执行者也达到了预期的目的。

   在用例中的其它说明可以描述为可选过程(alternative coruse)。可选过程也可促进成
功地完成任务，但它们代表了任务的细节或用于完成任务的途径的变化部分。在交互序列
中，普通过程可以在一些决策点上分解成可选过程，然后再重新汇成一个普通过程。

角色类和角色实例

   软件产品最终是给一些用户来使用的，而用户之间的差异是非常大的。造成差异的原因
包括了对计算机的认知程度的不同，使用习惯的不同，在软件目标组织中所处的地位不同，
地理位置不同，业务熟练程度不同。

   不同的用户都有自己一系列的功能需求和非功能需求。对电脑熟练程度不同的人可能就
会有不同的要求，熟练程度低的用户可能希望有一个友好的界面，熟练程度高的用户可能更
希望有快捷键或宏的操作以提高工作效率。考虑到用户的差异性，将用户分类并研究用户类
的行为特征是非常有必要的。所以在做具体的需求之前，先将用户分局行为和特点进行分
类，对于研究、收集用户的需求是非常有帮助的。

   可以利用一个简单的表格列出一些原始的分类，然后不断的完善这个表格。确认你的分
类之间没有交集。并充分描述用户分类的行为，目的，要求等。在企业分析中，比较常见的
分类可能包括，供应商，客户，部门等。

   就像C++中的类和对象一样，我们把分析出的用户分类称为“角色类”，把实际的用户
称为“角色实例”。在得到用户分类之后，最重要的就是要选出用户代表，用户代表不仅仅
是在需求阶段中参与项目，还必须对项目的全过程负责。用户代表能够代表用户分类的需
求。抓住用户代表的需求就大致把握住了用户类的需求。当然，需求分析还是需要在用户中
做大规模的调查的，只是要把重点放在用户代表上。

   确保和用户直接进行沟通！大家有没有玩过传话的游戏，可能看过。一群人排成一列，
一句话从排头挨个向后传，到最后，那句话已经是面目全非了。所以，一定要保证项目组能
够直接和用户接触。

   对于和用户直接沟通这一点，一般的针对特定企业的应用系统当然是不成问题，可是如
果是开发行业软件，和用户直接沟通就成为一件几乎是不可能的事情。在这种情况下，一般
有几种解决的办法：

   做大规模的市场调查，针对你的目标市场做市场调查，并根据统计学的理论建立你的数
学模型。这部分的工作效果最好，其性质有些象一些游戏公司会发布一些Demo版的游戏。可
是对于一般的企业来说，这项工作费时费力，高昂的成本往往使大家知难而退。我的意见
是，方法是非常好的，但是可以采用折衷的办法，例如选取有代表性的企业，为特定企业制
作一个较小的版本并收集反馈意见等。这涉及到很多市场营销的内容，并不是我的专业所
长，这里就不多弄斧了。

   聘请行业专家，一个行业专家往往可以在项目需求方面发挥极为重要的作用。一个行业
专家往往都有大量的行业经验和行业的人际关系网络。在产品的设计方面，这个行业专家提
供很多宝贵的意见。在目前很多的软件的开发过程中都采用了这种方式。行业专家有两种：
一种是在这个行业中有很深的资历，但是对软件技术并不熟悉；第二种是开发过同类软件的
软件专家，这种人在开发同类软件过程中已经积累了大量的项目经验，并且具有软件开发的
知识。这种方式是获取需求的最好的方式。

   分析对比同类软件，微软在开发Office、Visual Studio的时候，也是参照了Lotus和
Borland的成熟产品。这种方式的特点在于成本很低，比较适合和其他的方式配合使用。但
是，要注意自己有没有触犯专利法。

需求的冲突

   有的时候，虽然已经将用户分类并选出了用户代表。但是需求的来源众多，往往会发生
需求之间自相矛盾的事情。需求从四面八方收集来后，人们难以解决冲突，澄清模糊之处以
及协调不一致之处。某些人还要对不可避免要发生的范围问题单独作出决定。在项目的早期
阶段，你必须决定谁是需求问题的决策者。如果不清楚谁有权并且有责任来作出决策，或者
授权的个人不愿意或不能作出决策，那么决策者的角色将自然而然地落在开发者身上。这是
一个非常糟糕的选择，因为开发者通常没有足够多的信息和观点来作出业务上的决策。

   在软件项目中，谁将对需求作出决策的问题并没有统一的正确答案。分析员有时听从呼
声高的或来自最高层人物的最大的需求。即便使用用户代表这一手段，必须解决来自不同用
户类的相冲突的需求。通常，应尽可能由处于公司底层的人作出决策，因为他们与问题密切
相关，并能得到关于这些问题的广泛信息。

   如果不同的用户类有不一致的需求，那么必须决策出满足哪一类用户的需求更为重要。
了解可能使用产品的客户种类的信息和他们的用法与产品的业务目标的关系如何，将有助于
你决定哪一个用户类所占份额最大。

   当开发者想象中的产品与客户需求冲突时，通常应该由客户作出决策。然而，不要陷到
“客户总是对的”的陷阱中去，对他们百依百顺。现实中，客户并不总是对的。客户总是持
有自己的观点，开发者必须理解并尊重这一观点。

用例

   在具体的需求过程中，有大的用例（业务用例），也有小的用例。主要是由于用例的范
围决定的。用例像是一个黑盒，它没有包括任何和实现有关或是内部的一些信息。它很容易
就被用户（也包括开发者）所理解（简单的谓词短语）。如果用例不足以表达足够的信息来
支持系统的开发，就有必要把用例黑盒打开，审视其内部的结构，找出黑盒内部的Actor和
用例。就这样通过不断的打开黑盒，分析黑盒，再打开新的黑盒。直到整个系统可以被清晰
的了解为止。

   为什么要采用这种分析方法呢？计算机系统除了在与外界系统、人员有一系列的交互，
在系统内部也往往存在着复杂的交互。因此，在系统建模时，除了描述系统与外界的交互，
同时还要描述系统内部的交互。传统的MIS系统中，系统与外界的交互较多。典型的，如ATM
取款机：存在着大量的用户与ATM，ATM与其它系统的交互。而电信领域的系统，与外界的交
互较少。例如，系统的输入可能仅仅是从交换机上采集信息，然后由系统进行处理。系统的
复杂逻辑包含在系统内部处理的流程上，而非与外部系统的交互。建模主要任务是表达系统
内部的交互。

   用例图适于表达交互，之所以上面使用了电信系统，是因为用例最早来自于Ericsson的
交换机系统。当时，还是Ericsson雇员的Jacobson初步建立了用例图的概念，并于1994年提
出了OOSE方法，其最大特点是面向用例（Use-Case），并在用例的描述中引入了外部角色的
概念。用例的概念是精确描述需求的重要武器，比较适合支持商业工程和需求分析。随着用
例的发展，用例被大量的 用于对功能进行描述。每个用例代表了系统与外部ACTOR的交互。
可以采取顺序图来表达用例的具体操作程序。ACTOR用于确定系统的边界。

   ACTOR、用例可以从不同的层次来描述信息。采用该原则的原因有：

   1. 需求并不是在项目一开始就很明确，往往是随着项目的推进，逐渐细化。
   2. 人的认知往往具有层次的特性。从粗到细、从一般到特殊。采用不同的层次来描
述，适于认知的过程。

使用用例开发系统的一般过程

   在开发过程的初始阶段，可以根据具体的项目特点，制订开发各个视图之间的关联原
则，指导规范。在开发的过程中，视图的组织原则应不断进行维护、更新。

   识别ACTOR来识别系统与外界交互的实体。ACTOR具有特定领域的特征，例如：交换机
（采集系统）、97信息系统等。在系统层次的ACTOR确定了系统的边界。

   识别用例。同ACTOR一样，用例具有不同层次。对较为概括的USECASE，需要细化。注：
系统开发需要一定的规则来确定，如何来分解用例；可能基于原有系统的经验，或是参考现
有资料。

   当用例细化到可以被理解的层次。需要基于用例进行下一步的开发。如前面提到的，用
例主要用来描述交互。因此，存在交互的实体和交互的细节。交互的实体采用类图来描述；
而交互的细节，采用顺序图来描述。

   当系统复杂到一定层次时，类图和顺序图可能不能足以描述其复杂程度。在该情况下，
需要使用状态图来辅助阐述。状态图和顺序图之间使用事件联结在一起。它们之间的一致性
问题，目前UML和ROSE没有提供解决方案。相对折衷的方法是使用事件的命名规范强制一致
性。

   可以说，之前说的所有的东西都是为了能够导出用例在需求中的作用。用例是从用户的
角度看待系统，而不是基于程序员的角度。这样的话，用例驱动的系统能够真正做到以用户
为中心，用户的任何需求都能够在系统开发链中完整的体现。用户和程序员间通过用例沟
通，避免了牛头马嘴的尴尬局面。

   从前，系统开发者总是通过情节来获取需求，是问用户希望系统为他做什么。在
Jacobson发明了用例的概念之后，需求获取就变成问用户要利用系统做什么。这是立场不同
导致的结果。用户通常并不关心系统是如何实现的（也有少数可爱的技术狂是例外）。对他
们来说，更重要的是要达到他的目的。相反的，大部分的程序员的工作习惯就是考虑计算机
应该如何实现用户的要求。所幸的是，用例方法能够调和双方的矛盾，因为虽然用例是来源
于用户，服务于用户，但是它同样可以用于开发的流程。当系统的开发过程都是基于用例
的，用用例获取需求，用用例设计，用用例编码，用用例测试的时候。这个开发过程就是用
例驱动的。

用例和用例文档

   《软件需求》一书中提到了几种方法来确定用例：

   首先明确执行者和他们的角色，然后确定业务过程，在这一过程中每一个参与者都在为
确定用例而努力。
   确定系统所能反映的外部事件，然后把这些事件与参与的执行者和特定的用例联系起
来。
   以特定的说明形式表达业务过程或日常行为，从这些说明中获得用例，并确定参与到用
例中的执行者，
   有可能从现在的功能需求说明中获得用例。如果有些需求与用例不一致，就应考虑是否
真的需要它们。

   用例代表了用户的需求，在你的系统中，应该直接从不同用户类的代表或至少应从代理
那里收集需求。用例为表达用户需求提供了一种方法，而这一方法必须与系统的业务需求相
一致。分析者和用户必须检查每一个用例，在把它们纳入需求之前决定其是否在项目所定义
的范围内。基于“用例”方法进行需求获取的目的在于：描述用户需要使用系统完成的所有
任务。在理论上，用例的结果集将包括所有合理的系统功能。在现实中，你不可能获得完全
包容，但是比起我所知道的其它获取方法，基于用例的方法可以为你带来更好的效果。

   当使用用例进行需求获取时，应避免受不成熟的细节的影响。在对切合的客户任务取得
共识之前，用户能很容易地在一个报表或对话框中列出每一项的精确设计。如果这些细节都
作为需求记录下来，他们会给随后的设计过程带来不必要的限制。你可能要周期性地检查需
求获取，以确保用户参与者将注意力集中在与今天所讨论的话题适合的抽象层上。向他们保
证在开发过程中，将会详尽阐述他们的需求。在一个逐次详细描述过程中，重复地详述需
求，以确定用户目标和任务，并作为用例。然后，把任务描述成功能需求，这些功能需求可
以使用户完成其任务，也可以把它们描述成非功能需求，这些非功能需求描述了系统的限制
和用户对质量的期望。虽然最初的屏幕构思有助于描述你对需求的理解，但是你必须细化用
户界面设计。

   建立用例文档。在每一次的需求获取之后，都会生成很多未整理的需求，你必须将它们
组织成用例文档。使用诸如模板的技术能够提高你的速度和需求的复用性。一个用例文档可
以使用表格来组织，主要的要素包括了用例标识号、用例名称、父用例标志号、创建者、创
建时间、审核者、修订记录、角色、说明、先决条件、请求结果、优先级、普通过程、可选
过程、例外、非功能需求、假设、注释和问题。

   虽然列举出了这么多的属性，但是实际中使用的属性这要看你的团体而定，看项目的大
小而定。把大量的时间花在用例的描述上是没有意义的。用户需要的是一个软件系统，并不
是一大堆的用例说明。

老猫

需求管理这个词有两个部分：需求和管理。先说需求，需求是什么，需求就是你要买衣
服时要对售货员说你要多大的衣服。需求很难说清楚，比你搞不清楚自己的尺码还难，因为
售货员会看看你的身材，拿出一件衣服让你试一下，不合适可以不给钱。但是软件不行，你
会说我先给你开发个软件给你试一下，不好不用给钱吗，我反正不会。需求会变，如果你胖
了或是瘦了，发现原来的衣服不能穿了，你会再买一件，如果再买一件衣服需要花掉你
10000块钱，你怎么办？而由于软件不合适更换软件的费用是非常惊人的。

   人类的大部分的工程都会有比较严格的计划和质量保证，例如建筑。但是工程一旦落实
到软件开发上的时候，大家就会变得“大大咧咧”起来。软件项目中百分之四十至百分之六
十的问题都是在需求分析阶段埋下的“祸根”（L effingwell 1997）。如果你对建成的桥
不满意，要求设计师把桥转90度，他一定会认为你疯了，但是软件开发中经常都有发生要求
开发者更换操作系统的事情，要知道，这二者对项目而言的工程量可没有太大的差别。
所以呢，正是由于需求的难表述性和易变性，所以需求需要有科学的分析方法和管理方法，
这里分析方法不是本文的重点。

需求的特点

   需求的特点刚才已经提到了，就是难以表述和易变。可是，为什么需求会有这种的特点
呢？

   在计算机产生的早期，计算机只是少数人的“宠物”，这些人个个学富五车，才高八
斗。他们可以用010101之类的语言直接操纵计算机，他们也乐此不疲，那时候计算机对人类
的影响还不是很大。随着计算机硬件越来越快，越来越小，软件也发生了翻天覆地的变化。
计算机变成了社会不可或缺的一种工具。但是，计算机的文化，计算家的理念一直都没有变
化，今天的程序员和几十年前的程序员骨子里还是一样的。他们喜欢操纵计算机，思考都和
计算机一样，运用逻辑思维，甚至在他的思想中只有0和1。这对于感性的普通人来说无法接
受。可是，普通人使用的软件正是这些拥有逻辑思维的人设计制造的。程序员的思维贯穿了
软件设计的全过程，同样也贯穿了需求过程，而普通人没有这方面的思维，他们觉得和程序
员打交道极为困难，在程序员的眼里，世间的一切都是有清楚的界限的：0和1。需求过程
中，双方往往发现要么双方不能达成共识，要么双方达成共识的内容其实有相当大的出入。
所以在需求过程中经常出现用户讲不清楚，讲不完全需求的情况。更要命的是，在需求阶段
就又问题的需求，如果在软件后期发现，那么改正的费用是非常可怕的。有时候，甚至会超
出项目本身的费用。



   社会在卖方时代的时候，企业只需要生产出产品，保证产品的质量，就不用担心产品的
销售了，所以生产的过程也是比较稳定的。随着社会进入买方时代，企业必须不断的适应市
场，适应消费者才能保证不为社会所淘汰，所以企业的经营活动必须不断的变换以保证企业
具有活力。这种变化对于计算机系统来说是非常可怕的一件事。计算机系统必须不断适应企
业的变化而变化，否则就会阻碍企业的发展，原先是为了加速企业发展而开发的信息系统却
成了企业发展的束缚，这不是一个极大的讽刺吗？除了宏观的原因外，需求的不易表达也是
需求易变的一个原因，需求分析的不清晰和不完整导致了需求必将发现变化，要么就是对原
先的需求进行修改，要么就增加需求。

需求的总流程

需求的总流程如下图：



   需求分析的这个过程，我们可以称它为需求工程，也有叫做需求过程和需求阶段的。需
求工程包括了需求开发和需求管理，他们所涉及到的具体工作流如上图标明的那样。在上一
篇中，我介绍了一个我自己所经历的需求过程的例子，这个例子就经历了整个的需求过程，

   由于我们讨论的重点是在需求管理，所以上图左半边的部分不再我们的讨论范围之内。

需求管理

   软件能力成熟度模型（The Capability Maturity Model ，CMM）的第二级（可重复
级）中将需求管理做为六个关键过程域（Key Process Areas ，KPAs）的一个：

   需求管理的目的就是在客户和遵循客户需求的软件项目之间建立一种共同的理解。

需求的目标包括：

控制指定给软件的系统需求，为软件工程和管理应用建立基线。
保持软件计划、产品和活动与指定给软件的系统需求一致。

   为了实现第一个目标，必须要控制需求基线的变动，实施需求变更控制和版本控制。为
了实现第二个目标，必须要对需求进行跟踪，管理需求和其他联系链之间的联系和依赖。

   虽然并没有要求说软件团体必须要实施CMM，但是CMM的思想对任何的软件团体来说都是
有益的，CMM为了实行这两个目标，还确定了一系列的执行约定、执行能力、执行活动来达
到这两个目标。但是，CMM并没有强制要求软件团体必须遵循的软件需求管理过程。

   对于产生的需求变更，必须要有变更控制的标准、规范的过程来处理，并且由基于业务
和技术的原因来赞同或反对这项变更。在接受了软件变更之后，必须要保证软件开发计划要
和需求保持一致，并对需求的版本进行控制，避免同时出现多个需求版本的情况。在保证软
件开发计划方面会有很多问题产生，例如进度、质量等。这时候，必须就变更和软件项目各
小组达成共识，对软件项目计划作出调整，其中包括人员的安排、任务的安排、用户的沟
通、成本的调整，进度的调整等。

   为了能够实现上面所阐述的过程，必须要将需求过程文档化，注意，是需求过程，包括
了需求开发和需求管理两个方面。使用适当的Case工具也同样有利于管理工作的开展，按照
我自己的经验，采用Office和命名准确的目录就已经足够胜任此工作了，但是如果要能够更
高层次的使用Case工具，我建议使用关系数据库来管理你的需求。至于在工具方面，是各软
件团体自身的情况而定。我相信，没有最好的工具，只有最适合的工具。

变更控制

   记得还在大学的时候，和同学讨论一道知名软件企业的考题：如果客户要求你帮助他修
改软件一项功能，你应该怎么做？正确的答案是要向你的项目经理报告。这里面就包含了变
更控制的思想。在前面我们已经说过，易变是需求的一个特点，但是任何需求的变动都会对
项目产生或多或少的影响，如推迟进度，增加人员等。如果没有对变更的控制，那么项目就
会失去控制。我就见识过一个软件项目在经历了无数次的因需求变更导致的延期之后，发现
改变的功能已经远远偏离了原先的需求定义。

   研究表明，扩展需求对百分之八十的管理信息系统项目和百分之七十的军事软件项目造
成风险（Capers Jones 1994）。扩展需求是指在软件需求基线已经确定后又要增添新的功
能或进行较大改动。问题不仅仅是需求变更本身，而是迟到的需求变更会对已进行的工作有
较大的影响。具体的原因包括在软件系统中引入新功能往往会带来新的问题，新加入的需求
和以前的需求有矛盾之处。

   由于需求的可变性，所以没有需求变更是不可能的，并不是说你的需求分析不够完整，
业务过程、市场机会、竞争性的产品和软件技术在开发系统期间是可以变更，管理部门也会
决定对项目做出一些调整。所以你在你的项目进度安排中一定要给需求变更留下余地，微软
的开发方式中在每一个的里程碑（Milestone）间都预留了50%的时间，也是有这方面的理
由。

   然而，这并不是说你要接受所有的要求，国内很多软件公司深得“客户就是上帝”的精
髓，客户的所有要求都予以满足，这样做的结果往往就是开发人员疲惫不堪，质量得不到保
证，项目延期，客户和软件团队双方的利益都受损失。学会对客户说“不”，当然，回绝必
须要讲技巧，并不是一句“不行”就可以解决问题的。昨天我去买东西，我问售货员能不能
便宜一点，她回答说：“不行，已经很便宜了！”。最后我就没有买，但是她如果换句话
说：“对不起，我们的商品的质量都是特别好的，如果您下次再来的话，我们将给你优惠的
价格”，我相信我会买下那个商品。所以说不要讲究技巧。客户的要求应该尽量满足，即时
现阶段不行，也要向客户解释清楚，并在下一个版本中考虑客户的要求。

   对于需求变更的控制，保证成功的最主要的两点是将变更应用到整个开发链和记录历史
变更。你可能需求一份变更控制文档来说明变更需求，大致需要说明的元素包括：

   概述：说明变更的大致内容，应用范围，对开发链的影响，总之让管理变更控制的人明
白你的要求是什么。
   上下文：变更的需求在整体需求中的位置，如果需求是用用例表示的，指出他的父用例
是什么。
   规模：根据开发进行的程度，指出实施变更需要付出的代价，这个代价是决定接受需
求，通知客户项目延期，在下个迭代周期中实现变更的决定参考。
   提交人签字和所属开发组：决定了提交人所处的立场。

   一般来说接受需求变更提交的组织称为变更控制委员会（CCB 有时也称为结构控制委员
会），该委员会的组成包括各开发小组的代表，以保证需求变更实施到整个开发链。CCB的
工作流程大致是：

   接收到一新的变更要求后评估建议的技术可行性、代价、业务需求和资源限制。执行系
统影响分析、风险分析、危害分析及其它评估。这些分析确保能很好理解接受变更所带来的
潜在影响。同样也考虑拒绝变更所带来的对业务和技术的影响。

   CCB决定是采纳或还是拒绝请要的变更。给每个采纳的变更需求设定一个优先级或变更
实现日期，或将它分配给指定的产品。CCB通过更新请求状态和通知所有涉及到的小组成员
来传达变更决定。相关人员可能不得不改变工作产品，如软件需求规格说明文档、需求数据
库、设计模型、用户界面部件、代码、测试文档、用户文档。修改者在必要时应更新涉及的
工作产品。

   通过检查确保更新后的软件需求规格说明文档、使用实例文档、分析模型均正确反映变
更的各个方面。使用跟踪能力信息找出受变更影响的系统的各个部分，然后验证他们实现了
变更。属于多个小组的成员可能会通过对下游工作产品测试或检查工作来参与验证变更工
作。验证后，修改者安装更新后的部分工作产品并通过调试使之能与其它部分正常工作。
（摘自《软件需求》）

   最后，你需要记录变更记录，并建立需求变更跟踪矩阵来确保变更的实施。

版本控制

   需求版本混乱造成的灾害主要体现在资源的浪费上面，很多软件团体中经常发生开发组
花费时日改进了一项功能，却发现整项功能已经取消，发生错误原因是因为开发组没有拿到
最新的需求。

   版本控制包括两个方面：保正人人得到的是最新的版本，记录需求的历史版本。

   如果有专门的需求管理商业工具可以助您一臂之力，由于我并没有条件试用所有的需求
管理工具，能够向大家推荐的只有瑞理公司的RequisitePro，推荐的一个重要原因是它能够
把需求和瑞理的其他工具如Rose、TeamTest等联系起来，从而实现需求链。

   能够借助工具将需求自动化固然很好，不过，工具使用不当也不会提高生产效率。需求
管理的工具其实用简单的Office和任一个关系型数据库就可以解决，而且根据企业自身的特
点，摸索出最适合企业用的工具。

   版本控制的最简单方法是在每一个公布的需求文档的版本应该包括一个修正版本的历史
情况，即已做变更的内容、变更日期、变更人的姓名以及变更的原因并根据标准约定手工标
记软件需求规格说明的每一次修改。

需求链和需求跟踪

   如果你是一个开发人员，一天，市场部的小莉跑过来让你修改你正在开发产品的一个小
小的功能，这是应客户的要求添加的，你觉得这个要求很简单，再加上你对小莉有好感，可
能你就答应了她的要求。可是实际的情况是怎么样的呢？你会发现小小的修改并没有想象的
那么简单，对这项产品的修改导致了进程的延误，最糟糕的是，由于这项修改没有传达到整
个需求链，其他的开发人员那里由于你的修改出现了一些要命的错误。

   软件工程重视的是过程能力，如果不能严格的确保过程的每一个环节都被不择不扣的执
行，软件过程就会不成功，我们都学过法律常识，都知道有法可依还不够，还必须有法必
依，执法必严。遗憾的是，中国的软件组织对过程的严格执行并不是特别重视，上面的例子
在各团体中都是很普遍的，这可能和中国人的思维方式有些关系，关于这一点，鲁迅先生在
很早的时候已经讨论过了，我们就不用在此罗嗦了。

   需求链的概念指的是需求能够上传下达，从客户传达到需求过程，并从需求过程传达到
需求过程的下游开发链。而这个传达是可以逆向的。



   需求跟踪提供了一个表明与合同或说明一致的方法。更进一步，需求跟踪可以改善产品
质量，降低维护成本，而且很容易实现重用（ Ramesh 1998）。

   在CMM三级中要求软件团体必须具备需求跟踪的能力：“在软件工作产品之间，维护一
致性。工作产品包括软件计划，过程描述，分配需求，软件需求，软件设计，代码，测试计
划，以及测试过程。”

   实际上，创建需求跟踪能力是困难的，尤其是在短期之内会造成开发成本的上升，虽然
从长远来看可以减少软件生存期的费用，软件团体在实施这项能力的时候应循序渐进，逐步
实施。

   需求跟踪的一种通用的方法是采用需求能力跟踪矩阵。它的前提条件是将在需求链中各
个过程的元素加以编号，例如：需求的实例号，设计的实例号，编码的实例号，测试的实例
号。他们的关系都是一对一和一对多的关系。通过编号，你可以使用数据库进行管理，需求
的变化能够立刻体现在整条需求链的变化上。

   需求跟踪矩阵并没有规定的实现办法，每个团体注重的方面不同，所创建的需求跟踪矩
阵也不同，只要能够保证需求链的一致性和状态的跟踪就达到目的了。

老猫

是否大家的需求不高哦！！点击率好底野！！

老猫

各位不好意思！因为本人论坛被删了！所以不能再续下去了！
SORRY！！