需求管理计划

需求管理计划

版本

修订历史记录

目 录

1. 简介

1.1 1.2 1.3 1.4 1.5

目的 范围

定义、首字母缩写词和缩略语 参考资料 概述

4 4 4 4 4 4 4 5 5 5 5 5 6 6 6 6 6 6 6 6 6 7 8 8 8 9 9 9 9

2. 需求工件与需求类型 3. 需求属性

3.1

的属性 3.1.1 状态 3.1.2 价值 3.1.3 工作量 3.1.4 风险 3.1.5 稳定性

3.1.6 目标发布版 3.1.7 职责分配 3.1.8 原因

4. 可追踪性标准

4.1 4.2

需求之间的追踪

需求和后续开发的追踪

5. 需求管理团队 6. 需求开发与管理计划 7. 需求管理工作指南

7.1 7.2 7.3 7.4 7.5 7.6

需求工程过程 需求开发过程 定义需求属性

定义需求跟踪矩阵 需求版本控制过程 变更管理过程

需求管理计划

1.

简介

[需求管理计划的简介应提供整个文档的概述。其中应包括此需求管理计划的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。] 1.1

目的

[阐明本需求管理计划的目的。] 1.2

范围

[简要说明此需求管理计划的范围、与它相关的项目，以及受到此文档影响的其他任何事物。] 1.3

定义、首字母缩写词和缩略语

[本小节应提供正确解释此需求管理计划所需的全部术语的定义、首字母缩写词和缩略语。 这些信息可以通过引用项目词汇表来提供。] 1.4

参考资料

[本小节应完整列出此需求管理计划中其他部分所引用的任何文档。每个文档应标有标题、报告号（如果适用）、日期和出版单位。列出可从中获取这些参考资料的来源。这些信息可以通过引用附录或其他文档来提供。] 1.5

概述

[此小节应说明需求管理计划其他部分所包含的内容，并解释该文档的组织方式。]

2. 需求工件与需求类型

3.

3.1

需求属性

的属性

3.1.1 状态

有需求管理人员设置。

3.1.2 价值

由营销经理、产品经理或业务分析员设置。并非所有需求都同等重要。通过按照各项需求对最终用户的相对利益来划分其等级，可以促使客户、分析员和开发团队成员相互交换意见。用于管理规模并确定开发的优先级。

3.1.3 工作量

由开发团队设置。由于有些特性所需的时间和资源多于其他特性，所以在评测复杂程度并预计在给定时间范围内能否完成哪些工作时，最佳的方式就是估计团队工作周数或个人工作周数、所需的代码行数或功能点数

（举例来说）。用于管理规模并确定开发的优先级。 3.1.4 风险

由开发团队根据项目遭遇意外事件的可能性来设置，这些事件包括超支、工期延误，甚或是项目取消。虽然可以对风险级别进行细分，但大多数项目经理都认为将风险归为高、中、低就足够了。通过评测项目团队估计进度的不确定性（范围），一般都可以间接地对风险进行评估。 3.1.5 稳定性

由分析员和开发团队设置，设置的依据是特性发生变化的可能性或团队对特性的理解发生变化的可能性。用于协助确定开发优先级并确定下一步需要继续征集的特性。 3.1.6 目标发布版

记录将首次包括指定特性的产品版本。该字段可用于将前景文档中的特性分配给特定的基线发布版。如果将其与状态字段结合，您的团队就可以提出、记录和讨论发布版的各种特性，而此时还不必前进到开发阶段。只有状态被设置为“已并入”且目标发布版已确定的特性才将被实施。管理规模时，可以增加目标发布版本号，这样该项特性虽然仍保留在前景文档中，但将安排在以后发布。 3.1.7 职责分配

在许多项目中，特性会被分配给各个“特性团队”，它们负责进一步获取需求，并编写软件需求和实施方案。这一简单的下拉列表将帮助项目团队中的每位成员更好地理解他们的职责。 3.1.8 原因

此文本字段用于跟踪所需特性的来源。需求的提出总会有一定的原因。此字段记录相应的解释或对相应解释的引用。例如，引用可以是产品需求规约的页码及行号，或是某次重要的客户访谈录像的会议记录标号。

4. 可追踪性标准

4.1 需求之间的追踪

4.2 需求和后续开发的追踪 采用用例驱动的开发： 需求 – 确定用例 分析 – 分析用例 设计 – 设计用例 编码 –

实现用例 测试 – 测试用例 追踪方法：用例实现

5. 需求管理团队

