以知识为核心的ALM之需求管理篇

1、以知识为核心的ALM之需求管理 篇需求管理是软件开发生命周期的初始阶段，它对最终提交的软件产品的质量起着至关重要的作用。一位咨询师朋友 告诉我，在美国，超过60%的软件工程失败都是因为不科学的 需求管理。另外，80%的工程延误也源于不断改变的需求。由 此可见，需求管理是整个软件开发过程中至关重要的一部 分；尤其是对于大型工程，科学的需求管理在降低风险上的 作用更是无法估量。软件开发实践说明，让所有工程成员获得准确的需求， 是进行需求管理的根本；在此基础上，还应保证所有的需求 变更都是在可控制的情况下进行。除需求分析师外，所有其 他相关人员，如工程经理、开发组长、QA经理等，如能参与 到需求评审

2、中，不仅有利于管理需求，还能进一步保证需求 与业务实际更加匹配。对于需求变更，在执行之前分析其潜 在影响，进行有针对性的人员和资源配置，都将提高需求变 更的实现效率。需求管理工具现状对于市面上的需求管理工具，我有以下三点看法。首先， 目前很多需求管理工具与开发过程脱节。很多时候，开发工 具和需求管理工具必须协同工作，但是开发人员和需求分析 师不能有效地沟通数据。此外，需求文档和知识库的别离不 利于需求分析师了解每个需求的进展，也限制了高层管理者 对跨部门工作的整体了解。另一方面，有越来越多的企业，受到诸如塞班斯法等新法规的影响，不得不开始大范围使用需求管理工具。这在某 种程度上为市场造就了一批

3、针对特定行业的需求管理软件。 这些软件多数适用于对需求有严格控制的行业，如航空航天 和军工行业等。然而，对于普通行业市场，企业更需要的是 实用、集成的需求管理解决方案。Forrester最近的一份报告 指出，大局部企业都缺乏成熟的需求收集机制和体系；在这 种情况下，即便实施功能强大的工具，企业也没有能力来充 分利用各种功能和设置，更不用说有效利用这些工具来管理 需求了。另外，对于传统的瀑布式开发，所有的需求都是在开发开 始前完成的。但对于目前广泛使用的增量式或迭代式开发模 式，需求往往是需求者和消费者不断沟通产生的，也是不断 变化的。因此，有效的解决方案必须以类似的增量或迭代开 发模式满足需求

4、管理。集成的全球需求管理方法基于对一些成功软件组织的经验分析，我们认为企业真正 需要的是一个集成的需求管理解决方案，它可以帮助企业以 可监控、可追踪和可验证的方式管理他们的需求。它需要为 创立新的需求、功能和规范提供一个框架，并与开发任务和 测试任务相关联。需求团队和开发团队可以通过这个集成的 解决方案一起工作。这种集成方案不仅可以提高需求管理工具的性价比，还可 以方便工程团队的内部沟通。开发团队可以及时获得需求信 息；需求分析师可以通过查看需求的进度来确定可能的需求 变化；管理人员还可以通过查询、图表等功能浏览开发工程 的进度。能够实现上述目标的需求管理工具应该具有以下功 能：集成的需求管理

5、：创立、管理、讨论并关联工程需求 和功能；变更控制：当特定的变更发生时自动进行需求版本管 理，并通过工作流引擎来控制需求变更；数字资产管理：需求、功能以及其他重要的数字资产 都需要存储在一个可靠、可扩展、平安的中央资料库中；集成事件跟踪和测试：需求管理与事件跟踪和测试管 理工具集成，以便于工程经理查看与需求相关的开发和测试 工作；Windows客户端和Web客户端：提供Windows客户端和 Web客户端访问方式，保证在固定和移动办公的情况下都能登 录到系统中；定制化的用户界面：提供定制选择，以便于系统管理 员创立自定义的需求和功能界面，如字段标签、字段类型、 下拉菜单项选择项和客户报告等；开

