CMMI指导需求管理

1、cmmi指导需求管理能力成熟度模型集成（cmml capabi 1 itymaturitymodelintegration）已逐步成为it业的标准。cmmi定义了 5个组织成熟度级别，包含25个过程域（pa,processarea）,这些过程域全面涵盖了软件生命周期的各个领域。特别是 在业界普遍感到难以控制的需求方面，它定义了两个过程域：需求管理和需求开 发。 需求管理（reqm,requirementsmanagement）属于成熟度2级（受管理 级）的过程域，是其它许多过程域实施的前提。对于暂未实施cmmi的企业，同 样也可以借鉴cmmi的原则，实施和优化需求管理。本文从实际工作的角度，阐

2、 述如何用cmmi指导需求管理工作。一、需求管理概述 许多it企业都有过需求失控的痛苦经历，我们不难体会，没有好的需求管理会给我们带來什么: 需求以失控的状态进入软件过程，从源头上失去了项目的质量保证；需求范围界定不清，使项目缺乏计划性，导致成本、研制周期失控；需求变更失控，使组织处于被动反应式的环境屮，项冃组成为救火队；需求管理不当，导致项冃延期、士气低落，增加了项冃的失败风险； 为了避 免上述情况的出现，cmmi对需求管理提出了明确的冃的：一是管理项冃的产品 和产品构件的需求；二是标识哪些需求与项fl计划及t作产品z间不一致。通过 适当的步骤，确保需求在项冃的各个层面上动态地保持一致，一旦

3、出现不一致， 则启动相关的处理过程域，使其调整到一致。需求管理包含5个特定实践（sp,specificpractice）,这5个特定实践的关系。获得对需求的理解。需求接收者与需求提供者就需求达成共识。获取项r参与者对需求的承诺。通过书面承诺，建立各方、各项工作的基准。管理需求变更。维护变更历史，为调整与控制提供数据。维护对需求的双向可追溯性。这是从软件的可维护性角度提出的管理要求。标识项目计划和工作产品与需求的不一致性。旨 在发现不一致性，并且启动纠正措施。 二、需求管理计划 在组织级建 立需求管理计划模板，具体项忖则是在此模板的基础上结合项h的特点和具体情 况，制定项忖的需求管理计划。需求管

4、理计划（模板）应包括如下内容：需求管理的方针与政策；需求管理需使用的资源（管理人员、计算机资源、使用工具等）；角色与责任；培训计划；需求管理的干系人及介入事件的关联矩阵；配合项冃节奏或里程碑的事项（如：在哪些阶段点应做“识别项h工作与需求之间的不一致的工作”）:判断项h工作与需求不一致的准则和纠止流程；需求溯源性矩阵模板（最好使用工具）；需求变更流程；需求管理计划的审批与变更流程；其它流程。具体项 id的需求管理计划一般应在如下几个方面加以具体化：项h的需求管理角色应 分派到具体的人；可根据项h需求管理人员的实际情况，安排有针对性的培训 内容，如应用领域的业务培训、需求管理t具的培训等；需求管

5、理的干系人及 介入事件更加明确。如与需求管理相关的人员（干系人）主耍有业务代表（代表 业务需求提出部门）、设计人员、开发人员、测试人员等，当需求具有跨系统或 接口性质时，相关受影响的部门应列入干系人清单小。介入的事件是评估需求变 更的影响、通报双向溯源性情况、识别项h工作与需求z间的不一致。 三、 需求管理流程 各企业可根据口己的组织结构制定需求管理流程，但流程必 须涵盖上述5个特定实践，对于具体项目一般应用组织级的需求管理流程，项目 的特殊事项可以放在需求管理计划中进行描述。 需求管理流程可以由儿个 子流程组成，有些子流程可以并行工作，有些子流程还与其它过程域的流程有关。 首先，“获得对需求

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

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

