需求管理是软件开发生命周期的初始阶段，它对最终提交的软件产品的质量起着至关重要的作用。一位咨询师朋友告诉我，在美国，超过60%的软件项目失败都是因为不科学的需求管理。另外，80%的项目延误也源于不断改变的需求。由此可见，需求管理是整个软件开发过程中至关重要的一部分；尤其是对于大型项目，科学的需求管理在降低风险上的作用更是无法估量。

　　软件开发实践表明，让所有项目成员获得准确的需求，是进行需求管理的根本；在此基础上，还应保证所有的需求变更都是在可控制的情况下进行。除需求分析师外，所有其他相关人员，如项目经理、开发组长、QA经理等，如能参与到需求评审中，不仅有利于管理需求，还能进一步保证需求与业务实际更加匹配。对于需求变更，在执行之前分析其潜在影响，进行有针对性的人员和资源配置，都将提高需求变更的实现效率。

　　需求管理工具现状

　　对于市面上的需求管理工具，我主要有以下三方面的看法。首先，目前很多需求管理工具都与开发过程脱节。许多时候，开发工具与需求管理工具必须协同工作，然而，开发人员与需求分析师却不能进行有效的数据交流。另外，需求文档和知识库的分离，也不利于需求分析师了解各个需求的进展情况，而且限制了高层管理人员对跨部门工作的全局了解。

　　另一方面，有越来越多的企业，受到诸如塞班斯法等新法规的影响，不得不开始大范围使用需求管理工具。这在某种程度上为市场造就了一批针对特定行业的需求管理软件。这些软件多数适用于对需求有严格控制的行业，如航空航天和军工行业等。然而，对于普通行业市场，企业更需要的是实用、集成的需求管理解决方案。Forrester最近的一份报告指出，大部分企业都缺乏成熟的需求收集机制和体系；在这种情况下，即便实施功能强大的工具，企业也没有能力来充分利用各种功能和设置，更不用说有效利用这些工具来管理需求了。

　　另外，针对传统的瀑布式开发，所有的需求都在开发开始之前完成。然而，对于目前被广泛采用的增量或迭代开发模式，需求常常是由需求制造者和消费者不断交流所产生的，也是不断变化的。因此，有效的解决方案必须满足在类似增量或迭代开发模式下的需求管理。
集成的、全局的需求管理方法

　　基于对一些成功软件组织的经验分析，我们认为企业真正需要的是一款集成的需求管理解决方案，帮助企业进行可监控、可跟踪、可验证的需求管理。它需要提供一个框架以供创建新的需求、功能和规格，并与开发任务和测试任务相关联。需求分析团队和开发团队才能通过这个集成的解决方案协同工作。

　　这种集成的方案不仅能提高需求管理工具的性价比，也有利于项目团队的内部交流。开发团队可以及时获得需求信息；需求分析师能通过查看需求的进展情况来确定可能会发生的需求变更；高层管理者也能够通过查询和图表等功能浏览开发项目的进展情况。一款能够实现以上目标的需求管理工具应该具备以下几点功能：

　　•集成的需求管理：创建、管理、讨论并关联项目需求和功能;

　　•变更控制：当特定的变更发生时自动进行需求版本管理，并通过工作流引擎来控制需求变更；

　　•数字资产管理：需求、功能以及其他重要的数字资产都需要存储在一个可靠、可扩展、安全的中央资料库中；

　　•集成事件跟踪和测试：需求管理与事件跟踪和测试管理工具集成，以便于项目经理查看与需求相关的开发和测试工作；

　　•Windows客户端和Web客户端：提供Windows客户端和Web客户端访问方式，保证在固定和移动办公的情况下都能登录到系统中；

　　•定制化的用户界面：提供定制选择，以便于系统管理员创建自定义的需求和功能界面，如字段标签、字段类型、下拉菜单选项和客户报告等；

　　•开放的工作流设置：通过定义工作流来创建和管理需求和功能；

　　•嵌入式报表和分析：直接产生需求功能数据报表，如变更控制、变更效应、实施和测试数据等；

　　•自动获取需求：在系统中，用户可以直接输入需求信息，或者通过文档形式获得需求并附加到系统中。

　　在独立实现以上功能的基础上，需求管理工具还需与ALM中的开发过程进行无缝集成，其中包含事件跟踪、测试管理、以及中央知识库（如图1所示）。

　　规范点驱动的需求管理

　　诚然，需求管理对整个软件项目的成败发挥着举足轻重的作用。然而，需求在最初只是客户或管理人员对产品功能的一种愿望，需求分析师要将这种非结构化、粗线条、不明确的愿望归纳总结为具体的规范点（Specification，简称Spec）。产品管理团队再把各种Spec根据开发时间、成本和效益进行优先排序，确定Spec单，再由开发团队照单实施。

　　SpecDD（Specification Driven Development）是TechExcel根据多年经验，总结众多客户关于软件开发管理的需求而提出的一个概念性框架。SpecDD模型用Spec来表述/定义产品或版本功能，并通过中央知识库与整个团队有效共享，使Spec成为贯穿软件应用生命周期各阶段的要素，从而驱动整个开发流程。将知识和需求转换为结构化的、正规表达的Spec，是将整个开发过程从宏观战略落实到具体实施战术的过程。

　　SpecDD模型在需求管理上的优势主要体现为以下三个方面。首先，通过SpecDD模型可以实现对需求的度量和评估，包括每个需求所需要的资源和时间，将开发所需的时间和费用与需求相关联，度量和评估需求是否成功，通过需求验证指标来管理开发、测试活动。其次，Spec与项目规划、开发和测试任务始终保持关联，这就保证了开发的每一个环节都是可追溯。另外，SpecDD模型还能评估需求变更的潜在影响，例如需求变更对开发和测试工作、项目成本的影响。

