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 帮助。]

RUP软件文档模板需求管理计划

修订历史记录

RUP软件文档模板需求管理计划

Confidential

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

RUP软件文档模板需求管理计划

目录

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 <需求类型>的标准Confidential

?<公司名称>, 2000 4 4 4 5 5 5 5 5 5 5 6 6 6 6 6

Page 3 of 6

RUP软件文档模板需求管理计划

错误!未指定书签。

1. 简介

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

1.1 目的

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

1.2 范围

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

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

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

1.4 参考资料

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

1.5 概述

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

2. 需求工件与需求类型

[对于项目中的每种需求文档或工件,都应列出其中包含的需求类型,并简要解释其用途。您最好也列出承担相应职责的角色。]

RUP软件文档模板需求管理计划

Confidential

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

RUP软件文档模板需求管理计划

3.

3.1 需求属性 <需求类型>的属性

[对于已确定的每一需求类型,都应列出将要使用的属性,并简要解释其含义。例如,对于“特性”这一需求类型,可能要列出以下属性:

3.1.1 状态

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

RUP软件文档模板需求管理计划

3.1.2 利益

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

RUP软件文档模板需求管理计划

3.1.3 工作量

[由开发团队设置。由于有些特性所需的时间和资源多于其他特性,所以在评测复杂程度并预计在给定时间范围内能否完成哪些工作时,最佳的方式就是估计团队工作周数或个人工作周数、所需的代码行数或功能点数(举例来说)。用于管理规模并确定开发的优先级。]

3.1.4 风险

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

3.1.5 稳定性

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

Confidential

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

RUP软件文档模板需求管理计划

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 帮助。]

RUP软件文档模板软件需求规约

修订历史记录

RUP软件文档模板软件需求规约

Confidential

?错误!未找到引用源。, 2000 Page 2

RUP软件文档模板软件需求规约

目录

1. 简介

1.1 1.2 1.3 目的 范围

定义、首字母缩写词和缩略语 4 4 4 4 1.4 参考资料 1.5

概述

2. 整体说明

2.1 用例模型调查 2.2 假设与依赖关系3. 具体需求

3.1 用例报告 3.2 补充需求 4. 支持信息

Confidential

?错误!未找到引用源。, 2000 4 4 4 4 4 5 5 5 5

RUP软件文档模板软件需求规约

错误!未指定书签。

1. 简介

[软件需求规约 (SRS) 的简介应提供整个文档的概述。它应包括软件需求规约的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。]

[软件需求规约记录对系统或系统的一部分的完整软件需求。 以下是一个典型的软件需求规约概述,用于涉及用例建模的项目。此工件由一个包组成,该包包含用例模型的用例、适合的补充规约以及其他支持信息。有些软件需求规约没有采用用例建模,它在一个文档中记录了所有需求,而适用的部分可从补充规约(此后将不再需要)中插入,这种软件需求规约的模板请参见 rup_srs.dot。]

[软件需求规约可能会有许多不同的组织方式。有关以上两种组织方式的进一步阐述以及软件需求规约的其他组织方式,请参见 [IEEE93]。]

1.1 目的

[阐明此软件需求规约的目的。]软件需求规约应详细地说明所确定的应用程序或子系统的外部行为。它还要说明非功能性需求、设计约束以及提供完整、综合的软件需求说明所需的其他因素。]

1.2 范围

[简要说明此软件需求规约适用的软件应用程序、特性或其他子系统分组、与其相关的用例模型,以及受到此文档影响的任何其他事物。]

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

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

1.4 参考资料

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

1.5 概述

[此小节应说明软件需求规约其他部分所包含的内容,并解释文档的组织方式。]

2. 整体说明

[软件需求规约的这一节应说明影响产品及其需求的一般因素。本节并不列出具体的需求,而只是提供在第 3 节中详述的各种需求的背景,以使这些需求便于理解。其中包括产品总体效果、产品功能、用户特征、约束、假设与依赖关系、需求子集等内容。]

2.1 用例模型调查

[当采用用例建模时,此节将概述适用于该子系统或特性的用例模型或用例模型的子集。 其中包括所有用例和主角的名称列表及简要说明,以及适用的各种图和关系。 请参见用例模型调查报告,它在此处可用作附件。]

2.2 假设与依赖关系

[本节说明所有重要的技术可行性假设、子系统或构件可用性假设,或者可作为此软件需求规约所Confidential

?错误!未找到引用源。, 2000 Page 4

RUP软件文档模板软件需求规约

述软件可行性的基础的其他与项目有关的假设。]

3. 具体需求

软件需求规约的这一节应包括所有的软件需求,其详细程度应使设计人员能够设计出可以满足这些需求的系统,并使测试人员能够测试该系统是否满足这些需求。 当利用用例建模时,这些需求在用例和适用的补充规约中记录。如果没有利用用例建模,则可以将补充规约的概要直接插入此节。]

3.1 用例报告

[在用例建模过程中,用例通常会定义系统的大部分功能性需求,以及一些非功能性需求。对于以上用例模型中的每个用例或其子集,都需在此节中引用或附上用例报告。务必要明确地标明每一需求。]

3.2 补充需求

[补充规约记录未包含在用例中的需求。应在此处列出补充规约中适用于该子系统或特性的具体需求,并对这些需求加以改进,以足够详细地说明该子系统或特性。这些需求可以直接记录在此文档中,也可单独保存为补充规约,补充规约在此处可用作附件。务必要明确地标明每一需求。] 4.

?

?

? 支持信息 目录 索引 附录 [支持信息用于使软件需求规约更易于使用。它包括:

其中可以包括用例示意板或用户界面原型。如果包含附录,软件需求规约应明确指出是否将附录当作需求的一部分。]

Confidential

?错误!未找到引用源。, 2000 Page 5

相关推荐