SG 1 管理需求

需求得到管理，与项目计划和工作产品间的不一致得到识别。

项目通过以下活动来在整个项目期间维护当前已批准的需求集：

• 管理所有需求变更

• 维护需求、项目计划与工作产品之间的关联关系

• 确保需求、项目计划与工作产品之间的协调一致

• 采取纠正措施

参阅“需求开发”过程域，以进一步了解如何分析并确认需求。

参阅“技术解决方案”过程域，中的“开发备选解决方案和选择准则”特定实践以进一步了解如何确定需求的可行性。

参阅“项目监督与控制”过程域，以进一步了解如何管理纠正措施直至关闭。

SP 1.1 理解需求

与需求提供方一起达成对需求含义的理解。

随着项目的逐步成熟和需求的产生，所有的项目活动或专业领域将接收需求。为避免需求蔓延，应建立准则来指定接收需求的适当渠道或官方来源。需求接收方与提供方一起对需求进行分析，以确保对于需求的含义达成一个相容的、共同的理解。这些分析和对话的结果是已批准的需求集。

CMMI模型中，REQM过程域的工作产品实例：

1. 区分适当的需求提供方的准则列表

2. 评价与验收需求的准则

3. 基于准则的分析结果

4. 已批准的的需求集

CMMI模型中，REQM过程域的子实践：

1. 建立区分适当的需求提供方的准则。

2. 建立评价与验收需求的客观准则。

缺少评价与验收需求的准则通常会导致不充分的验证、代价高昂的返工或客户的拒绝。

评价与验收准则的实例有：

• 描述清晰而适当

• 完整

• 彼此一致

• 可唯一识别

• 与架构方法与质量属性的优先级划分相一致

• 适于实现

• 可验证（即可测试）

• 可追溯

• 可实现

• 与业务价值结合紧密

• 被认定为客户的一个高优先级需求

3. 分析需求以确保建立的准则得到了满足。

4. 与需求提供方达成对需求的理解，从而使项目参与者能够对其作出承诺。

SP 1.2 获得对需求的承诺

获得项目参与者对需求的承诺。

参阅“项目监督与控制”过程域，以进一步了解如何监督承诺。

前一条特定实践处理的是与需求提供方达成对需求的理解。本特定实践处理的是在执行必要的需求实现活动的人员之间达成一致与承诺。需求在项目期间会逐渐演变。本特定实践确保项目参与者随着需求的演变，对当前的、已批准的需求及其导致的项目计划、活动与工作产品的变更作出承诺。

CMMI模型中，REQM过程域的工作产品实例：

1. 需求影响评估

2. 对需求与需求变更的文档化的承诺

CMMI模型中，REQM过程域的子实践：

1. 评估需求对已有承诺的影响。

当需求变更或新需求产生时，应评价其对项目参与者的影响。

2. 协商并记录承诺。

在项目参与者对新需求或需求变更作出承诺前，应先协商对既有承诺的变更。

SP 1.3 管理需求变更

随着项目进行中需求的演变，对需求变更进行管理。

参阅“配置管理”过程域，以进一步了解如何跟踪并控制变更。

需求变更有各种原因。随着要求的变化与工作的进展，可能必须对已有需求进行变更。有必要高效而有效地管理这些新增需求与变更。为有效地分析变更的影响，有必要了解每个需求的来源，并将变更的依据文档化。项目可能要对需求易变性的适当的度量项进行跟踪，以判断是否有必要采用新的变更控制方法或修订已有的变更控制方法。

CMMI模型中，REQM过程域的工作产品实例：

1. 需求变更请求

2. 需求变更影响报告

3. 需求状态

4. 需求数据库

CMMI模型中，REQM过程域的子实践：

1. 将对项目提出的或由项目产生的所有需求与需求变更文档化。

2. 维护需求变更历史信息，包括变更的依据。

维护变更历史信息有助于跟踪需求易变性。

3. 从相关干系人的立场评价需求变更的影响。

影响产品架构的需求变更可能会对很多干系人产生影响。

4. 确保需求与变更的数据对项目可用。

SP 1.4 维护需求的双向可追溯性

维护需求与工作产品之间的双向可追溯性。

本特定实践旨在维护需求的双向可追溯性（见术语表中“双向可追溯性”的定义。）当需求得到有效管理时，我们能够建立起从源需求到其较低层次需求以及从较低层次需求回溯到源需求的可追溯性。这种双向可追溯性有助于确定是否所有的源需求都得到了完全的处理以及是否所有较低层次需求都可以追溯到一个有效的来源。

需求可追溯性也包括与其它实体如中间的与最终的工作产品、设计文档的变更以及测试计划等的关联。可追溯性既包括垂直关联，也包括水平关联，如接口两端。在评估需求变更对项目活动与工作产品的影响时，可追溯性尤为重要。

可追溯性要考虑的方面，实例有：

• 可追溯性的范围：可追溯性所需的边界

• 可追溯性的定义：需要建立逻辑关联的元素

• 可追溯性的类别：何时需要建立水平与垂直可追溯性

此类双向可追溯性并不总是自动化的。可以用电子表格、数据库及其它通用工具来手工实现。

CMMI模型中，REQM过程域的工作产品实例：

1. 需求可追溯性矩阵

2. 需求跟踪系统

CMMI模型中，REQM过程域的子实践：

1. 维护需求可追溯性，以确保将低等级（即衍生的）需求的来源文档化。

2. 维护从需求到其衍生需求及其在工作产品中的分配的需求可追溯性。

可能需要维护其可追溯性的工作产品包括：架构、产品组件、开发迭代（或增量）、功能、接口、对象、人员、过程及其它工作产品。

3. 创建需求可追溯性矩阵。

SP 1.5 确保项目工作与需求间的协调一致

确保项目计划和工作产品与需求之间保持协调一致。

本特定实践识别需求与项目计划、工作产品之间的不一致，并采取纠正措施来纠正这些问题。

CMMI模型中，REQM过程域的工作产品实例：

1. 需求与项目计划、工作产品之间不一致的记录文档，包括来源与条件

2. 纠正措施

CMMI模型中，REQM过程域的子实践：

1. 评审项目计划、活动以及工作产品与需求及其变更的一致性。

2. 识别不一致的来源（如果有的话）。

3. 识别由需求基线的变更引起的，应对计划与工作产品进行的变更。

4. 启动必要的纠正措施。

【REQM过程域相关文章】

CMMI过程域详解-需求管理（REQM）之概述

CMMI过程域详解-需求管理（REQM）之SG 1