需求管理小组成员： ● 产品经理 ● 项目经理 ● 系统分析员 ● 架构师

● 开发人员代表 ● 测试人员代表

6. 需求开发与管理计划

7. 需求管理工作指南

7.1 需求工程过程

确定系统目标 //可以是产品经理或者项目经理 建立需求管理小组 //系统分析员 或者产品经理 建立需求管理项目 //系统分析员 或者产品经理

制定需求管理计划 ,确定需求的工件类型、属性、追踪策略//系统分析员 或者产品经理 获取需求、分析需求、编写需求规格 //系统分析员或者产品经理 确定需求的属性 //产品经理/系统分析员 需求评审 //需求管理小组

建立需求追踪矩阵 //系统分析员或者产品经理 建立需求基线 //系统分析员 或者产品经理

第一次迭代：

根据需求确定系统的架构，确定需求的优先级 //需求管理小组 项目计划，分配需求，管理需求的广度//项目经理 实现需求 //开发人员 验证需求 //测试人员

建立需求基线//产品经理/系统分析员

第二次迭代：

确定需求的优先级 //需求管理小组

项目计划，分配需求，管理需求的广度//项目经理 实现需求 //开发人员 验证需求 //测试人员

建立需求基线//产品经理/系统分析员

第n 次迭代 产品发布

确定需求的优先级 //需求管理小组

项目计划，分配需求，管理需求的广度//项目经理 实现需求 //开发人员 验证需求 //测试人员

建立需求基线 //产品经理/系统分析员

7.2 需求开发过程 获取需求

需求分析 需求定义 需求验证

7.3 定义需求属性 确定需求属性类型 定义需求属性

可以修改需求属性

根据需求属性检索需求 7.4 定义需求跟踪矩阵 确定需求跟踪矩阵的X,Y 轴 建立跟踪矩阵视图 标示跟踪矩阵

7.5 需求版本控制过程 建立需求版本 固化需求

记录需求变更请求 接受需求变更

建立需求基线，新的版本 7.6 变更管理过程

所有的人员都可以提出需求变更请求，说明变更的原因 变更过程必须依据需求管理计划的需求状态定义， 由需求管理小组分析需求变更引起的影响，

对于接受的需求变更，分配责任者，执行需求变更， 需求变更完成后，进行实施和验证。

需求管理计划

版本

修订历史记录

目 录

1. 简介

1.1 1.2 1.3 1.4 1.5

目的 范围

定义、首字母缩写词和缩略语 参考资料 概述

4 4 4 4 4 4 4 5 5 5 5 5 6 6 6 6 6 6 6 6 6 7 8 8 8 9 9 9 9

2. 需求工件与需求类型 3. 需求属性

3.1

的属性 3.1.1 状态 3.1.2 价值 3.1.3 工作量 3.1.4 风险 3.1.5 稳定性

3.1.6 目标发布版 3.1.7 职责分配 3.1.8 原因

4. 可追踪性标准

4.1 4.2

需求之间的追踪

需求和后续开发的追踪

5. 需求管理团队 6. 需求开发与管理计划 7. 需求管理工作指南

7.1 7.2 7.3 7.4 7.5 7.6

需求工程过程 需求开发过程 定义需求属性

定义需求跟踪矩阵 需求版本控制过程 变更管理过程

需求管理计划

1.

简介

[需求管理计划的简介应提供整个文档的概述。其中应包括此需求管理计划的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。] 1.1

目的

[阐明本需求管理计划的目的。] 1.2

范围

[简要说明此需求管理计划的范围、与它相关的项目，以及受到此文档影响的其他任何事物。] 1.3

定义、首字母缩写词和缩略语

[本小节应提供正确解释此需求管理计划所需的全部术语的定义、首字母缩写词和缩略语。 这些信息可以通过引用项目词汇表来提供。] 1.4

参考资料

[本小节应完整列出此需求管理计划中其他部分所引用的任何文档。每个文档应标有标题、报告号（如果适用）、日期和出版单位。列出可从中获取这些参考资料的来源。这些信息可以通过引用附录或其他文档来提供。] 1.5

概述

[此小节应说明需求管理计划其他部分所包含的内容，并解释该文档的组织方式。]

2. 需求工件与需求类型

3.

3.1

需求属性

的属性

3.1.1 状态

有需求管理人员设置。

3.1.2 价值

由营销经理、产品经理或业务分析员设置。并非所有需求都同等重要。通过按照各项需求对最终用户的相对利益来划分其等级，可以促使客户、分析员和开发团队成员相互交换意见。用于管理规模并确定开发的优先级。

