用CMMI指导需求管理

能力成熟度模型集成（CMMI，Capability Maturity Model Integration）已逐步成为IT业的标准。CMMI定义了5个组织成熟度级别，包含25个过程域（PA,Process Area），这些过程域全面涵盖了软件生命周期的各个领域。特别是在业界普遍感到难以控制的需求方面，它定义了两个过程域：需求管理和需求开发。

需求管理（REQM,Requirements Management）属于成熟度2级（受管理级）的过程域，是其他许多过程域实施的前提。对于暂未实施CMMI的企业，同样也可以借鉴CMMI的原则，实施和优化需求管理。本文从实际工作的角度，阐述如何用CMMI指导需求管理工作。

一、需求管理概述

许多IT企业都有过需求失控的痛苦经历，我们不难体会，没有好的需求管理会给我们带来什么：

    需求以失控的状态进入软件过程，从源头上失去了项目的质量保证；

    需求范围界定不清，使项目缺乏计划性，导致成本、研制周期失控；

    需求变更失控，使组织处于被动反应式的环境中，项目组成为救火队；

    需求管理不当，导致项目延期、士气低落，增加了项目的失败风险；

    ……

为了避免上述情况的出现，CMMI对需求管理提出了明确的目的：一是管理项目的产品和产品构件的需求；二是标识哪些需求与项目计划及工作产品之间不一致。通过适当的步骤，确保需求在项目的各个层面上动态地保持一致，一旦出现不一致，则启动相关的处理过程域，使其调整到一致。

需求管理包含5个特定实践（SP,Specific Practice），这5个特定实践的关系如图1所示。

获得对需求的理解。需求接收者与需求提供者就需求达成共识。 获取项目参与者对需求的承诺。通过书面承诺，建立各方、各项工作的基准。 管理需求变更。维护变更历史，为调整与控制提供数据。 维护对需求的双向可追溯性。这是从软件的可维护性角度提出的管理要求。 标识项目计划和工作产品与需求的不一致性。旨在发现不一致性，并且启动纠正措施。

二、需求管理计划

在组织级建立需求管理计划模板，具体项目则是在此模板的基础上结合项目的特点和具体情况，制定项目的需求管理计划。

需求管理计划（模板）应包括如下内容：

需求管理的方针与政策； 需求管理需使用的资源（管理人员、计算机资源、使用工具等）； 角色与责任； 培训计划； 需求管理的干系人及介入事件的关联矩阵； 配合项目节奏或里程碑的事项（如：在哪些阶段点应做“识别项目工作与需求之间的不一致的工作”）； 判断项目工作与需求不一致的准则和纠正流程； 需求溯源性矩阵模板（最好使用工具）； 需求变更流程； 需求管理计划的审批与变更流程； 其他流程。

具体项目的需求管理计划一般应在如下几个方面加以具体化：①项目的需求管理角色应分派到具体的人；②可根据项目需求管理人员的实际情况，安排有针对性的培训内容，如应用领域的业务培训、需求管理工具的培训等；③需求管理的干系人及介入事件更加明确。如与需求管理相关的人员（干系人）主要有业务代表（代表业务需求提出部门）、设计人员、开发人员、测试人员等，当需求具有跨系统或接口性质时，相关受影响的部门应列入干系人清单中。介入的事件是评估需求变更的影响、通报双向溯源性情况、识别项目工作与需求之间的不一致。

三、需求管理流程

各企业可根据自己的组织结构制定需求管理流程，但流程必须涵盖上述5个特定实践，对于具体项目一般应用组织级的需求管理流程，项目的特殊事项可以放在需求管理计划中进行描述。

需求管理流程可以由几个子流程组成，有些子流程可以并行工作，有些子流程还与其他过程域的流程有关。

首先，“获得对需求的理解”和“获取项目参与者对需求的承诺”两个特定实践可以放到一个流程中实施。将实际流程图进行简化（见图2），可以看出：
①通过一个综合流程可将多个特定实践包含其中。同时，还可以看出需求管理过程域与其他过程域（配置管理、技术开发、项目策划）相关联。
②“获得对需求的理解”要求明确需求的正式来源（总行业务部门）。
③“获得对需求的理解”实际上是进行需求分析、确认需求的过程，它的结果是形成“达成一致”的需求（《软件需求说明书》）。
④“获取项目参与者对需求的承诺”主要包括两个承诺。一是需求方对达成一致的需求（《软件需求说明书》）的正式确认二是开发方以项目目标定义书的方式，对开发计划和成本等作出承诺。

其次，“管理需求变更”中应先进行评估与审批，审批之后应执行“维护对需求的双向可追溯性”和“标识项目计划和工作产品与需求的不一致性”。这两个看上去好象是附加上去的特定实践，其实很重要（不好的需求管理流程中常缺这两个特定实践），其目的是通过流程维护需求变更的历史和理由、评价需求变更的影响，发现不一致并启动相关的处理过程域（进入其他流程）。例如，当变更对项目产生风险时，需要使用其他流程进行风险防范或进行项目计划变更，这些都可以包含在流程中。“管理需求变更”流程需要配置管理过程域的支持（通常是通过配置管理的控制变更来实现对需求变更的控制）。

