修订历史记录

日期 版本 说明 作者 <日> <详细信息> <姓名>

Confidential ,<公司名称>, 2000 Page 2 of 6

<项目名称> Version: <1.0>

Date:

目录

1. 简介 4

1.1 目的 4

1.2 范围 4

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

1.4 参考资料 4

1.5 概述 4

2. 需求工件与需求类型 4

3. 需求属性 5

3.1 <需求类型>的属性 5

3.1.1 状态 5

3.1.2 利益 5

3.1.3 工作量 5

3.1.4 风险 5

3.1.5 稳定性 5

3.1.6 目标发布版 6

3.1.7 职责分配 6

3.1.8 原因 6

4. 可追踪性标准 6

4.1 <需求类型>的标准 6 Confidential ,<公司名称>, 2000 Page 3 of 6

<项目名称> Version: <1.0>

Date:

需求管理计划

1. 简介

[需求管理计划的简介应提供整个文档的概述。其中应包括此需求管理计划的目的、范围、定义、

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

1.1 目的

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

1.2 范围

[简要说明此需求管理计划的范围、与它相关的项目，以及受到此文档影响的其他任何事物。] 1.3 定义、首字母缩写词和缩略语

[本小节应提供正确解释此需求管理计划所需的全部术语的定义、首字母缩写词和缩略语。 这些信

] 息可以通过引用项目词汇表来提供。

1.4 参考资料

[本小节应完整列出此需求管理计划中其他部分所引用的任何文档。每个文档应标有标题、报告号

(如果适用)、日期和出版单位。列出可从中获取这些参考资料的来源。这些信息可以通过引用

] 附录或其他文档来提供。

1.5 概述

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

[对于项目中的每种需求文档或工件，都应列出其中包含的需求类型，并简要解释其用途。您最好

] 也列出承担相应职责的角色。

工件 需求类型 说明

(文档类型)

涉众请求 (STR) 涉众请求 (STRQ) 关键的涉众请求(包括变更请求)

前景 (VIS) 涉众需要 (NEED) 关键的涉众或用户需要

前景 (VIS) 特性 (FEAT) 此系统发布版的状况或功能

用例模型 用例 (UC) 此发布版的用例，记录在

Rational Rose 中

用例 (UC) 用例详细需求 (UC) 在用例规约中列出的各项详细需求

补充规约 (SS) 补充需求 (SUPP) 未记录在用例模型中的非功能性需

求

Confidential ,<公司名称>, 2000 Page 4 of 6

<项目名称> Version: <1.0>

Date:

3. 需求属性

3.1 <需求类型>的属性

[对于已确定的每一需求类型，都应列出将要使用的属性，并简要解释其含义。例如，对于“特

性”这一需求类型，可能要列出以下属性:

3.1.1 状态

[在经过项目管理团队的商谈和复审后设置。用于在确立项目基线的过程中对进度进行跟踪。]

已提出 用于说明正在进行讨论但尚未经过“正式渠道”(例如由项目团队、

产品管理部门和用户或客户群的代表所组成的工作组)复审和验收的

特性。

已批准 [被认为是有用、可行并已获得正式渠道批准，准备实施的功能。]

已并入 [在特定时间点并入产品基线中的特性。]

3.1.2 利益

[由营销经理、产品经理或业务分析员设置。并非所有需求都同等重要。通过按照各项需求对最终

用户的相对利益来划分其等级，可以促使客户、分析员和开发团队成员相互交换意见。用于管理

] 规模并确定开发的优先级。

关键 [必不可少的特性。不实现这些规约就无法使系统满足客户的需要。所有

] 关键特性都必须在发布时实现，否则将错过预定的发布时间。

重要 [对于系统在大多数应用中的有效性及效率都较为重要的特性。很难通过

其他方式来实现这方面的功能。如果遗漏了某项重要特性，可能会影响客

户或用户满意度，甚至会影响收入，但发布并不会因为缺少某一项重要特

] 性而延期。

有用 [有些特性在不太典型的应用中比较有用，或者可以合理而有效地实现其

替代特性，这些特性的使用次数将会相对较少。即使发布版中没有包括某

] 一项这样的特性，也不会对收入或客户满意度造成严重的影响。3.1.3 工作量

[由开发团队设置。由于有些特性所需的时间和资源多于其他特性，所以在评测复杂程度并预计在

给定时间范围内能否完成哪些工作时，最佳的方式就是估计团队工作周数或个人工作周数、所需

] 的代码行数或功能点数(举例来说)。用于管理规模并确定开发的优先级。3.1.4 风险

[由开发团队根据项目遭遇意外事件的可能性来设置，这些事件包括超支、工期延误，甚或是项目

取消。虽然可以对风险级别进行细分，但大多数项目经理都认为将风险归为高、中、低就足够

] 了。通过评测项目团队估计进度的不确定性(范围)，一般都可以间接地对风险进行评估。3.1.5 稳定性

[由分析员和开发团队设置，设置的依据是特性发生变化的可能性或团队对特性的理解发生变化的

] 可能性。用于协助确定开发优先级并确定下一步需要继续征集的特性。

Confidential ,<公司名称>, 2000 Page 5 of 6

<项目名称> Version: <1.0>

Date:

3.1.6 目标发布版

[记录将首次包括指定特性的产品版本。该字段可用于将前景文档中的特性分配给特定的基线发布

版。如果将其与状态字段结合，您的团队就可以提出、记录和讨论发布版的各种特性，而此时还

不必前进到开发阶段。只有状态被设置为“已并入”且目标发布版已确定的特性才将被实施。管

理规模时，可以增加目标发布版本号，这样该项特性虽然仍保留在前景文档中，但将安排在以后

] 发布。

3.1.7 职责分配

[在许多项目中，特性会被分配给各个“特性团队”，它们负责进一步获取需求，并编写软件需求

] 和实施方案。这一简单的下拉列表将帮助项目团队中的每位成员更好地理解他们的职责。3.1.8 原因

[此文本字段用于跟踪所需特性的来源。需求的提出总会有一定的原因。此字段记录相应的解释或

对相应解释的引用。例如，引用可以是产品需求规约的页码及行号，或是某次重要的客户访谈录

] 像的会议记录标号。

4. 可追踪性标准

4.1 <需求类型>的标准

[对于已确定的每一需求类型，应列出确定可追踪性时使用的标准(应追踪至的对象)。] Confidential ,<公司名称>, 2000 Page 6 of 6

范文三：RUP软件文档模板 - 需求管理计划

<公司名称>

错误!未指定书签。 错误!未指定书签。

版本 <1.0> [注:以下提供的模板用于 Rational Unified Process。其中包括用方括号括起来并以蓝色斜体(样式 =InfoBlue)显示的文本,它们用于向作者提供指导,在发布此文档之前应该将其删除。按此样式输 入的段落将被自动设置为普通样式(样式 =Body Text)。 ]

[要定制 Microsoft Word 中的自动字段(选中时显示灰色背景),请选择 File>Properties,然后将 Title 、 Subject 和 Company 等字段替换为此文档的相应信息。关闭该对话框后,通过选择

Edit>Select All(或 Ctrl-A)并按 F9,或只是在字段上单击并按 F9,可以在整个文档中更新自动字 段。对于页眉和页脚,这一操作必须单独进行。按 Alt-F9,将在显示字段名称和字段内容之间切 换。有关字段处理的详细信息,请参见 Word 帮助。 ]

修订历史记录

目录

1. 简介 4 1.1 目的 4 1.2 范围 4 1.3 定义、首字母缩写词和缩略语 4 1.4 参考资料 4 1.5 概述 4

2. 需求工件与需求类型 4

3. 需求属性 5 3.1 <需求类型>的属性 5 3.1.1 状态 5 3.1.2 利益 5 3.1.3 工作量 5 3.1.4 风险 5 3.1.5 稳定性 5 3.1.6 目标发布版 6 3.1.7 职责分配 6 3.1.8 原因 6

4. 可追踪性标准 6 4.1 <需求类型>的标准 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<需求类型>的标准

[对于已确定的每一需求类型,应列出确定可追踪性时使用的标准(应追踪至的对象)。 ]

范文四：能力需求计划管理细则模板

能力需求计划管理细则模板

能力需求计划管理细则模板

能力需求计划管理细则

第一章 总则

第一条 目的。

能力需求计划旨在通过对物料需求和企业现有生产能力进行比较，及早发现可能影响生产订单顺利完成的因素，并对这些因素进行平衡和调整，确保生产计划按时完成。

第二条 定义。

能力需求计划是对物料需求计划所需能力进行核算的一种计划管理方法。具体通过对各生产阶段和各工作中心(工序)所需的各种资源进行精确计算，得出人力负荷、设备负荷等资源负荷情况，并做好生产能力与生产负荷的平衡工作。

第二章 能力需求计划的分类和计算

第三条 分类。

11>(无限能力计划。

(1)无限能力计划不考虑能力对生产的限制，当生产负荷大于生产能力、出现超负荷情况时，对超过部分进行负荷调整。

(2)调整策略包括延长工作时间、使用替代加工级别、转移负荷工作中心、替代工序、外协加工、直接购买等方式。

(3)实施无限能力计划的出发点在于满足市场需求，体现企业以市场为中心的战略。

2(有限能力计划。

根据生产能力情况，将生产计划的安排按照紧迫程度和重要程度进行排序。当生产负荷过大时，可以考虑延后不紧迫和不重要的生产任务。

第四条 计算额定生产能力，即计算正常生产条件下的生产能力。

额定生产能力,可用机器数×每班工时×每天开班数×每周工作天数×利用率×效率

第五条 计算实际能力。

通过记录某工作班组在某一生产周期内的产出进行计算。

第三章 能力需求计划的编制

第六条 数据来源。

1(已下达车间执行的订单、已释放或正在加工的订单。

2(物料需求计划订单。

通过物料需求计划的运行，计算出产品零部件的净需求量和需求日期。

3(工作中心能力数据。

4(工艺路线数据。

5(工厂生产日历(一般将不工作的日期排除)。

6(其他数据:如工序间隔时间，包括在该中心的排队等待时间和从该中心转移到下一工作中心的运输等待时间，是在有关工序开工时间的基础数据。

第七条 编制步骤。

1(将物料需求计划各时段需要加工的物料通过工艺路线文件进行编制，得到所需要的各工作中心负荷。

2(将各工作中心负荷同各工作中心的额定能力进行比较，得出按时段划分的各工作中心的负荷报告。

3(由生产部管理人员根据报告提供的负荷情况及订单的优先级因素，对生产能力进行调整和平衡。

PAGE

PAGE 2

范文五：【管理精品】能力需求计划管理细则模板

能力需求计划管理细则模板

能力需求计划管理细则

第一章 总则

第一条 目的。

能力需求计划旨在通过对物料需求和企业现有生产能力进行比较，及早发现可能影响生产订单顺利完成的因素，并对这些因素进行平衡和调整，确保生产计划按时完成。

第二条 定义。

能力需求计划是对物料需求计划所需能力进行核算的一种计划管理方法。具体通过对各生产阶段和各工作中心(工序)所需的各种资源进行精确计算，得出人力负荷、设备负荷等资源负荷情况，并做好生产能力与生产负荷的平衡工作。

第二章 能力需求计划的分类和计算

第三条 分类。

1(无限能力计划。

(1)无限能力计划不考虑能力对生产的限制，当生产负荷大于生产能力、出现超负荷情况时，对超过部分进行负荷调整。

(2)调整策略包括延长工作时间、使用替代加工级别、转移负荷工作中心、替代工序、外协加工、直接购买等方式。

(3)实施无限能力计划的出发点在于满足市场需求，体现企业以市场为中心的战略。

2(有限能力计划。

根据生产能力情况，将生产计划的安排按照紧迫程度和重要程度进行排序。当生产负荷过大时，可以考虑延后不紧迫和不重要的生产任务。

第四条 计算额定生产能力，即计算正常生产条件下的生产能力。

额定生产能力,可用机器数×每班工时×每天开班数×每周工作天数×利用率×效率

第五条 计算实际能力。

通过记录某工作班组在某一生产周期内的产出进行计算。

第三章 能力需求计划的编制

第六条 数据来源。

1(已下达车间执行的订单、已释放或正在加工的订单。

2(物料需求计划订单。

通过物料需求计划的运行，计算出产品零部件的净需求量和需求日期。

3(工作中心能力数据。

4(工艺路线数据。

5(工厂生产日历(一般将不工作的日期排除)。

6(其他数据:如工序间隔时间，包括在该中心的排队等待时间和从该中心转移到下一工作中心的运输等待时间，是在有关工序开工时间的基础数据。

第七条 编制步骤。

1(将物料需求计划各时段需要加工的物料通过工艺路线文件进行编制，得到所需要的各工作中心负荷。

2(将各工作中心负荷同各工作中心的额定能力进行比较，得出按时段划分的各工作中心的负荷报告。

3(由生产部管理人员根据报告提供的负荷情况及订单的优先级因素，对生产能力进行调整和平衡。

转载请注明出处范文大全网 » 客户需求管理计划模板