前些日子有一个朋友向我要一份需求的标准文档，因为他现在正在负责一个项目。我对他说，我的需求文档只适合我用，并不适合你用。如果你是真的想在开发过程中引入科学的管理方法，静下心来，认真的学习需求的方法论，仔细的思考适合你们自身的方法。如果你只是需要一份好看的模版来哄哄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）以展示达到目标的能力。需求管理是其中之一，它的目标如下：
需求管理的关键过程领域不涉及收集和分析项目需求。而是假定已收集了软件需求或已由更高一级的系统给定了需求。一旦需求到手且文档化了，软件开发团队和有关的团队（例如质量保证和测试）需要评审文档。发现问题应与客户或其它需求源协商解决，软件开发计划是基于已确认的需求。
开发团队在向客户、市场部或经理们作出承诺（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）。这些子项包括软件类产品中需求收集、评价、编写文档等所有活动。