3.1.3 工作量

由开发团队设置。由于有些特性所需的时间和资源多于其他特性，所以在评测复杂程度并预计在给定时间范围内能否完成哪些工作时，最佳的方式就是估计团队工作周数或个人工作周数、所需的代码行数或功能点数

（举例来说）。用于管理规模并确定开发的优先级。 3.1.4 风险

由开发团队根据项目遭遇意外事件的可能性来设置，这些事件包括超支、工期延误，甚或是项目取消。虽然可以对风险级别进行细分，但大多数项目经理都认为将风险归为高、中、低就足够了。通过评测项目团队估计进度的不确定性（范围），一般都可以间接地对风险进行评估。 3.1.5 稳定性

由分析员和开发团队设置，设置的依据是特性发生变化的可能性或团队对特性的理解发生变化的可能性。用于协助确定开发优先级并确定下一步需要继续征集的特性。 3.1.6 目标发布版

记录将首次包括指定特性的产品版本。该字段可用于将前景文档中的特性分配给特定的基线发布版。如果将其与状态字段结合，您的团队就可以提出、记录和讨论发布版的各种特性，而此时还不必前进到开发阶段。只有状态被设置为“已并入”且目标发布版已确定的特性才将被实施。管理规模时，可以增加目标发布版本号，这样该项特性虽然仍保留在前景文档中，但将安排在以后发布。 3.1.7 职责分配

在许多项目中，特性会被分配给各个“特性团队”，它们负责进一步获取需求，并编写软件需求和实施方案。这一简单的下拉列表将帮助项目团队中的每位成员更好地理解他们的职责。 3.1.8 原因

此文本字段用于跟踪所需特性的来源。需求的提出总会有一定的原因。此字段记录相应的解释或对相应解释的引用。例如，引用可以是产品需求规约的页码及行号，或是某次重要的客户访谈录像的会议记录标号。

4. 可追踪性标准

4.1 需求之间的追踪

4.2 需求和后续开发的追踪 采用用例驱动的开发： 需求 – 确定用例 分析 – 分析用例 设计 – 设计用例 编码 –

实现用例 测试 – 测试用例 追踪方法：用例实现

5. 需求管理团队

需求管理小组成员： ● 产品经理 ● 项目经理 ● 系统分析员 ● 架构师

● 开发人员代表 ● 测试人员代表

6. 需求开发与管理计划

7. 需求管理工作指南

7.1 需求工程过程

确定系统目标 //可以是产品经理或者项目经理 建立需求管理小组 //系统分析员 或者产品经理 建立需求管理项目 //系统分析员 或者产品经理

制定需求管理计划 ,确定需求的工件类型、属性、追踪策略//系统分析员 或者产品经理 获取需求、分析需求、编写需求规格 //系统分析员或者产品经理 确定需求的属性 //产品经理/系统分析员 需求评审 //需求管理小组

建立需求追踪矩阵 //系统分析员或者产品经理 建立需求基线 //系统分析员 或者产品经理

第一次迭代：

根据需求确定系统的架构，确定需求的优先级 //需求管理小组 项目计划，分配需求，管理需求的广度//项目经理 实现需求 //开发人员 验证需求 //测试人员

建立需求基线//产品经理/系统分析员

第二次迭代：

确定需求的优先级 //需求管理小组

项目计划，分配需求，管理需求的广度//项目经理 实现需求 //开发人员 验证需求 //测试人员

建立需求基线//产品经理/系统分析员

第n 次迭代 产品发布

确定需求的优先级 //需求管理小组

项目计划，分配需求，管理需求的广度//项目经理 实现需求 //开发人员 验证需求 //测试人员

建立需求基线 //产品经理/系统分析员

7.2 需求开发过程 获取需求

需求分析 需求定义 需求验证

7.3 定义需求属性 确定需求属性类型 定义需求属性

可以修改需求属性

根据需求属性检索需求 7.4 定义需求跟踪矩阵 确定需求跟踪矩阵的X,Y 轴 建立跟踪矩阵视图 标示跟踪矩阵

7.5 需求版本控制过程 建立需求版本 固化需求

记录需求变更请求 接受需求变更

建立需求基线，新的版本 7.6 变更管理过程

所有的人员都可以提出需求变更请求，说明变更的原因 变更过程必须依据需求管理计划的需求状态定义， 由需求管理小组分析需求变更引起的影响，

对于接受的需求变更，分配责任者，执行需求变更， 需求变更完成后，进行实施和验证。