需求管理计划

1、-作者xxxx-日期xxxx需求管理计划【精品文档】需求管理计划1 简介21.1 目的21.2 范围21.3 定义、首字母缩写词与缩略语21.4 参考资料21.5 概述22 需求工件与需求类型33 需求属性33.1 特性属性33.1.1 状态33.1.2 利益33.1.3 工作量33.1.4 风险33.1.5 稳定性33.1.6 目标发布版33.1.7 职责分配43.1.8 原因43.2 涉众请求的属性43.2.1 状态43.2.2 利益43.2.3 工作量43.2.4 请求类别43.2.5 风险43.2.6 原因53.3 用例的属性53.3.1 用例分级53.3.2 风险53.3.3 原因5

2、3.3.4 用例图形说明53.4 用例详细需求53.4.1 用例分级53.4.2 用例图形说明53.4.3 用例书面说明53.5 补充需求的属性53.5.1 状态53.5.2 利益53.5.3 风险53.5.4 原因63.5.5 书面说明64 可追踪性标准61 简介11目的本文档说明塔防游戏的需求文档、需求类型以及各自的需求属性，同时指定出于对此项目需求进行评测、报告和控制等目的而要收集并使用的信息和控制机制。b5E2RGbCAP12范围输入：涉众请求、业务规则、用例模型及主角输出：游戏功能、游戏关卡13定义、首字母缩写词与缩略语无14参考资料UML与系统分析设计可视化面向对象建模技术-标准建

3、模语言UML教程 刘超 张莉遍著15概述管理计划包含了需求工件与需求类型（主要分析需求的类型有哪些，并对其进行解释），需求属性（主要介绍不同需求类型的需求属性有哪些，并解释），可追踪性标准（主要对于已确定的每一需求类型，列出确定可追踪性时使用的标准（应追踪至的对象）。p1EanqFDPw2 需求工件与需求类型件（文档类型）需求类型说明涉众请求 (STR)涉众请求 (STRQ)涉众的关键请求，包括变更请求前景 (VIS)特性 (FEAT)系统的这一发布版的状况或功能用例模型用例 (UC)该发布版的用例，记录在 Rational Rose中用例 (UC)用例详细需求 (UC)在用例规约中列出的各项

4、详细需求补充规约 (SS)补充需求 (SUPP)未记录在用例模型中的非功能性需求系统构架负责确定用例的优先级。用例阐释者详细用例说明，详细说明软件需求。系统分析员主要负责确定前景，功能分析，获取常用词汇，查找主角和用例，获取涉众请求，制定需求管理计划。用户界面设计员主要负责用户界面建模，设计用户界面原型。3 需求属性31特性的属性311状态在经过项目管理团队的商谈和复审后设置。用于在确立项目基线的过程中对进度进行跟踪。已提出用于说明正在进行讨论但尚未经过“正式渠道”（由项目团队、产品管理部门和用户或客户群的代表所组成的工作组）复审和验收的特性。已批准被认为是有用、可行并已获得正式渠道批准，准备

5、实施的功能。已并入在特定时间点并入产品基线中的特性。312利益由营销经理、产品经理或业务分析员设置。并非所有需求都同等重要。通过按照各项需求对最终用户的相对利益来划分其等级，可以促使客户、分析员和开发团队成员相互交换意见。用于管理规模并确定开发的优先级。DXDiTa9E3d313工作量由开发团队设置。由于有些特性所需的时间和资源多于其他特性，所以在评测复杂程度并预计在给定时间范围内能否完成哪些工作时，最佳的方式就是估计团队工作周数或个人工作周数、所需的代码行数或功能点数。用于管理规模并确定开发的优先级。RTCrpUDGiT314风险由开发团队根据项目遭遇意外事件的可能性来设置，这些事件包括超支

6、、工期延误，甚或是项目取消。虽然可以对风险级别进行细分，但大多数项目经理都认为将风险归为高、中、低就足够了。通过评测项目团队估计进度的不确定性（范围），一般都可以间接地对风险进行评估。5PCzVD7HxA315稳定性由分析员和开发团队设置，设置的依据是特性发生变化的可能性或团队对特性的理解发生变化的可能性。用于协助确定开发优先级并确定下一步需要继续征集的特性。jLBHrnAILg316目标发布版记录将首次包括指定特性的产品版本。该字段可用于将前景文档中的特性分配给特定的基线发布版。如果将其与状态字段结合，您的团队就可以提出、记录和讨论发布版的各种特性，而此时还不必前进到开发阶段。只有状态被设置