8、溯性”和“标识项目计划和工作产品与需求 的不一致性”，一般分散在其它相关流程中，并贯穿于整个软件生命周期中。例 如，定期或以事件触发方式启动“标识项口计划和工作产品与需求的不一致性”， 检查是否一致，从而进行相应处理。 流程的具体编制依赖于组织结构（同时 它也影响着组织结构），因此，不同的组织需要制定自己的流程。组织流程一般 是跨过程域的综合流程，在制定流程前，应充分了解过程域之间的依赖关系，只 有这样，才能将这些关系有机地融合到流程小。这些相关的过程域可能分属于不 同的成熟度级别，因此，可能在现有条件下没有实施较高级别的过程域，这时我 们可以“弱化”这些不能实现的过程域，即只取其必要的功能放

9、到流程中去。我 们将“需求开发”过程域弱化成“需求分析”（“需求管理”要求“需求开发” 提供必要的功能）放到流程中。 总之，掌握过程域之间的关系，对编制流 程很有帮助。这里我们总结出需求管理与其它过程域的主耍关系。 （1）需 求管理依赖的过程域 需求开发：通过需求开发建立和维护客户产品、产 品部件和接口需求。配置管理：通过配置管理控制需求的变更。 项冃 监督和控制：通过监督和控制识别需求与项冃计划、丁作产品的矛盾。 （2） 依赖于需求管理的过程域 需求开发：通过需求管理来管理客户和产品需 求，获得需求供应者的同意和需求实现者的承诺，并使需求的维护可追溯。技术解决方案：通过需求管理为产品和产品部

10、件管理需求。 产品集成： 通过需求管理来管理接口需求的变更。 项忖计划：根据需求管理来制定 计划和更改计划。 验证和确认：根据需求管理维护需求。 供应商 合同管理：根据需求管理确能能被外部满足的需求并管理可追溯的需求，这些需 求来源于供应商已经完成的产品。 卩q、需求管理工具化 需求管理的工 具包括：需求及相关文档管理的工具；流程审批的流转电子化；溯源性矩 阵的维护工具。其中最人的难点是需求溯源性矩阵的维护t具，对此我们作重点 分析。 需求溯源包括的三个方面，可看作是三个子矩阵，每个子炬阵对某 个方面都具有双向溯源性。 1.需求向低层分解的双向溯源矩阵 2.需求沿生命周期纵向产品溯源矩阵3.需

11、求的水平溯源矩阵（跨系统功能间）当需求影响到多个系统时，就应建立关联功能间的水平溯源关系。综上所述，需求管理要求建立和维护需求双向溯源表，而双向溯源表的关联关系非常复 杂，因此：（1）必须借助工具进行管理。对小的项h，可以用excel等简单工具进行管理，但对大型项忖或组织级的需求管理，则应购买或自行开发专门 的需求管理t具。（2）必须建立一套编码体系，以便进行标识和检索。（3）需求管理工具可以与配置管理工具同吋考虑，即综合设计成一个管理系统。 五、需求管理实施建议 需求管理是基础性的管理，企业必须投入精力，认 真实施，并以此作为实施cmmi的起点。在实施中要注意如下儿点：1培训t作。从以上分析

12、可以看岀，需求管理是一项技术含量高、参与人员多、持续 时间长（从项目前期到项目结束）的管理活动。因此，必须作好相关的培训，通 过培训使高层管理人员了解需求管理的意义，取得他们的支持；使需求管理人员 学会使用工具；使一般员工有需求管理意识，维护好溯源短阵屮与自己相关的部 分，并提高识别项h工作与需求的不一致的能力。2试点工作。应先选几个项目作为试点，取得经验后再全面实施。3.从制度方面进行实施体系的建立，使z制度化。4.监督与控制。质量保证（qa,qualityassutance）人员应根据需求管理计划为基准进行监督与控制，例如，根据需求管理的干系人 及介入事件的关联矩阵，审查“通报双向溯源性情况”是否到位（是否按时通报, 是否有人员遗