需求管理规程V1.00.doc

需求管理规程受控状态：受控编写： 徐国栋 日期： 审核： 日期： 批准： 日期： 发布时间： 实施时间：文档修订记录版本号*变化状态简要说明日期变更人批准日期批准人*变化状态：C = 创立，A = 增加，M = 修改，D = 删除文档审批信息序号审批人角色审批日期签字备注目录1. 简介11.1. 目的11.2. 适用范围11.3. 引用文件11.4. 术语表11.5. 参考资料12. 过程总体描述12.1. 过程概述12.2. 过程流程图23. 过程元素描述33.1. 需求跟踪33.1.1. 目的33.1.2. 角色和职责33.1.3. 进入准则33.1.4. 输入33.1.5. 工作任务33.1.6. 退出准则43.1.7. 输出43.2. 管理需求变更43.2.1. 目的43.2.2. 角色和职责43.2.3. 进入准则53.2.4. 输入53.2.5. 工作任务53.2.6. 退出准则53.2.7. 输出61. 简介1.1. 目的为软件项目在整个开发过程中确保产品的完整性、可追溯性，从而使产品满足需求提供方法和指导。1.2. 适用范围本文档的适用范围为组织中的各软件项目。1.3. 引用文件1.4. 术语表1.5. 参考资料 2. 过程总体描述2.1. 过程概述需求管理过程指识别、分析、建立软件需求，监控软件需求的状态，控制软件需求的变更过程，进行软件需求的追溯等。为软件项目在需求方面建立和维护与客户的共识；并将所建立的软件需求作为估算、策划、实施和管理项目的基础；控制管理软件需求及其变更，使软件开发计划、工作产品和活动与软件需求保持一致；进行软件需求的追溯，可改善产品质量、降低维护成本、实现重用。软件需求管理的活动贯穿项目的整个生命周期。2.2. 过程流程图3. 过程元素描述3.1. 需求跟踪1.2.3.3.1.3.1.1. 目的在项目的整个开发过程中，跟踪每项需求的状态是需求管理的一个重要的方面，通过周期性报告需求项的各状态类别以及各状态类别在整个需求中所占的百分比来改进项目的监控工作。状态的跟踪包括状态的定义和状态变更、统计，目的是了解项目是如何达到和完全验证所有批准的需求。3.1.2. 角色和职责l 项目经理：定义需求状态类型；审批需求状态的变更，分析需求跟踪状态结果；l QA人员：检查需求跟踪矩阵的填写，协助项目经理分析需求跟踪状态结果；l CM人员：负责需求跟踪矩阵的需求状态项的填写和统计需求状态，发布结果。3.1.3. 进入准则l 软件需求规格说明书经CCB批准并纳入基线。3.1.4. 输入l 软件需求规格说明书l 项目计划l 工作产品l 需求模块跟踪矩阵3.1.5. 工作任务（1） 定义需求状态类别目前定义的需求状态类别包括：l 已建议：该需求已被有权提出需求的人（客户或需求人员）建议。l 已批准：该需求已被分析，估计了其对项目与下一部分的影响，软件工程组已承诺实现该项需求。l 已设计：已实现需求项关联设计的概要设计和详细设计。l 已实现：已实现需求项关联代码的编写和单元测试。l 已验证：使用所选择的方法已验证了实现的需求，例如测试等。该需求现在被认为完成。l 已删除：计划的需求已从基线中删除，但必须是按变更要求进行的。（2） 由CM人员在事件驱动下（项目经理提交需求跟踪矩阵）填写需求跟踪矩阵的需求状态项，并统计出需求状态情况。3.1.6. 退出准则l 需求状态统计完成3.1.7. 输出l 需求跟踪矩阵3.2. 管理需求变更3.2.3.2.1. 目的对新出现的修改变更进行管理，经项目经理提交给CCB进行变更评估进入变更流程（参见变更管理规程），变更评估完成进行需求跟踪矩阵的变更。3.2.2. 角色和职责l 项目经理：负责接收变更申请单，组织需求变更活动的开展，审批需求跟踪矩阵；l 软件工程组成员：负责变更需求、设计、代码或测试内容，填写需求跟踪矩阵；l CM人员：负责将需求基线纳入配置管理；发布基线和需求状态。l CCB：负责评估、批准需求；l 客户代表：参与并确认需求的定义。3.2.3. 进入准则l 项目经理接受到变更申请单3.2.4. 输入l 变更申请单3.2.5. 工作任务l 软件工程组成员根据变更后的需求说明书及下游工作产品，填写需求跟踪矩阵；l 项目经理审批填写需求跟踪矩阵；l CM人员根据需求跟踪矩阵负责变更需求跟踪矩阵和需求状态，统计需求状态情况。 3.2.6. 退出准则l 变更被拒绝，CCB批准签字l 变更被取消，CCB批准签字l 变更获得相关组和客户的承诺l 基线更新，变更被执行，CCB批准签字，进行了验证l 需求变更涉及的下游工作产品变更并纳入基线l 需求跟踪矩阵变