7、为“已并入”且目标发布版已确定的特性才将被实施。管理规模时，可以增加目标发布版本号，这样该项特性虽然仍保留在前景文档中，但将安排在以后发布。xHAQX74J0X317职责分类在许多项目中，特性会被分配给各个“特性团队”，它们负责进一步获取需求，并编写软件需求3和实施方案。这一简单的下拉列表将帮助项目团队中的每位成员更好地理解他们的职责。LDAYtRyKfE318原因此文本字段用于跟踪所需特性的来源。需求的提出总会有一定的原因。此字段记录相应的解释或对相应解释的引用。例如，引用可以是产品需求规约的页码及行号，或是某次重要的客户访谈录像的会议记录标号。Zzz6ZB2Ltk32涉众请求的属性321状

8、态在经过项目管理团队的商谈和复审后设置。用于在确立项目基线的过程中对进度进行全程跟踪。已提出用于说明正在进行讨论但尚未经过“正式渠道”（例如由项目团队、产品管理部门和用户或客户群的代表所组成的工作组）复审和验收的涉众请求。已批准被认为是有用、可行并已获得正式渠道批准，准备实施的涉众请求。已实现在特定时间点产品质量测试通过的。322利益由营销经理、产品经理或业务分析员设置。并非所有需求都同等重要。通过按照各项需求对最终用户的相对利益来划分其等级，可以促使客户、分析员和开发团队成员相互交换意见。用于管理规模并确定开发的优先级。dvzfvkwMI1关键关键的涉众请求。不实现这些请求就无法使系统满足客

9、户的需要。所有关键的涉众请求都必须在发布时实现，否则将错过预定的发布时间。非关键可以通过其他方式来实现这方面的涉众请求。如果遗漏了某项非关键涉众请求，可能会影响客户或用户满意度，甚至会影响收入，但发布并不会因为缺少某一项非必要质量标准而延期。323工作量由联合测试团队（由9人小组人员组成）设置。由于有些涉众请求所需实现起来复杂程度要比其他涉众请求要大，所以在评测涉众请求实现起来的复杂程度并预计在测试过程中所需的时间，最佳的方式就是估计团队工作周数或个人工作周数。用于管理规模并确定测试的优先级。rqyn14ZNXI324请求类别包括：变更请求，质量请求，特性请求，成本请求。325风险由测试及开发

10、团队根据项目遭遇意外事件的可能性来设置，这些事件包括超支、工期延误，甚或是项目取消。虽然可以对风险级别进行细分，但大多数项目经理都认为将风险归为高、中、低就足够了。通过评测项目团队估计进度的不确定性（范围），一般都可以间接地对风险进行评估。EmxvxOtOco326原因此文本字段用于跟踪所需涉众请求的来源。需求的提出总会有一定的原因。此字段记录相应的解释或对相应解释的引用。例如，引用可以是产品需求规约的页码及行号，或是某次重要的客户访谈录像的会议记录标号。SixE2yXPq533用例的属性331用例分级关键关键的用例。不实现这些请求就无法使系统满足客户的需要。所有关键的用例都必须在发布时实现，

11、否则将错过预定的发布时间。非关键可以通过其他方式来实现这方面的用例。如果遗漏了某项非关键用例，可能会影响客户或用户满意度，甚至会影响收入，但发布并不会因为缺少某一项非必要质量标准而延期。332风险由测试及开发团队根据项目遭遇意外事件的可能性来设置，这些事件包括超支、工期延误，甚或是项目取消。虽然可以对风险级别进行细分，但大多数项目经理都认为将风险归为高、中、低就足够了。通过评测项目团队估计进度的不确定性（范围），一般都可以间接地对风险进行评估。6ewMyirQFL333原因此文本字段用于跟踪所需涉众请求的来源。需求的提出总会有一定的原因。此字段记录相应的解释或对相应解释的引用。例如，引用可以是