再次，两个关系密切的特定实践“维护对需求的双向可追溯性”和“标识项目计划和工作产品与需求的不一致性”，一般分散在其他相关流程中，并贯穿于整个软件生命周期中。例如，定期或以事件触发方式启动“标识项目计划和工作产品与需求的不一致性”，检查是否一致，从而进行相应处理。

流程的具体编制依赖于组织结构（同时它也影响着组织结构），因此，不同的组织需要制定自己的流程。组织流程一般是跨过程域的综合流程，在制定流程前，应充分了解过程域之间的依赖关系，只有这样，才能将这些关系有机地融合到流程中。这些相关的过程域可能分属于不同的成熟度级别，因此，可能在现有条件下没有实施较高级别的过程域，这时我们可以“弱化”这些不能实现的过程域，即只取其必要的功能放到流程中去。如图2中，我们将“需求开发”过程域弱化成“需求分析”（“需求管理”要求“需求开发”提供必要的功能）放到流程中。

总之，掌握过程域之间的关系，对编制流程很有帮助。这里我们总结出需求管理与其他过程域的主要关系。

（1）需求管理依赖的过程域
①需求开发：通过需求开发建立和维护客户产品、产品部件和接口需求。
②配置管理：通过配置管理控制需求的变更。
③项目监督和控制：通过监督和控制识别需求与项目计划、工作产品的矛盾。

（2）依赖于需求管理的过程域
①需求开发：通过需求管理来管理客户和产品需求，获得需求供应者的同意和需求实现者的承诺，并使需求的维护可追溯。
②技术解决方案：通过需求管理为产品和产品部件管理需求。
③产品集成：通过需求管理来管理接口需求的变更。
④项目计划：根据需求管理来制定计划和更改计划。
⑤验证和确认：根据需求管理维护需求。
⑥供应商合同管理：根据需求管理确定能被外部满足的需求并管理可追溯的需求，这些需求来源于供应商已经完成的产品。

四、需求管理工具化

需求管理的工具包括：①需求及相关文档管理的工具；②流程审批的流转电子化；③溯源性矩阵的维护工具。其中最大的难点是需求溯源性矩阵的维护工具，对此我们作重点分析。

需求溯源包括的三个方面，可看作是三个子矩阵，每个子矩阵对某个方面都具有双向溯源性。

1．需求向低层分解的双向溯源矩阵

需求向低层分解的双向溯源矩阵，如表1所示。

2．需求沿生命周期纵向产品溯源矩阵

需求沿生命周期纵向产品溯源矩阵，用表2、表3予以说明。
表2中的编号均表示文档的版本号，例如，对于软件需求说明书ＲＳ．1．2，对应有两个系统设计规格书（DM．1．2．1、DM．1．2．2），后一个版本号代表新版本，应作为当前使用版本。该表反映了文档变更历史。

3．需求的水平溯源矩阵（跨系统功能间）

当需求影响到多个系统时，就应建立关联功能间的水平溯源关系（见表4）。
综上所述，需求管理要求建立和维护需求双向溯源表，而双向溯源表的关联关系非常复杂，因此：

（1）必须借助工具进行管理。对小的项目，可以用Excel等简单工具进行管理，但对大型项目或组织级的需求管理，则应购买或自行开发专门的需求管理工具。

（2）必须建立一套编码体系，以便进行标识和检索。

（3）需求管理工具可以与配置管理工具同时考虑，即综合设计成一个管理系统。

五、需求管理实施建议

需求管理是基础性的管理，企业必须投入精力，认真实施，并以此作为实施CMMI的起点。在实施中要注意如下几点：

1．培训工作。从以上分析可以看出，需求管理是一项技术含量高、参与人员多、持续时间长（从项目前期到项目结束）的管理活动。因此，必须作好相关的培训，通过培训使高层管理人员了解需求管理的意义，取得他们的支持；使需求管理人员学会使用工具；使一般员工有需求管理意识，维护好溯源矩阵中与自己相关的部分，并提高识别项目工作与需求的不一致的能力。

2．试点工作。应先选几个项目作为试点，取得经验后再全面实施。

3．从制度方面进行实施体系的建立，使之制度化。

4．监督与控制。质量保证（QA,Quality Assurance）人员应根据需求管理计划为基准进行监督与控制，例如，根据需求管理的干系人及介入事件的关联矩阵，审查“通报双向溯源性情况”是否到位（是否按时通报，是否有人员遗漏）等。

5．评价与审查。一方面对过程的活动、状态及结果进行审查，解决相关问题；另一方面对照要求进行评价与检查，总结经验并处理不符合项。

6．度量。逐步建立度量的指标体系，开始时可只度量完成各项工作的工作量，之后可以作进一步的度量，积累组织的历史数据，供以后进行需求管理的分析、决策等。例如，需求变更比率、因变更造成的延期、需求变更累计数等。

 

原文转自：http://www.ltesting.net