6、放的工作流设置：通过定义工作流来创立和管理需 求和功能；嵌入式报表和分析：直接产生需求功能数据报表，如变更控制、变更效应、实施和测试数据等;自动获取需求：在系统中，用户可以直接输入需求信息，或者通过文档形式获得需求并附加到系统中。在独立实现以上功能的基础上，需求管理工具还需与ALM 中的开发过程进行无缝集成，其中包含事件跟踪、测试管 理、以及中央知识库（如图1所示）。规范点驱动的需求管理诚然，需求管理对整个软件工程的成败发挥着举足轻重 的作用。然而，需求在最初只是客户或管理人员对产品功能的一种愿望，需求分析师要将这种非结构化、粗线条、不明 确的愿望归纳总结为具体的规范点(Specificati

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

8、管理上的优势主要表达为以下三个方 面。首先，通过SpecDD模型可以实现对需求的度量和评估， 包括每个需求所需要的资源和时间，将开发所需的时间和费 用与需求相关联，度量和评估需求是否成功，通过需求验证 指标来管理开发、测试活动。其次，Spec与工程规划、开发 和测试任务始终保持关联，这就保证了开发的每一个环节都 是可追溯。另外，SpecDD模型还能评估需求变更的潜在影 响，例如需求变更对开发和测试工作、工程本钱的影响。通常情况下，Spec包含功能、缺陷和功能增强三个局部，他们都来源于相关的知识或需求，并与需求条目和知识 库中的知识条目相关联。图2以Browser 6.0产品为例，用 图形化的方

9、式显示了 Spec与知识、需求的关系。针对 Browser产品的最新版本6. 0,有平安和用户界面两大类需 求，通过需求分析师将其分解为新的功能，如支持SSL v. 3. 0 Tabbed Browsing等;除新功能以外，Spec还包括对 之前版本的功能增强，如保存已标记的文件；以及上一版本的缺陷，如保存时响应缓慢。这些Spec通过规划、编码、测 试等工作，构成最终交付的产品。同时，Spec也是高度结构化的，表现为其树形结构准确 对应产品/版本功能树，以保证开发人员不丧失任何需求（如 图3所示）。产品管理团队通过创立Spec树，使每个功能/ 缺陷/功能增强都能对应分支上的树叶。同时，Spec

10、与知识项 目相关联，这些知识工程描述了形成此Spec的构思，以及其 他相关的文档、标准、附件和参考工程。需求变更的管理理解需求变更的可能影响，并有效地控制它们，对于软件 的最终提交至关重要。无论是改变现有的需求还是增加新的 需求，都会不同程度地影响工程最终交付的进度。例如，需 求的变化可能会影响相关的功能、任务和测试工作；编码的 延迟会延迟与该功能相关的其他开发任务和测试工作。因 此，一个有效的需求管理工具必须确保工程团队能够容易地 评估这些变更的可能影响。如何在变更发生之前对其进行评估呢？这就需要将需求 管理与所有开发、测试行为进行集成，用户就可以通过跟踪 编码、测试等行为对变更带来的潜在影

11、响进行评估。这在 SpecDD模型中得以实现。将有效的变更转变为需求如前文所讲，SpecDD模型表现为用Spec来表述/定义产 品或版本功能，并和整个团队有效共享，从而驱动开发。因 此，要保证交付的产品完全符合最终版本的Spec,需求分析 部门就要和开发部门协同工作，并对变更做出严格的控制。 对开发工作有潜在影响的变更都将会被慎重管理，并严格检 验是否影响到需求的依赖关系。所有因需求变更而产生的影响，都必须检验变更后的完整性。因此，要实现有效的需求 变更，管理工具需要实现以下几种功能：变更控制对变更进行严格的流程控制，包括请求、复查、讨论、 调整和批准等；变更请求由一个独立的工作流所控制；变更

12、不能对需求造成不良影响，因此在变更被批准之前，需求不能被改变。实用性 接近实际的需求管理实践； 易于被客户理解；易于对重要的变更进行跟踪。各部门协同工作 需求、功能和开发等各方面 的人员都在各个阶段参与变更请求，将不同部门的人员都纳 入变更管理体系；让开发团队参与到变更请求的批准过程中，这样会比被动的接受或拒绝变更要更科学、更有 效；在变更得到批准或拒绝之前，分析针对该变更在资源和时间上的分配。科学的需求管理是软件工程成功的保证。在更新需求的过 程中，工程的所有相关人员都应该从各自的角色参与其中， 这将促进软件产品最终实现业务目标。当需求发生变化时， 准确的分析和评估也将有助于确保工程按时提交

13、。除需求管理工具独立工作以外，将它与应用生命周期管 理（ALM）中的其他过程管理工具集成，才能最终提供一个完 整的贯穿需求和开发过程的解决方案。需求分析人员和开发 团队通过一个平台实现协同工作，统一接口和共用流程。这 就能促进需求数据在需求制造者和实施者之间无缝、实时的 传递，并保证在开发的每一个环节都可追溯需求。如前文所讲，SpecDD模型表现为用Spec来表述/定义产 品或版本功能，并和整个团队有效共享，从而驱动开发。因此，要保证交付的产品完全符合最终版本的Spec,需求分析 部门就要和开发部门协同工作，并对变更做出严格的控制。 对开发工作有潜在影响的变更都将会被慎重管理，并严格检 验是否

14、影响到需求的依赖关系。所有因需求变更而产生的影 响，都必须检验变更后的完整性。因此，要实现有效的需求 变更，管理工具需要实现以下几种功能：变更控制 对变更进行严格的流程控制，包括 请求、复查、讨论、调整和批准等；变更请求由一个独立的工作流所控制；变更不能对需求造成不良影响，因此在变更被批准之前，需求不能被改变。 实用性 接近实际的需 求管理实践； 易于被客户理解； 易于对重 要的变更进行跟踪。各部门协同工作需求、功能和开发等各方面的人员都在各个阶段参与变更请求，将不同部门的人员都纳 准过程中，这样会比被动的接受或拒绝变更要更科学、更有入变更管理体系;让开发团队参与到变更请求的批在变更得到批准或拒绝之前，分析针对该变更在资源和时间上的分配。科学的需求管理是软件工程成功的保证。在更新需求的过 程中，工程的所有