12、产品需求规约的页码及行号，或是某次重要的客户访谈录像的会议记录标号。kavU42VRUs334用例图形说明34用例详细需求341用例分级关键关键的用例。不实现这些请求就无法使系统满足客户的需要。所有关键的用例都必须在发布时实现，否则将错过预定的发布时间。非关键可以通过其他方式来实现这方面的用例。如果遗漏了某项非关键用例，可能会影响客户或用户满意度，甚至会影响收入，但发布并不会因为缺少某一项非必要质量标准而延期。342用例图形说明包括：用例图，活动图，交互图，类图等。343用例书面说明对用例图等图形说明做书面的阐述，解释标志和含义。35补充需求的属性351状态在经过项目管理团队的商谈和复审后设置

13、。用于在确立项目基线的过程中对进度进行跟踪。352利益由营销经理、产品经理或业务分析员设置。并非所有需求都同等重要。通过按照各项需求对最终用户的相对利益来划分其等级，可以促使客户、分析员和开发团队成员相互交换意见。用于管理规模并确定开发的优先级。y6v3ALoS89353风险由开发团队根据项目遭遇意外事件的可能性来设置，这些事件包括超支、工期延误，甚或是项目取消。虽然可以对风险级别进行细分，但大多数项目经理都认为将风险归为高、中、低就足够了。通过评测项目团队估计进度的不确定性（范围），一般都可以间接地对风险进行评估。M2ub6vSTnP354原因此文本字段用于跟踪所需特性的来源。需求的提出总会

14、有一定的原因。此字段记录相应的解释或对相应解释的引用。例如，引用可以是产品需求规约的页码及行号，或是某次重要的客户访谈录像的会议记录标号。0YujCfmUCw355书面说明说明补充需求的类型，含义等。4 可追踪性标准对于上述确定的每一需求类型，应列出确定可追踪性时使用的标准（应追踪至的对象）。可追踪性有助于开发者了解和管理诸如业务规则和涉众请求等需求内容如何转换为一系列关键的涉众用户需要和系统特性（在前景文档中规定）。可追踪性还可用于跟踪这些详细规约如何转化为设计、如何测试，以及用户文档是如何记录的。eUts8ZQVRd任何开发流程都隐含有一定量的可追踪性。这些可追踪性通常由流程中工件之间的正

15、式关系提供。用例可追踪至用例段（每个用例由一个用例段集组成。这种关系允许我们追踪哪些用例段组成了哪一个用例）和主角（这种关系允许我们查看哪一个用例包含哪些主角）。sQsAEJkW5T需要追踪至产品特性（每一种需要由一个特性集实现。这种关系允许追踪每个特性的业务利益）。产品特性追踪至软件需求（每个特性由一个软件需求集实现；这种关系允许追踪每个软件需求的业务利益，并在产品特性级别进行软件需求规模管理）；GMsIasNXkA需要至用例（在这种情况下，需要直接追踪到用例。假设用例在产品和规模管理中可以扮演产品特性的角色）。产品特性至用例（可选的可追踪性链接。产品特性可直接追踪至用例。这一选项允许在编写

16、用例段之前为用例分配产品特性，在产品特性级别对用例模型执行影响分析，反之亦然）。TIrRGchYzg产品特性到用例段（产品特性追踪至用例段。它允许在特性的基础上管理用例模型的规模，并有利于在比用例本身更合适的级别上进行特性集与用例模型之间的影响分析；追踪至用例的所有产品特性还必须追踪至用例段之一）。7EqZcWLZNX产品特性到软件需求（产品特性还追踪至补充规约里的软件需求。没有追踪至用例模型的所有产品特性必须追踪到补充规约中的至少一个软件需求）。lzq7IGf02E软件需求至用例（功能性软件需求追踪至用例；非功能性软件需求的一个子集也追踪至用例；这种关系允许根据用例的需求和业务利益对用例模型进行高级规模规划和评估。注意：所有局部功能需求必须追踪至用例或词汇表。如果无法以该方式将它们反映出来，那么它们将得不到实施）。zvpgeqJ1hk软件需求至用例段（追踪到用例的软件需求必须还能够追踪至用例的用例段之一。这种关系允许根据对用例提出的需求验证用例的用例段。追踪至用例的所有软件需求必须由用例内其中的一个段实现。双重可追踪性允许我们在考虑所需的用例段之前对用例段进行验证，并为用例本身分配软件需求。某些段可能没有与之匹配的软件需求。注意：追踪至用例的所有功能性需求必须还能够追踪到用例的某一个段。如果无法以该方式将它们反