　　通常情况下，Spec包含功能、缺陷和功能增强三个部分，他们都来源于相关的知识或需求，并与需求条目和知识库中的知识条目相关联。图2以Browser 6.0产品为例，用图形化的方式显示了Spec与知识、需求的关系。针对Browser产品的最新版本6.0，有安全和用户界面两大类需求，通过需求分析师将其分解为新的功能，如支持SSL v.3.0、Tabbed Browsing等；除新功能以外，Spec还包括对之前版本的功能增强，如保存已标记的文件；以及上一版本的缺陷，如保存时响应缓慢。这些Spec通过规划、编码、测试等工作，构成最终交付的产品。

　　同时，Spec也是高度结构化的，表现为其树形结构准确对应产品/版本功能树，以保证开发人员不丢失任何需求（如图3所示）。产品管理团队通过创建Spec树，使每个功能/缺陷/功能增强都能对应分支上的树叶。同时，Spec与知识项目相关联，这些知识项目描述了形成此Spec的构思，以及其他相关的文档、标准、附件和参考项目。

　　需求变更的管理

　　理解需求变更可能产生的效应，并有效的进行控制，对于软件的最后提交都是至关重要的。无论是变更已有需求，还是增加新的需求，都对项目最终交付的日程造成不同程度的影响。例如，需求变更可能会影响到与之相关的功能、任务和测试工作；编码延期会延误与该功能相关的其他开发任务和测试工作。因此，有效的需求管理工具，必须保证项目团队能够很容易的评估这些变更可能带来的影响。

　　如何在变更发生之前对其进行评估呢？这就需要将需求管理与所有开发、测试行为进行集成，用户就可以通过跟踪编码、测试等行为对变更带来的潜在影响进行评估。这在SpecDD模型中得以实现。

　　将有效的变更转变为需求

　　如前文所讲，SpecDD模型表现为用Spec来表述/定义产品或版本功能，并和整个团队有效共享，从而驱动开发。因此，要保证交付的产品完全符合最终版本的Spec，需求分析部门就要和开发部门协同工作，并对变更做出严格的控制。对开发工作有潜在影响的变更都将会被慎重管理，并严格检验是否影响到需求的依赖关系。所有因需求变更而产生的影响，都必须检验变更后的完整性。因此，要实现有效的需求变更，管理工具需要实现以下几种功能：

　　•变更控制

　　对变更进行严格的流程控制，包括请求、复查、讨论、调整和批准等；
   
　　变更请求由一个独立的工作流所控制；
   
　　变更不能对需求造成不良影响，因此在变更被批准之前，需求不能被改变。

　　•实用性
   
　　接近实际的需求管理实践；
   
　　易于被客户理解；
   
　　易于对重要的变更进行跟踪。

　　•各部门协同工作
   
　　需求、功能和开发等各方面的人员都在各个阶段参与变更请求，将不同部门的人员都纳入变更管理体系；
   
　　让开发团队参与到变更请求的批准过程中，这样会比被动的接受或拒绝变更要更科学、更有效；
   
　　在变更得到批准或拒绝之前，分析针对该变更在资源和时间上的分配。

　　科学有效的需求管理是软件项目成功的保证。在更新需求的过程中，让项目的所有相关人员从各自的角色出发，都参与其中，将促进软件产品最终达到业务目标。需求变更时，对其进行准确的分析和评估，也有助于确保项目按时提交。

　　除需求管理工具独立工作以外，将它与应用生命周期管理（ALM）中的其他过程管理工具集成，才能最终提供一个完整的贯穿需求和开发过程的解决方案。需求分析人员和开发团队通过一个平台实现协同工作，统一接口和共用流程。这就能促进需求数据在需求制造者和实施者之间无缝、实时的传递，并保证在开发的每一个环节都可追溯需求。

　　如前文所讲，SpecDD模型表现为用Spec来表述/定义产品或版本功能，并和整个团队有效共享，从而驱动开发。因此，要保证交付的产品完全符合最终版本的Spec，需求分析部门就要和开发部门协同工作，并对变更做出严格的控制。对开发工作有潜在影响的变更都将会被慎重管理，并严格检验是否影响到需求的依赖关系。所有因需求变更而产生的影响，都必须检验变更后的完整性。因此，要实现有效的需求变更，管理工具需要实现以下几种功能：

　　•变更控制
   
　　对变更进行严格的流程控制，包括请求、复查、讨论、调整和批准等；
   
　　变更请求由一个独立的工作流所控制；

　　变更不能对需求造成不良影响，因此在变更被批准之前，需求不能被改变。
　　•实用性
   
　　接近实际的需求管理实践；
   
　　易于被客户理解；
   
　　易于对重要的变更进行跟踪。

　　•各部门协同工作
   
　　需求、功能和开发等各方面的人员都在各个阶段参与变更请求，将不同部门的人员都纳入变更管理体系；
   
　　让开发团队参与到变更请求的批准过程中，这样会比被动的接受或拒绝变更要更科学、更有效；
   
　　在变更得到批准或拒绝之前，分析针对该变更在资源和时间上的分配。

　　科学有效的需求管理是软件项目成功的保证。在更新需求的过程中，让项目的所有相关人员从各自的角色出发，都参与其中，将促进软件产品最终达到业务目标。需求变更时，对其进行准确的分析和评估，也有助于确保项目按时提交。

　　除需求管理工具独立工作以外，将它与应用生命周期管理（ALM）中的其他过程管理工具集成，才能最终提供一个完整的贯穿需求和开发过程的解决方案。需求分析人员和开发团队通过一个平台实现协同工作，统一接口和共用流程。这就能促进需求数据在需求制造者和实施者之间无缝、实时的传递，并保证在开发的每一个环节都可追溯需求。