需求管理计划

需求管理计划

1简介 (2)

1.1目的 (2)

1.2范围 (2)

1.3定义、首字母缩写词与缩略语 (2)

1.4参考资料 (2)

1.5概述 (2)

2需求工件与需求类型 (3)

3需求属性 (3)

3.1特性属性 (3)

3.1.1状态 (3)

3.1.2利益 (3)

3.1.3工作量 (3)

3.1.4风险 (3)

3.1.5稳定性 (3)

3.1.6目标发布版 (3)

3.1.7职责分配 (4)

3.1.8原因 (4)

3.2涉众请求的属性 (4)

3.2.1状态 (4)

3.2.2利益 (4)

3.2.3工作量 (4)

3.2.4请求类别 (4)

3.2.5风险 (4)

3.2.6原因 (5)

3.3用例的属性 (5)

3.3.1用例分级 (5)

3.3.2风险 (5)

3.3.3原因 (5)

3.3.4用例图形说明 (5)

3.4用例详细需求 (5)

3.4.1用例分级 (5)

3.4.2用例图形说明 (5)

3.4.3用例书面说明 (5)

3.5补充需求的属性 (5)

3.5.1状态 (5)

3.5.2利益 (5)

3.5.3风险 (5)

3.5.4原因 (6)

3.5.5书面说明 (6)

4可追踪性标准 (6)

1简介

1．1目的

本文档说明塔防游戏的需求文档、需求类型以及各自的需求属性，同时指定出于对此项目需求进行评测、报告和控制等目的而要收集并使用的信息和控制机制。

1．2范围

输入：涉众请求、业务规则、用例模型及主角

输出：游戏功能、游戏关卡

1．3定义、首字母缩写词与缩略语

无

1．4参考资料

UML与系统分析设计

可视化面向对象建模技术-标准建模语言UML教程刘超张莉遍著1．5概述

管理计划包含了需求工件与需求类型（主要分析需求的类型有哪些，并对其进行解释），需求属性（主要介绍不同需求类型的需求属性有哪些，并解释），可追踪性标准（主要对于已确定的每一需求类型，列出确定可追踪性时使用的标准（应追踪至的对象））。

2需求工件与需求类型

件（文档类型）需求类型说明

涉众请求(STR) 涉众请求 (STRQ) 涉众的关键请求，包括变更请求前景(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和实施方案。这一简单的下拉列表将帮助项目团队中的每位成员更好地理解他们的职责。

3．1．8原因

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

3．2涉众请求的属性

3．2．1状态

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