需求管理过程 .docVIP

需求管理过程 Version 1.2 文档名称：CMMI5-需求管理过程-V1.2.doc 修订历史记录 日期 版本号 修改说明 修改人 核准人 目录 1 目的 4 2 范围 4 3 术语、缩写词 4 4 职责 4 5 过程概述 5 5.1 简要说明 5 5.2 流程图 5 5.3 规程清单 5 6 过程规范 6 6.1 需求确认 6 6.2 需求跟踪 6 6.3 需求变更控制 7 7 输出结果和记录 8 8 裁剪指南 8 9 附录 9 需求管理过程 目的 软件需求管理就是对分配给软件的系统需求进行管理。即客户和软件项目之间就需要满足的软件需求建立和维护一致的约定； 控制软件需求，为软件工程和管理建立基线，为其它软件工程活动提供基础（如管理活动、测试活动） ； 保持软件计划、产品和活动与软件需求的一致性。 范围 项目级的软件需求管理活动包括： 需求确认； 需求基线化； 需求跟踪； 需求变更控制； 需求状态评审。 术语、缩写词 需求 用户所需要的并能触发一个程序或系统开发工作的说明（Jones 1994）；或从系统外部能发现系统所具有的满足于用户的特点、功能及属性等（Alan Davis 1993）。 需求工程 所有与需求相关的活动统称为需求工程。 需求开发 需求收集、评价、文档化等活动，一般分为：需求调查、需求分析、需求定义和需求验证四个阶段。 需求管理 在项目进展过程中，维持需求约定集成性和精确性的所有活动。包括：需求确认、需求跟踪、需求变更控制。 需求确认 指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。 需求跟踪 指通过比较需求文档与后继工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保软件产品与软件需求之间的一致性。 需求变更控制 指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，确保需求的变更不会失去控制而导致项目发生混乱。 职责 项目经理 （1）负责组织对需求文档如《用户需求说明书》和《软件需求规格说明书》进行评审。（2）作为开发方负责人和客户对需求文档作书面承诺，使之具有商业合同效果。（3）和客户共同控制需求变更。 项目协调员 协助项目经理进行需求变更管理及需求跟踪管理。 配置管理员 负责建立软件需求基线库。 变更控制委员会（CCB） 负责评审“需求变更申请”，决定采纳和拒绝变更请求。CCB由项目经理、系统分析员、系统设计员组成，若项目已处于编码阶段和测试阶段，则CCB还需包括主要开发人员、主要测试人员，必要时可能包括业务部经理、PQE、CC人员、客户代表。 系统分析员 负责变更需求文档。 系统设计员 负责变更系统设计，以保持设计和需求的一致性。 程序员 负责变更程序，使程序与设计和需求保持一致。 软件测试测人员 负责根据SRS编写测试用例。负责验证软件需求规格说明书的可测试性。 过程概述 简要说明 需求管理（Requirement Management，RM）的目的是在客户与项目组之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并控制需求的变更。 流程图 规程清单 需求管理过程包含3个规程：需求确认、需求跟踪与需求变更控制。 需求确认－需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。 需求跟踪－需求跟踪是指通过比较需求文档与后继工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依照需求文档进行开发。 需求变更控制－需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，确保需求的变更不会失去控制而导致项目发生混乱。 过程规范 需求确认 目的：是开发方和客户对需求文档如《用户需求说明书》和《软件需求规格说明书》进行评审，达成一致的理解，并作出书面承诺。 Entry Criteria 1 需求文档如《用户需求说明书》和《软件需求规格说明书》已经完成。 Inputs 1 需求文档如《用户需求说明书》和《软件需求规格说明书》。 Steps 1 项目经理先在项目内部组织人员进行非正式的需求评审，以消除明显的错误和分歧。 2 项目经理邀请同行专家和用户（包括客户和最终用户）一起评审需求文档，尽最大努力使需求文档能够正确无误地反映用户的真实意愿。 同行专家人员组成参考《评审人员组成指南》，其中要包括测试人员，他们负责对需求的可测试性（Testability）进行验证。 在评审的时候应该使用《需求评审检查表》 3 当需求文档通过正式的评审之后，系统分析员准备《需求确认表》。 4 项目经理和研发部门经理及客户对需求文档进行确认，填写《