需求管理计划

Dormanager需求管理计划第1页需求管理计划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原因…………………………………………………………………………53.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书面说明……………………………………………………………………6Dormanager需求管理计划第2页4可追踪性标准……………………………………………………………………………61简介1．1目的本文档说明塔防游戏的需求文档、需求类型以及各自的需求属性，同时指定出于对此项目需求进行评测、报告和控制等目的而要收集并使用的信息和控制机制。1．2范围输入：涉众请求、业务规则、用例模型及主角输出：游戏功能、游戏关卡1．3定义、首字母缩写词与缩略语无1．4参考资料UML与系统分析设计可视化面向对象建模技术-标准建模语言UML教程刘超张莉遍著1．5概述管理计划包含了需求工件与需求类型（主要分析需求的类型有哪些，并对其进行解释），需求属性（主要介绍不同需求类型的需求属性有哪些，并解释），可追踪性标准（主要对于已确定的每一需求类型，列出确定可追踪性时使用的标准（应追踪至的对象））。2需求工件与需求类型件（文档类型）需求类型说明涉众请求(STR)涉众请求(STRQ)涉众的关键请求，包括变更请求前景(VIS)特性(FEAT)系统的这一发布版的状况或功能用例模型用例(UC)该发布版的用例，记录在RationalRose中用例(UC)用例详细需求(UC)在用例规约中列出的各项详细需求补充规约(SS)补充需求(SUPP)未记录在用例模型中的非功能性需求系统构架负责确定用例的优先级。用例阐释者详细用例说明，详细说明软件需求。系统分析员主要负责确定前景，功能分析，获取常用词汇，查找主角和用例，获取涉众请求，制定需求管理计划。用户界面设计员主要负责用户界面建模，设计用户界面原型。3需求属性3．1特性的属性3．1．1状态在经过项目管理团队的商谈和复审后设置。用于在确立项目基线的过程中对进度进行跟Dormanager需求管理计划第3页踪。已提出用于说明正在进行讨论但尚未经过“正式渠道”（例如由项目团队、产品管理部门和用户或客户群的代表所组成的工作组）复审和验收的特性。已批准被认为是有用、可行并已获得正式渠道批准，准备实施的功能。已并入在特定时间点并入产品基线中的特性。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状态在经过项目管理团队的商谈和复审后设置。用于在确立项目基线的过程中对进度进行全Dormanager需求管理计划第4页程跟踪。已提出用于说明正在进行讨论但尚未经过“正式渠道”（例如由项目团队、产品管理部门和用户或客户群的代表所组成的工作组）复审和验收的涉众请求。已批准被认为是有用、可行并已获得正式渠道批准，准备实施的涉众请求。已实现在特定时间点产品质量测试通过的。3．2．2利益由营销经理、产品经理或业务分析员设置。并非所有需求都同等重要。通过按照各项需求对最终用户的相对利益来划分其等级，可以促使客户、分析员和开发团队成员相互交换意见。用于管理规模并确定开发的优先级。关键关键的涉众请求。不实现这些请求就无法使系统满足客户的需要。所有关键的涉众请求都必须在发布时实现，否则将错过预定的发布时间。非关键可以通过其他方式来实现这方面的涉众请求。如果遗漏了某项非关键涉众请求，可能会影响客户或用户满意度，甚至会影响收入，但发布并不会因为缺少某一项非必要质量标准而延期。3．2．3工作量由联合测试团队（由9人小组人员组成）设置。由于有些涉众请求所需实现起来复杂程度要比其他涉众请求要大，所以在评测涉众请求实现起来的复杂程度并预计在测试过程中所需的时间，最佳的方式就是估计团队工作周数或个人工作周数。用于管理规模并确定测试的优先级。3．2．4请求类别包括：变更请求，质量请求，特性请求，成本请求。3．2．5风险由测试及开发团队根据项目遭遇意外事件的可能性来设置，这些事件包括超支、工期延误，甚或是项目取消。虽然可以对风险级别进行细分，但大多数项目经理都认为将风险归为高、中、低就足够了。通过评测项目团队估计进度的不确定性（范围），一般都可以间接地对风险进行评估。3．2．6原因此文本字段用于跟踪所需涉众请求的来源。需求的提出总会有一定的原因。此字段记录相应的解释或对相应解释的引用。例如，引用可以是产品需求规约的页码及行号，或是某次重要的客户访谈录像的会议记录标号。3．3用例的属性3．3．1用例分级关键关键的用例。不实现这些请求就无法使系统满足客户的需要。所有关键的用例都必须在发布时实现，否则将错过预定的发布时间。非关键可以通过其他方式来实现这方面的用例。如果遗漏了某项非关键用Dormanager需求管理计划第5页例，可能会影响客户或用户满意度，甚至会影响收入，但发布并不会因为缺少某一项非必要质量标准而延期。3．3．2风险由测试及开发团队根据项目遭遇意外事件的可能性来设置，这些事件包括超支、工期延误，甚或是项目取消。虽然可以对风险级别进行细分，但大多数项目经理都认为将风险归为高、中、低就足够了。通过评测项目团队估计进度的不确定性（范围），一般都可以间接地对风险进行评估。3．3．3原因此文本字段用于跟踪所需涉众请求的来源。需求的提出总会有一定的原因。此字段记录相应的解释或对相应解释的引用。例如，引用可以是产品需求规约的页码及行号，或是某次重要的客户访谈录像的会议记录标号。3．3．4用例图形说明3．4用例详细需求3．4．1用例分级关键关键的用例。不实现这些请求就无法使系统满足客户的需要。所有关键的用例都必须在发布时实现，否则将错过预定的发布时间。非关键可以通过其他方式来实现这方面的用例。如果遗漏了某项非关键用例，可能会影响客户或用户满意度，甚至会影响收入，但发布并不会因为缺少某一项非必要质量标准而延期。3．4．2用例图形说明包括：用例图，活动图，交互图，类图等。3．4．3用例书面说明对用例图等图形说明做书面的阐述，解释标志和含义。3．5补充需求的属性3．5．1状态在经过项目管理团队的商谈和复审后设置。用于在确立项目基线的过程中对进度进行跟踪。3．5．2利益由营销经理、产品经理或业务分析员设置。并非所有需求都同等重要。通过按照各项需求对最终用户的相对利益来划分其等级，可以促使客户、分析员和开发团队成员相互交换意见。用于管理规模并确定开发的优先级。3．5．3风险由开发团队根据项目遭遇意外事件的可能性来设置，这些事件包括超支、工期延误，甚或是项目取消。虽然可以对风险级别进行细分，但大多数项目经理都认为将风险归为高、中、低就足够了。通过评测项目团队估计进度的不确定性（范围），一般都可以间接地对风险进行评估。3．5．4原因此文本字段用于跟踪所需特性的来源。需求的提出总会有一定的原因。此字段记录相应Dormanager需求管理计划第6页的解释或对相应解释的引用。例如，引用可以是产品需求规约的页码及行号，或是某次重要的客户访谈录像