CMMI模型过程域系列学习中文版

Question

来源：http://blog.csai.cn/user2/51384/archives/2009/40444.html    
REQUIREMENTS MANAGEMENT 需求管理

An Engineering Process Area at Maturity Level 2 工程类过程域的成熟度第二级

Purpose 目的

需求管理（REQM）的目的是，管理项目产品与产品组件的需求，并识别这些需求与项目计划和工作产品之间的差异。

Introductory Notes 简介

需求管理过程指的是，管理项目所接收或产生的全部需求，包括技术性和非技术性需求，以及收集的组织对项目的需求。特别指出，一旦实施需求开发过程域，该过程就会产生产品与产品组件需求，这些也要纳入需求管理过程的管理。在整个过程域中，用到术语“产品与产品组件”时，含义也包括服务及其组件的意思。在实施需求管理、需求开发、技术解决方案过程域时，它们的相关过程可能紧密联系在一起，并同步执行。

项目采取适当的步骤，确保被认可的需求集得到管理，以支持项目计划与实施的各项需要。当项目从已批准的需求提供者那里收到需求时，应同需求提供者一起评审该需求，以便在需求纳入项目计划之前，解决有关问题并避免产生误解。一旦需求提供者与需求接收者达成共识，就应获得项目参与者对需求的承诺。随着项目的推进，项目应管理需求的变更，并识别出存在于计划、工作产品与需求之间的差异。
需求管理的一部分内容是指，记录需求变更及其理由，并维持对原始需求、所有产品与产品组件需求二者间的双向跟踪性。
所有的开发项目都有需求。如果一个项目专注于活动的维护，在这种情况下，产品或产品组件需求的变更，是以现有需求、设计或实现为基础的。若需求出现变更，可能记录在客户或用户需求变更中，或者属于从需求开发过程中收到新的需求。不论是何种来源或形式，因需求变更而引起的维护活动，应因此进行相应的管理。

特定实践

SG 1 Manage Requirements 管理需求
管理需求，并识别需求与项目计划和工作产品之间的差异。
项目在其生命周期中，维护一组经过批准的现有的需求，主要是通过采取下列活动完成：
? 管理所有的需求变更
? 维护需求、项目计划与工作产品之间的关系
? 识别需求、项目计划与工作产品之间的差异
? 采取纠正措施

SP 1.1 Obtain an Understanding of Requirements 获得对需求的了解
设法了解需求提供者提出的需求的含义。
随着项目的成熟和各种需求的派生，所有的各项活动或工程学科都要接收相应的需求。为避免需求的蔓延，要建立一定的标准，指定接收需求的适当渠道或正式来源。接收需求的活动，是与需求提供者一起就需求进行分析，以确保对需求的含义达成共识。分析与沟通的结果，是一组被认可的需求。

    典型的工作产品
    1. 区别适合的需求提供者的标准清单
    2. 评审和接收需求的标准
    3. 依据标准的分析结果
    4. 一组被认可的需求

    子实践
    1. 建立辨别合理的需求提出者的标准。
    2. 建立用于评审和验收需求的客观标准。
    缺乏评估和验收标准，通常会导致验证不充分，重大的返工，或者客户拒绝验收。
    评估和验收标准，包含以下因素：
    * 表述明确、恰当
    * 完整
    * 一致性
    * 唯一性
    * 适合执行
    * 可验证的（可测试的）
    * 可跟踪性
    3. 分析需求，确保符合已建立的标准。
    4. 就需求与需求提供者达成共识，使项目参与者能够对它们做出承诺。

SP 1.2 Obtain Commitment to Requirements 获得对需求的承诺
获得项目参与者对需求的承诺。
上一个特定实践用于处理如何与需求提供者达成共识，本特定实践则处理如何取得项目成员的同意与承诺，这些项目成员是指负责实施必要的活动以执行需求的人员。在整个项目期间，需求会逐渐开发，尤其像需求开发过程域与技术解决方案过程域的特定实践所描述的那样。随着需求的逐渐开发，本特定实践可以确保项目参与者对当前已批准的需求，以及对项目计划、活动和工作产品的变更结果，做出承诺。

    典型的工作产品
    1. 需求影响评估
    2. 对需求和需求变更的承诺记录

    子实践
    1. 评估需求对现有承诺的影响。
    当需求发生变更时，或者出现新的需求时，应该评估对项目参与者有哪些影响。
    2. 协商并记录承诺。
    在项目参与者对新需求或需求变更做出承诺之前，应该针对现有的承诺出现了哪些变更进行协商。

SP 1.3 Manage Requirements Changes 管理需求变更
随着需求在项目期间逐步得到开发，对需求的变更进行管理。
在项目推进期间，需求可能由于各种原因发生变更。随着需要发生变更，以及工作的推进，将会产生一些附加的需求，因此可能要对现有的需求做出相应的变更。有效地管理这些附加的需求和需求变更是非常重要的。为了有效地分析这些变更的影响，有必要了解每个需求的来源和变更的理由，并将变更记录成文件。项目经理或许希望跟踪需求变更的适当度量值，以判断是否需要采取新的或修订现有的控制措施，这是非常必要的。

    典型的工作产品
    1. 需求状态
    2. 需求数据库
    3. 需求决策数据库

    子实践
    1. 将所有的需求与需求变更形成文件，不论是外界要求的或是由项目自身产生。
    2. 维护需求变更的历史及变更的理由。
    维护变更的历史，有助于跟踪需求的波动性。
    3. 从相关干系人的立场出发，评估需求变更的影响。
    4. 保证需求与变更数据可供项目使用。

SP 1.4 Maintain Bidirectional Traceability of Requirements 维护需求的双向可跟踪性
维护需求与工作产品之间的双向可跟踪性。
本特定实践的目的在于，维护每个等级产品组件需求的双向可跟踪性。当需求得到良好的管理，就可以建立从原始需求到较低层次需求的可跟踪性，以及从较低层次需求回到他们原始需求的可跟踪性。这种双向跟踪性有助于判断是否所有的需求都得到处理，是否所有低层需求都可以跟踪到一个有效的来源。
需求的可跟踪性也可以涵盖与其他实体的关系，例如：中间和最终工作产品、设计文件的变更、测试计划。可跟踪性包括水平关系，如跨接口；也包括垂直关系。在评估需求变更对项目活动和工作产品产生的影响时，尤其需要可跟踪性。

    典型的工作产品
    1. 需求跟踪矩阵
    2. 需求跟踪系统

    子实践
    1. 维护需求的可跟踪性，确保较低层次（或派生）需求的来源被记录成文件。
    2. 维护需求的可跟踪性，从需求到派生需求，以及从需求分配到功能、接口、目标、人员、过程及工作产品。
    3. 制作需求跟踪矩阵。

SP 1.5 Identify Inconsistencies Between Project Work and Requirements 识别项目工作与需求间的差异
识别项目计划和工作产品与需求之间的差异。
本特定实践在于发现需求与项目计划和工作产品之间的差异，并启动纠正措施进行修正。

    典型的工作产品
    1. 差异性的文档化，包括来源、条件、理由
    2. 纠正措施

    子实践
    1. 评审项目计划、活动和工作产品，查看它们是否与需求及需求变更相符。
    2. 识别差异的来源和理由。
    3. 识别由于需求基线的变更，而导致需要对计划和工作产品做出的变更。
    4. 启动纠正措施。