《需求管理计划》由会员分享，可在线阅读，更多相关《需求管理计划（9页珍藏版）》请在金锄头文库上搜索。
1、urtiLn 火龙呆软件_北京火龙果软件工程技术中心需求管理计划版本 Version:火龙果业务系统Date: vdocument identifier修订历史记录日期版本说明作者日/月/年x.x详细信息姓名Version:火龙果业务系统Date: vdocument identifier目录1. 简介41.1 目的41.2 范围41.3 定义、首字母缩写词和缩略语41.4 参考资料41.5 概述42. 需求工件与需求类型43. 需求属性53.1 需求类型的属性53.1.1 状态53.1.2 价值53.1.3 工作量53.1.4 风险63.1.5 稳定性63.1.6 目标发布版63.1.7 职
2、责分配63.1.8 原因64. 可追踪性标准64.1 需求之间的追踪64.2 需求和后续开发的追踪65. 需求管理团队66. 需求开发与管理计划77. 需求管理工作指南87.1 需求工程过程87.2 需求开发过程97.3 定义需求属性97.4 定义需求跟踪矩阵97.5 需求版本控制过程97.6 变更管理过程9Version:火龙果业务系统Date: vdocument identifier需求管理计划1. 简介需求管理计划的简介应提供整个文档的概述。其中应包括此需求管理计划的目的、范围、定义、首字母缩 写词、缩略语、参考资料和概述。1.1 目的阐明本需求管理计划的目的。1.2 范围简要说明此需
3、求管理计划的范围、与它相关的项目，以及受到此文档影响的其他任何事物。1.3 定义、首字母缩写词和缩略语本小节应提供正确解释此需求管理计划所需的全部术语的定义、首字母缩写词和缩略语。这些信息可以通 过引用项目词汇表来提供。1.4 参考资料 本小节应完整列出此需求管理计划中其他部分所引用的任何文档。每个文档应标有标题、报告号（如果适 用）、日期和出版单位。列出可从中获取这些参考资料的来源。这些信息可以通过引用附录或其他文档来提 供。1.5 概述此小节应说明需求管理计划其他部分所包含的内容，并解释该文档的组织方式。2. 需求工件与需求类型工件（文档类型）需求类型说明用例模型用例（UC）此发布版的用例
4、，记录在RationalRose 中前景产品特性需求规格说明书SRS （包含 Use Case）在用例规约中列出的各项详细需求界面原型UI说明用户界面需求涉众请求涉众请求数据字典DDS详细描述数据项Version:火龙果业务系统Date: vdocument identifier3. 需求属性3.1 需求类型的属性属性名称用途定义方法优先级确定开发的先后顺序架构师根据技术和业务综合确定状态控制需求的变更由需求管理小组和利益人集体确定价值描述需求的商业价值由系统分析员定义，市场部门提议工作量描述实现需求需要的工作量由开发团队设置风险描述需求引起的风险开发团队设置稳定性需求在今后的稳定程度分析员和
5、开发团队设置目标发布版描述需求被实现后发布的版本由项目经理定义职责分配需求的责任人由项目经理定义原因需求变化的原因由系统分析员定义3.1.1 状态 有需求管理人员设置。已提出用于说明正在进行讨论但尚未经过“正式渠道”（例如由项目团队、产品管理部门和用户或客户群的代表所组成的工作组）复审和验收的特 性。已批准被认为是有用、可行并已获得正式渠道批准，准备实施的功能。已并入在特定时间点并入产品基线中的特性。已验证已经被测试验证3.1.2 价值 由营销经理、产品经理或业务分析员设置。并非所有需求都同等重要。通过按照各项需求对最终用户的相对 利益来划分其等级，可以促使客户、分析员和开发团队成员相互交换意
6、见。用于管理规模并确定开发的优先 级。关键必不可少的特性。不实现这些规约就无法使系统满足客户的需要。所有关键特性都必须在发布时实现，否则将错过预定的发布时间。重要对于系统在大多数应用中的有效性及效率都较为重要的特性。很难通过其他方式来实现这方面的功能。如果遗漏了某项重要特性，可能会影响客户 或用户满意度，甚至会影响收入，但发布并不会因为缺少某一项重要特性 而延期。有用有些特性在不太典型的应用中比较有用，或者可以合理而有效地实现其替代特性，这些特性的使用次数将会相对较少。即使发布版中没有包括某一 项这样的特性，也不会对收入或客户满意度造成严重的影响。3.1.3 工作量由开发团队设置。由于有些特性
7、所需的时间和资源多于其他特性，所以在评测复杂程度并预计在给定时间范Version:火龙果业务系统Date: vdocument identifier围内能否完成哪些工作时，最佳的方式就是估计团队工作周数或个人工作周数、所需的代码行数或功能点数 （举例来说）。用于管理规模并确定开发的优先级。3.1.4 风险由开发团队根据项目遭遇意外事件的可能性来设置，这些事件包括超支、工期延误，甚或是项目取消。虽然 可以对风险级别进行细分，但大多数项目经理都认为将风险归为高、中、低就足够了。通过评测项目团队估 计进度的不确定性（范围），一般都可以间接地对风险进行评估。3.1.5 稳定性由分析员和开发团队设置，设
8、置的依据是特性发生变化的可能性或团队对特性的理解发生变化的可能性。用 于协助确定开发优先级并确定下一步需要继续征集的特性。3.1.6 目标发布版记录将首次包括指定特性的产品版本。该字段可用于将前景文档中的特性分配给特定的基线发布版。如果将 其与状态字段结合，您的团队就可以提出、记录和讨论发布版的各种特性，而此时还不必前进到开发阶段。 只有状态被设置为“已并入”且目标发布版已确定的特性才将被实施。管理规模时，可以增加目标发布版本 号，这样该项特性虽然仍保留在前景文档中，但将安排在以后发布。3.1.7 职责分配在许多项目中，特性会被分配给各个“特性团队”，它们负责进一步获取需求，并编写软件需求和实
9、施方案。 这一简单的下拉列表将帮助项目团队中的每位成员更好地理解他们的职责。3.1.8 原因 此文本字段用于跟踪所需特性的来源。需求的提出总会有一定的原因。此字段记录相应的解释或对相应解释 的引用。例如，引用可以是产品需求规约的页码及行号，或是某次重要的客户访谈录像的会议记录标号。4. 可追踪性标准4.1 需求之间的追踪需求之间存在互相影响，一个需求会依赖于另一个需求，被依赖的需求变化的时候，影响依赖的需求。需求类型追踪到前景涉众请求需求规格说明前景用例模型需求规格说明界面原型用例模型数据字典需求规格说明4.2 需求和后续开发的追踪 采用用例驱动的开发： 需求-确定用例 分析-分析用例 设计-
10、设计用例 编码-实现用例 测试-测试用例 追踪方法：用例实现5. 需求管理团队Version:火龙果业务系统Date: vdocument identifier角色职责负责的工件产品经理需求主要责任者需求管理计划，前景，涉众请求，用例模型，需求规格说明项目经理根据需求制定项目计划项目开发计划系统分析员需求主要责任者需求管理计划，前景，涉众请求，用例模型，需求规格说明架构师确定需求的优先级架构设计文档开发人员实施需求详细设计文档、程序文件测试人员验证需求测试计划、测试用例、测试报告角色职责负责的工件项目经理根据需求制定项目计划项目开发计划系统分析员需求主要责任者需求管理计划，前景，涉众请求，用例
11、模型，需求规格说明开发人员实施需求详细设计文档、程序文件测试人员验证需求测试计划、测试用例、测试报告需求管理小组成员： 产品经理 项目经理 系统分析员 架构师 开发人员代表 测试人员代表6. 需求开发与管理计划时间工作角色工件确定系统目标产品经理/项目经理前景（需求概览）建立需求管理小组产品经理/系统分析员建立需求管理项目产品经理/系统分析员需求管理库制定需求管理计划产品经理/系统分析员需求管理计划获取需求、分析需求、编写 需求规格产品经理/系统分析员需求规格说明书确定需求的属性值产品经理/系统分析员需求属性矩阵确定需求追踪矩阵产品经理/系统分析员需求追踪矩阵建立需求基线产品经理/系统分析员第
12、一次迭代根据需求确定系统的架构， 确定需求的优先级等属性架构师、需求管理小组需求管理属性矩阵分配需求，管理需求的广度项目经理需求管性矩阵实现需求开发人员程序软件验证需求测试人员测试用例、测试报告建立需求基线产品经理/系统分析员第2次迭代确定需求的优先级架构师、需求管理小组需求管理属性矩阵Version:火龙果业务系统Date: vdocument identifier分配需求，管理需求的广度项目经理需求管性矩阵实现需求开发人员程序软件验证需求测试人员测试用例、测试报告建立需求基线产品经理/系统分析员第n次迭代产品发布确定需求的优先级架构师、需求管理小组需求管理属性矩阵分配需求，管理需求的广度项
13、目经理需求管性矩阵实现需求开发人员程序软件验证需求测试人员测试用例、测试报告建立需求基线产品经理/系统分析员需求整理与存档产品经理/系统分析员7. 需求管理工作指南7.1 需求工程过程确定系统目标 /可以是产品经理或者项目经理 建立需求管理小组 /系统分析员 或者产品经理 建立需求管理项目 /系统分析员 或者产品经理 制定需求管理计划 ,确定需求的工件类型、属性、追踪策略/系统分析员 或者产品经理 获取需求、分析需求、编写需求规格 /系统分析员或者产品经理确定需求的属性 /产品经理/系统分析员需求评审 /需求管理小组 建立需求追踪矩阵 /系统分析员或者产品经理 建立需求基线 /系统分析员 或者产品经理第一次迭代： 根据需求确定系统的架构，确定
