需求管理计划
版本
[注：以下提供的模板用于 Rational Unified Process。其中包括用方括号括起来并以蓝色斜体（样式=InfoBlue）显示的文本，它们用于向作者提供指导，在发布此文档之前应该将其删除。按此样式输入的段落将被自动设置为普通样式（样式=Body Text）。]
[要定制 Microsoft Word 中的自动字段（选中时显示灰色背景），请选择 File>Properties，然后将 Title 、Subject 和 Company 等字段替换为此文档的相应信息。关闭该对话框后，通过选择
Edit>Select All（或 Ctrl-A）并按 F9，或只是在字段上单击并按 F9，可以在整个文档中更新自动字段。对于页眉和页脚，这一操作必须单独进行。按 Alt-F9，将在显示字段名称和字段内容之间切换。有关字段处理的详细信息，请参见 Word 帮助。]
修订历史记录
目录
1. 简介
1.1 1.2 1.3 目的 范围
定义、首字母缩写词和缩略语 4 4 4 4 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 4 4 5 5 5 5 5 5 5 5 6 6 6 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
可追踪性标准
的标准
[对于已确定的每一需求类型，应列出确定可追踪性时使用的标准（应追踪至的对象）。]
需求管理计划
版本
[注：以下提供的模板用于 Rational Unified Process。其中包括用方括号括起来并以蓝色斜体（样式=InfoBlue）显示的文本，它们用于向作者提供指导，在发布此文档之前应该将其删除。按此样式输入的段落将被自动设置为普通样式（样式=Body Text）。]
[要定制 Microsoft Word 中的自动字段（选中时显示灰色背景），请选择 File>Properties，然后将 Title 、Subject 和 Company 等字段替换为此文档的相应信息。关闭该对话框后，通过选择
Edit>Select All（或 Ctrl-A）并按 F9，或只是在字段上单击并按 F9，可以在整个文档中更新自动字段。对于页眉和页脚，这一操作必须单独进行。按 Alt-F9，将在显示字段名称和字段内容之间切换。有关字段处理的详细信息，请参见 Word 帮助。]
修订历史记录
目录
1. 简介
1.1 1.2 1.3 目的 范围
定义、首字母缩写词和缩略语 4 4 4 4 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 4 4 5 5 5 5 5 5 5 5 6 6 6 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
可追踪性标准
的标准
[对于已确定的每一需求类型，应列出确定可追踪性时使用的标准（应追踪至的对象）。]