第二章 过程域 —— 需求管理
需求管理
成熟度2级的一个工程域
目的
需求管理（REQM）的目的是管理项目产品和产品构件的需求，并且识别需求与项目计划与工作产品之间的矛盾。
介绍
需求管理过程管理所有的接收到的或由项目产生的需求，即包括技术的和非技术的需求也包括由组织施加给项目的需求。确切地说，如果需求制定过程域被执行的话，它的过程将会生成产品和产品构件需求，因此也就需要需求管理过程来管理。当需求管理、需求制定以及技术方案过程域都被执行时，他们相关的过程将会被紧密约束并且紧接着执行。
项目采用适当的步骤以确保已经过协议的需求被管理从而支持计划和完成项目的需要。当一个项目收到来自一个被认可的需求提供者的需求时，这些需求在被合并到项目计划之前会被需求提供者讨论以解决问题和防止误解。一旦需求提供者和需求接收者达成共识，承诺这些需求会被项目的参与者所共享。当这些需求发展和识别出任何发生在计划、工作产品以及需求之间的矛盾时，项目管理需求的变更。
需求管理的一部分工作是文档化需求变更和基本原理以及在原始需求和所有的产品以及产品构件需求之间保持双向可追溯性。
相关过程域
有关将风险承担者的需要转变成产品需求以及决定怎样在产品构件中分配或者描述需求的更多信息请参见需求制定过程域。
有关将需求转化成技术方案的更多信息请参见技术方案过程域。
有关项目计划如何反映需求以及党需求变更时是否需要进行修订的更多信息请参见项目计划过程域。
有关基线和控制变更以配置需求文档的更多信息请参见配置管理过程域。
有关跟踪和控制基于需求的活动和工作产品并且进行适当的改进活动的更多信息请参见项目监督与控制过程域。
有关识别和掌握与需求有关的风险的更多信息请参见风险管理过程域。
实现目标的关键实践
SG1 管理需求
需求已得到管理，并且需求与项目计划、工作产品之间的矛盾已被识别。
在项目生命周期之内，项目通过如下工作维持一组当前并且适当的需求：
l 管理所有的需求
l 维持需求、计划和工作产品间的关系
l 识别需求、计划和工作产品间的矛盾
l 获得纠正的活动
有关判断需求可行性的的更多信息请参见技术方案过程域。
有关确保需求符合客户需要和期望的更多信息请参见需求制定过程域。
有关获取纠正的活动的更多信息请参见项目监督与控制过程域。
实践－目标关系表
| 连续式 |
分级式 |
| SG1 需求管理 |
SG1需求管理 |
| SP1.1-1取得对需求的理解 |
SP1.1-1取得对需求的理解 |
| SP1.2-2取得需求承诺 |
SP1.2-2取得需求承诺 |
| SP1.3-1管理需求变更 |
SP1.3-1管理需求变更 |
| SP1.4-2保持需求的双向可追溯性 |
SP1.4-2保持需求的双向可追溯性 |
| SP1.5-1识别项目工作和需求之间的矛盾 |
SP1.5-1识别项目工作和需求之间的矛盾 |
| GG1 达到特定目标 |
|
| GP1.1 完成基础实践 |
|
| GG2 制度化一个已管理的过程 |
GG2 制度化一个已管理的过程 |
| GP2.1建立组织的方针 |
GP2.1建立组织的方针 |
| GP2.2 计划过程 |
GP2.2 计划过程 |
| GP2.3 提供资源 |
GP2.3 提供资源 |
| GP2.4 分配职责 |
GP2.4 分配职责 |
| GP2.5 培训人员 |
GP2.5 培训人员 |
| GP2.6 管理配置 |
GP2.6 管理配置 |
| GP2.7 识别和包括相关的风险承担者 |
GP2.7 识别和包括相关的风险承担者 |
| GP2.8 监督和控制这个过程 |
GP2.8 监督和控制这个过程 |
| GP2.9 客观的评价坚持状况 |
GP2.9 客观的评价坚持状况 |
| GP2.10 以更高等级的管理回顾状态 |
GP2.10 以更高等级的管理回顾状态 |
| GG3 制度化已定义的过程 |
|
| GP3.1 建立一个已定义的过程 |
GP3.1 建立一个已定义的过程 |
| GP3.2 收集改进信息 |
GP3.2 收集改进信息 |
| GG4 制度化一个已量化管理的过程 |
|
| GP4.1 建立过程的量化目标 |
|
| GP4.2 稳定子过程的执行 |
|
| GG5 制度化一个优化中的过程 |
|
| GP5.1 保证连续的过程改进 |
|
| GP5.2 改正问题的根源 |
|
| 对于软件工程
需求或许是整个产品需求的一个组成部分或者也可能组成全部的的产品需求。 |
| 对于系统工程
每一级别的产品构件设计（例如，模块，子系统）接收来自更高等级的需求。 |
SP1.1-1取得对需求的理解
理解需求提出者（提出）需求的确切意图。
当项目成熟和需求被导出的时候，所有的应用或者模块都会收到需求。为了防止需求蔓延，要建立标准指定适当的渠道或正式的来源用于接收需求。接收需求活动引导需求提供者对需求的分析，以确保对其的理解和需求的含义保持一致。分析和讨论的结果是对需求达成某种协议。
典型工作产品
1. 不同的合适的需求提供者的标准清单
2. 需求评估和接受的标准
3. 根据标准分析的结果
4. 经过协商的需求
子实践
1. 建立不同的合适的需求提供者的标准清单
2. 建立对需求接受的客观标准
接收标准的缺乏经常导致不适当的确认，昂贵的重作或者客户的拒绝。
| 接收标准示例如下： l 清晰适当的规定 l 完整 l 相互一致 l 唯一识别 l 适合执行 l 可验证（可测试） l 可跟踪 |
3. 分析需求以确保建立的标准是适宜的
4. 和需求提供者达到对需求的共识从而使项目参与者能够答应对这些需求负责。
SP1.2-2取得需求承诺
取得项目成员对需求的承诺。
有关监督承诺构成的更多信息请参见项目监督与控制过程域。
| 对于综合的产品和过程制定
当综合团队形成时，项目成员是完整的团队和其成员。相互关联的综合团队之间的需求承诺对每一个综合团队来说和对产品以及项目需求的承诺都很重要。 |
尽管前面的关键实践是为了和需求提供者达到共识，然而这个关键实践是为了在那些不得不执行对执行需求有必要的活动的人员之间达成协议和承诺。需求发展贯穿整个项目过程，尤其像需求制定过程域和技术方案过程域的关键实践所描述的。当需求发展了，这个关键实践要确保项目成员获得当前的、经核准的需求以及项目计划、活动和工作产品的最终变化。
典型工作产品
1. 需求对估计成本的影响
2. 对需求和需求变更文档化的承诺
子实践
1. 评估需求对现存承诺的影响
当需求变更或者一个新需求被提出来时，对项目成员的影响应该被估计。
2. 磋商和记录承诺
对现有承诺的改变在项目成员接受到需求或者需求变更之前应该经过协商。
SP1.3-1管理需求变更
管理项目进展中需求的更改。
有关维持和控制需求基线和制造需求以及变更对项目有效的数据的更多信息请参见配置管理过程域。
项目期间，需求变更有多种原因。工作只要进行需要就会改变，不是新的需求被提出来，就是现有的需求可能要变化。有效地有力的管理这些额外增加和变更的需求是最基本的。为了有效地分析变更带来的影响，有必要知道每一个需求的来源和记载任何变化的相互关联。项目管理者可能，不管用何种方法，希望适当的跟踪需求扩散的度量方法从而判断是否需要新的或者经过修订的控制。
典型工作产品
1. 需求状态
2. 需求数据库
3. 需求决议数据库
子实践
1. 捕获所有收集或者项目产生的需求和需求变更。
2. 用变更之间的基本原理维持需求变更历史。
维持需求变更历史可以帮助跟踪需求的扩散。
3. 从相关风险承担者的角度评价需求变更的影响。
4. 使需求和变更数据对于项目可用。
SP1.4-2保持需求的双向可追溯性
保持需求与项目计划、工作产品相互之间的双向可追溯性。
这个特殊实践的意图是为每一级产品分解的需求保持其双向可追溯性。当需求被管理得很好时，可追溯性能够被建立从而实现从原始需求到它的更低级的需求并且从更低级的需求返回到它们的来源。这样的双向可追溯性帮助判断所有的原始需求已经完整地被标记并且所有的更低级的需求能够被跟踪到一个有效的来源。需求可追溯性也能够包含于其他实体的关系，例如媒介和最终工作产品、设计文档的变更、测试计划以及工作任务。可追溯性即可以包含横向的也可以包含纵向的关系，例如交叉界面。可追溯性在对需求变更对项目计划、活动和工作产品带来的影响进行评估时尤为重要。
典型工作产品
1. 需求跟踪矩阵
2. 需求跟踪系统
子实践
1. 保持需求可追溯性从而确保更低级别（导出）的需求的来源被写成文档。
2. 保持需求可追溯性从一个需求到它导出的需求并且分配到功能、对象、人员、过程和工作产品。
3. 保持功能到功能和交叉界面的横向可追溯性。
4. 生成需求跟踪矩阵。
SP1.5-1识别项目工作和需求之间的矛盾
识别项目计划、工作产品与需求之间的矛盾。
有关监督和控制项目计划和工作产品与需求的一致性并且在必要时纠正活动的更多信息请参见项目监督与控制过程域。
这个关键实践发现需求和项目计划以及工作产品之间的矛盾，并且开始纠正的活动去消除这些矛盾。
典型工作产品
1. 记载包括来源、条件和基本原理等矛盾的文档
2. 纠正的活动
子实践
1. 回顾项目计划、活动和工作产品与需求的一致性和它们所作的变更。
2. 识别矛盾的来源和基本原理。
3. 识别因为对需求基线的变更而导致的需要对计划和工作产品所作的变更。
4. 开始纠正的活动。
目标的一般实践
| GG1 完成特定目标
通过将可识别的输入工作产品转变为可识别的输出工作产品，过程支持并且能够使过程域的特定目标实现。
GP1.1 履行基本实践
履行原因分析和决策过程的基本实践从而发展工作产品和提供达到过程域的特殊目标的服务。 |
仅仅适用于连续式 |
GG2 制度化一个已管理的过程
过程被作为一个已管理的过程制度化。
执行的保障
GP2.1 建立组织的方针
建立和维持一个用于计划和执行需求管理过程的组织性方针。
详尽的细节
这个方针建立了对管理需求和识别需求与项目计划和工作产品之间矛盾的组织性的期望。
执行的能力
GP2.2计划过程
建立和维持一个用于执行需求管理过程的计划。
详尽的细节
具有代表性的，执行需求管理过程的计划是在项目计划过程域中描述的项目计划中的一部分。
GP2.3 提供资源
提供足够的资源用于执行需求管理过程，开发工作产品，以及提供过程的服务。
详尽的细节
| 提供的资源包括如下工具所示： l 需求跟踪工具 l 可追溯工具 |
GP2.4 分配职责
分配执行过程，开发工作产品以及提供需求管理过程服务的职责。
GP2.5 培训人员
必须培训执行和支持需求管理过程的人员。
详尽的细节
| 培训主题示例如下： l 应用的范围 l 需求定义、分析、回顾和管理 l 需求管理工具 l 配置管理 l 协商和冲突方案 |
引导（过程的）执行
GP2.6 管理配置
给需求管理过程中的指定工作产品以适宜的配置管理水平。
详尽的细节
| 在配置管理下存放的工作产品示例如下： l 需求 l 需求跟踪矩阵 |
GP2.7 识别和包含相关的风险承担者
对照计划，识别和包含需求管理过程的相关风险承担者。
详尽的细节
从客户、最终用户、开发者、生产者、测试人员、供应商、市场人员、维护人员、配置人员和其他可能被影响或者产生影响的人中选择相关的风险承担者。产品既是过程。
| 风险承担者的活动示例如下： l 对需求的理解解决争议 l 评估需求变更的影响 l 传达双向可追溯性 l 识别项目计划、工作产品以及需求之间的矛盾 |
GP2.8 监督与控制过程
根据计划监督与控制原因分析与决策过程，从而执行过程并进行适当的纠正活动。
详尽的细节
| 用于监督与控制的度量方法示例如下： l 需求的扩散（需求变更的百分率） |
验证（过程的）执行
GP2.9 客观的评价坚持状况
对照过程的描述、规则、程序，客观评估需求管理过程的坚持状况，并处理未按此执行的相关事宜。
详尽的细节
| 回顾活动示例如下： l 管理需求 l 识别项目计划、工作产品以及需求之间的矛盾 |
| 工作产物回顾示例如下： l 需求 l 需求跟踪矩阵 |
GP2.10 用更高等级的管理回顾状态
用更高层次的管理回顾需求管理过程中的活动、状态、和结果，并解决问题。
详尽的细节
对组织提出的额外的变更要用更高层次的管理来惠顾从而确保所有的委托事项都能够被完成。
| 编者按：GG3和它的实践不应用于成熟度2级阶段，而是应用于3级及以上阶段。
|
仅仅适用于分级式 |
| GG3 制度化一个已定义的过程
过程被作为一个已定义的过程制度化。
执行的能力
GP3.1 建立一个已定义的过程
建立和维持一个已定义的需求管理过程的描述。
引导（过程的）执行
GP3.2收集改进信息
收集工作产品、度量方法、度量结果以及源于计划和执行需求管理过程的改进信息，从而支持将来的使用以及组织过程和过程域的改进。 |
连续式/成熟度3-5级 |
| GG4 制度化一个集成的已管理的过程
过程是作为一个集成的已管理的过程被制度化的。
GP4.1 为过程建立集成目标
为需求管理过程建立和维持集成目标从而明确质量和过程执行是基于客户需求和商业目标的。
GP4.2 稳定子过程执行
稳定一个或多个子过程的执行从而确定需求管理过程的能力以达到建立的集成质量和过程执行目标。
GG5 制度化一个已优化的过程
过程是作为一个已优化的过程被制度化的。
GP5.1 确保连续的过程改进
在完成组织的相关商业目标过程中确保连续的需求管理过程改进。
GP4.2 纠正问题的根源原因
在需求管理过程中识别和纠正缺陷和其他问题的根源原因。
|
仅仅适用于连续式 |