需求管理计划

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需求工件与需求类型

用例阐释者详细用例说明，详细说明软件需求。

系统分析员主要负责确定前景，功能分析，获取常用词汇，查找主角和用例，获取涉众请求，制定需求管理计划。

用户界面设计员主要负责用户界面建模，设计用户界面原型。

3需求属性

3．1特性的属性

3．1．1状态

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

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

3．1．3工作量

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

3．1．4风险

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

3．1．5稳定性

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

3．1．6目标发布版

记录将首次包括指定特性的产品版本。该字段可用于将前景文档中的特性分配给特定的基线发布版。如果将其与状态字段结合，您的团队就可以提出、记录和讨论发布版的各种特性，而此时还不必前进到开发阶段。只有状态被设置为“已并入”且目标发布版已确定的特性才将被实施。管理规模时，可以增加目标发布版本号，这样该项特性虽然仍保留在前景文档中，但将安排在以后发布。

3．1．7职责分类

在许多项目中，特性会被分配给各个“特性团队”，它们负责进一步获取需求，并编写软件需求3和实施方案。这一简单的下拉列表将帮助项目团队中的每位成员更好地理解他们的职责。

3．1．8原因

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

3．2涉众请求的属性

3．2．1状态

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

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

由联合测试团队（由9人小组人员组成）设置。由于有些涉众请求所需实现起来复杂程度要比其他涉众请求要大，所以在评测涉众请求实现起来的复杂程度并预计在测试过程中所需的时间，最佳的方式就是估计团队工作周数或个人工作周数。用于管理规模并确定测试的优先级。

3．2．4请求类别

包括：变更请求，质量请求，特性请求，成本请求。

3．2．5风险

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

3．2．6原因

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

3．3用例的属性

3．3．1用例分级

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

3．3．3原因

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

3．3．4用例图形说明

3．4用例详细需求

3．4．1用例分级

包括：用例图，活动图，交互图，类图等。

3．4．3用例书面说明

对用例图等图形说明做书面的阐述，解释标志和含义。

3．5补充需求的属性

3．5．1状态

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

3．5．2利益

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

3．5．3风险

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

3．5．4原因

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

3．5．5书面说明

说明补充需求的类型，含义等。

4可追踪性标准

对于上述确定的每一需求类型，应列出确定可追踪性时使用的标准（应追踪至的对象）。可追踪性有助于开发者了解和管理诸如业务规则和涉众请求等需求内容如何转换为一系列关键的涉众／用户需要和系统特性（在前景文档中规定）。可追踪性还可用于跟踪这些详细规约如何转化为设计、如何测试，以及用户文档是如何记录的。

任何开发流程都隐含有一定量的可追踪性。这些可追踪性通常由流程中工件之间的正式关系提供。

用例可追踪至用例段（每个用例由一个用例段集组成。这种关系允许我们追踪哪些用例段组成了哪一个用例）和主角（这种关系允许我们查看哪一个用例包含哪些主角）。

 需要追踪至产品特性（每一种需要由一个特性集实现。这种关系允许追踪每个特性的业务利益）；

产品特性追踪至软件需求（每个特性由一个软件需求集实现；这种关系允许追踪每个软件需求的业务利益，并在产品特性级别进行软件需求规模管理）；

需要至用例（在这种情况下，需要直接追踪到用例。假设用例在产品和规模管理中可以扮演产品特性的角色）；

产品特性至用例（可选的可追踪性链接。产品特性可直接追踪至用例。这一选项允许在编写用例段之前为用例分配产品特性，在产品特性级别对用例模型执行影响分析，反之亦然）；

产品特性到用例段（产品特性追踪至用例段。它允许在特性的基础上管理用例模型的规模，并有利于在比用例本身更合适的级别上进行特性集与用例模型之间的影响分析；追踪至用例的所有产品特性还必须追踪至用例段之一）；

产品特性到软件需求（产品特性还追踪至补充规约里的软件需求。没有追踪至用例模型的所有产品特性必须追踪到补充规约中的至少一个软件需求）；

软件需求至用例（功能性软件需求追踪至用例；非功能性软件需求的一个子集也追踪至用例；这种关系允许根据用例的需求和业务利益对用例模型进行高级规模规划和评估。注意：所有局部功能需求必须追踪至用例或词汇表。如果无法以该方式将它们反映出来，那么它们将得不到实施）；

软件需求至用例段（追踪到用例的软件需求必须还能够追踪至用例的用例段之一。

这种关系允许根据对用例提出的需求验证用例的用例段。追踪至用例的所有软件需求必须由用例内其中的一个段实现。双重可追踪性允许我们在考虑所需的用例段之前对用例段进行验证，并为用例本身分配软件需求。某些段可能没有与之匹配的软件需求。注意：追踪至用例的所有功能性需求必须还能够追踪到用例的某一个段。如果无法以该方式将它们反映出来，那么它们将得不到实施）；

软件需求至词汇表术语（功能性和非功能性需求可追踪至词汇表中的项。对于确定系统所包含的实体的属性和关系的“静态需求”而言，情况尤其如此。如果一个词汇表术语能够从软件需求进行追踪，那么该术语必须用于其中一个用例，否则它不可能被带入设计模型中）；

软件需求至补充需求（补充需求可以重新声明适用于整个系统或不能很好适应用例模型的补充需求。另一个备用方案就是将所有未追踪至用例模型的局部软件需求看作补充需求， 这样就避免了对它们的重复说明）。