大型系统软件需求管理计划模版.docx

更多精彩，尽在tt娱乐城/需求管理计划版本 注：以下提供的模板用于 Rational Unified Process。其中包括用方括号括起来并以蓝色斜体（样式=InfoBlue）显示的文本，它们用于向作者提供指导，在发布此文档之前应该将其删除。按此样式输入的段落将被自动设置为普通样式（样式=Body Text）。要定制 Microsoft Word 中的自动字段（选中时显示灰色背景），请选择 FileProperties，然后将 Title、Subject 和 Company 等字段替换为此文档的相应信息。关闭该对话框后，通过选择 EditSelect All（或 Ctrl-A）并按 F9，或只是在字段上单击并按 F9，可以在整个文档中更新自动字段。对于页眉和页脚，这一操作必须单独进行。按 Alt-F9，将在显示字段名称和字段内容之间切换。有关字段处理的详细信息，请参见 Word 帮助。 专业文档，尽在/ Version: 需求管理计划 Date: 修订历史记录日期版本说明作者目录1.简介31.1目的31.2范围31.3定义、首字母缩写词和缩略语31.4参考资料31.5概述32.需求工件与需求类型33.需求属性33.1的属性33.1.1状态33.1.2利益33.1.3工作量33.1.4风险33.1.5稳定性33.1.6目标发布版33.1.7职责分配33.1.8原因34.可追踪性标准34.1的标准3需求管理计划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)未记录在用例模型中的非功能性需求 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 原因此文本字段用于跟踪所需特性的来源。需求的提出总会有一定的原因。此字段记录相应的解释或