版本 需求管理过程
需求管理过程定义
文档编号
版本
生效日期
拟制
审核
批准
北京赛柏科技有限责任公司
(版权所有，翻版必究)
变更记录
版本号
修改原因／内容
修改人
审核／
批准人
修改时间
目录
3目录 ---------------------------------------------------------------------
41 前言 ------------------------------------------------------------------
目的 -------------------------------------------------------------------------------------------
适用范围 -------------------------------------------------------------------------------------
术语 -------------------------------------------------------------------------------------------
参考文献 -----------------------------------------------------------------------------------
42 过程目标 ----------------------------------------------------------
43 角色职责 ----------------------------------------------------------
54 输入 ----------------------------------------------------------------
65 入口准则 ----------------------------------------------------------
66 活动 ----------------------------------------------------------------
活动流程图 --------------------------------------------------------------------------
活动描述 -----------------------------------------------------------------------------
77 出口准则 ----------------------------------------------------------
88 输出 ----------------------------------------------------------------
89 需要的资源 -------------------------------------------------------
810 需要的知识和技能 ---------------------------------------------
811 需要的配置管理 ------------------------------------------------
812 监督和控制 ------------------------------------------------------
813 验证 -----------------------------------------------------------------
914 相关的文件 ------------------------------------------------------
1 前言
目的
本文是XX公司过程体系文件的一部分，用于描述需求管理过程。需求管理的目的是管理产品和产品构件的需求，并识别需求与项目计划与工作产品的不一致。定义本过程是为了指导本公司项目相关人员正确实施需求管理的各项活动，保证在客户和项目相关人员之间建立对需求的共同理解。
适用范围
本过程适用于公司范围内所有的项目。
需求管理的范围包括所有的项目需求，包括技术性需求和非技术性需求，项目获得的需求和项目产生的需求，包括客户提供的需求和组织自己的要求。此外，需求开发所生成的产品，如产品需求和产品构件需求，也是需求管理的范围。
术语
CCB（Configuration Control Board）：配置控制委员会
PPQA（Process and Product Quality Assurance）：过程和产品质量保证
REQM（Requirements Management）：需求管理
参考文献
《CMMI-DEV, , Staged Representation》
过程目标
所有需求都被文档化，建立供软件工程和管理使用的需求基线。
确保项目所有相关人员对需求取得一致的理解。
确保项目计划、活动、工作产品与软件需求保持一致。
维护需求的双向可跟踪性。
确保所有的需求变更都受控。
角色职责
角色
职责
项目经理
为需求管理工作提供各种必要的环境和条件
领导项目组收集和分析客户需求，定义《用户需求规格说明书》和《产品需求规格说明书》
需求变更请求发生时，组织、参与评估其影响面和程度
组织和参与与需求相关的工作产品和活动的评审
需求变更请求批准后，更改项目计划、工作产品和活动以便与需求的变更保持一致
组织定义和维护《需求跟踪矩阵》
客户（注）
提出需求
提出需求变更请求
确认需求
项目组成员
参与定义《用户需求规格说明书》和《产品需求规格说明书》
提出需求变更请求
定义和维护《需求跟踪矩阵》
实施批准后的需求变更
参与与需求相关的工作产品和活动的评审
测试组
根据《用户需求规格说明书》和《产品需求规格说明书》编写相应的测试计划、测试用例
需求变更批准后调整测试计划、测试用例
测试结果通告给项目相关人员
参与与需求相关的工作产品和活动的评审
配置管理员
负责与需求相关的配置项管理
PPQA工程师
负责评价需求管理过程活动及相关的工作产品
高层经理
评审需求管理活动和工作产品
协调和审批外部约定（Commitment）
为需求管理活动提供必要的资金、人员、资源支持与保证
CCB
评审和审批需求及需求变更请求
注：客户分为内部客户和外部客户，内部客户包括本公司的高层经理、项目经理、项目组成人员、
输入
文档化的初始需求
可以借鉴和参考的相关项目的资料
入口准则
存在文档化、已批准的客户需求（如任务书、合同、SOW等）；
负责需求管理工作的人员已经指定并具有相关技能；
有足够的用于需求管理的资源和资金。
活动
活动流程图
需求管理活动主要包括：获得对需求的理解、获得对需求的承诺、管理需求变更、维护需求跟踪、识别项目计划、项目产品与需求的不一致。图 7 1是需求管理活动的关系示意图。
图 7 1 需求管理活动关系示意图
活动描述
活动名称
活动描述
制定实施需求管理过程的计划
在项目开展之初，制定项目计划的同时制定需求管理计划。需求管理计划给出该项目需求管理的目标，任务的时间进度，所需资源，承担人员，所需知识技能及培训。通常需求管理计划是项目整体计划的一部分。
取得对需求的理解
取得对需求的理解的活动是与需求提供者一起进行的需求分析活动，以确保对需求的含义达成共识。分析和交流的结果是达成一致的需求集合。
制订用于区别适合的需求提供者的准则。
制订用于接收需求的目标准则。
分析需求，以保证满足所制订的准则。
与需求提供者达成共识，以便项目的各个参加者能够对它们做出承诺。
取得对需求的承诺
取得对需求的承诺就是要在那些必须进行各项为实现这些需求所需的活动的人员之间达成一致和建立承诺。。随着需求的演变，要求在所有相关的人员之间对已批准的现行需求重新建立承诺并且对项目计划、活动和工作产品中的后续变更做出承诺。
1.所有相关的人员对需求进行评审，评估各项需求对现行承诺的影响。
2.当需求发生变更或提出了新的需求时，所有相关的人员对需求变更进行评审，要评价它们对项目各个参加者的影响。
3.记录评审结果，记录承诺。
管理需求变更
对现行的需求做出变更时，有效地管理这些需求和需求变更。要了解每个需求的来源并且把做出变更的理由形成文件。项目经理跟踪相应的需求变化度量数据，以便判断是否需要采取新的控制措施或对已有的控制做出调整。
1. 汇集赋予项目的或者由项目产生的全部需求或需求变更。
2. 维护需求变更的历史及变更理由。
3. 维护变更的历史数据有助于追溯需求的变化情况。
4. 从相关的共利益者的角度出发评价需求变更的影响。
5. 使需求和需求变更数据可供项目使用。
维护需求的双向可跟踪性
维护需求的的双向可跟踪性，以建立起从来源需求到它的较低层次的需求的可跟踪性，和从较低层次的需求到它们的来源需求的可跟踪性。。需求的可跟踪性还可以覆盖与其他实体的关系，例如与产品、设计文档的变更、测试计划、验证、确认以及工作任务等的关系。在评估需求变更对项目计划、活动以及工作产品的影响时，尤其需要可跟踪性。
维护对需求的可跟踪性，以确保能找到低层（派生）需求的来源。
维护某个需求与它的各个派生需求的需求可跟踪性，以及从需求分配到功能、目标、人和过程的需求可跟踪性。
维护需求的从功能到功能的横向可跟踪性和跨接口的可跟踪性。
生成需求可跟踪性度量项目。
识别项目计划、项目产品与需求的不一致性
这个活动旨在发现需求与项目计划和工作产品之间的不一致，并且决定是否采取纠正措施。审查项目计划、活动和工作产品，看其是否与需求和需求变更一致。
确定不一致的来源和理由。
识别由于对需求基线的变更而导致的必需对项目计划、活动和工作产品做出的变更。
出口准则
需求被理解并达成承诺
需求变更处理完成
需求跟踪矩阵已经建立或维护，能够正确反映需求与各阶段主要工作产品间的对应关系
需求和各阶段工作产品之间的不一致问题被消除《软件需求规格说明书》被评审和批准并且被置于配置管理库；
软件开发计划、设计、代码、测试计划、测试用例、需求跟踪矩阵根据需求变更已被更新。
输出
《需求跟踪矩阵》；
《需求变更申请表》；
《需求变更跟踪报告》；
《问题处理单》；
《需求不一致性状态跟踪表》；
《需求评审检查单》；
《需求评审报告》。
9 需要的资源
工具：
需求说明工具
模拟和建模工具
需求跟踪工具
10 需要的知识和技能
知识：
应用专题
需求定义和分析
需求导出
需求说明和建模
需求跟踪
11 需要的配置管理
内容：
用户需求
需求库
需求跟踪矩阵
软件需求规格说明或系统需求规格说明
管理级别：基线
12 监督和控制
对本过程计划实施的监督和控制
度量和分析：
需求总数；
需求变更总数，已变更需求所占的百分比；
需求变更活动，包括提出的、未解决的、批准的、和加入到系统基线的总次数；
13 验证
1）PPQA工程师按照质量保证计划对需求管理活动和工作产品进行评价，对发现的不一致问题需要一跟到底。
2）项目经理定期或事件驱动对需求的管理活动进行评审，并将结果记录于《项目周报》。
3）高层经理在约定的里程碑处，审查需求管理活动的实施。
14 相关的文件
《评审规程》
《评审报告》
《变更控制规程》
《变更申请单》
《问题处理规程》
《问题报告》
《PPQA过程》
《CM过程》
《基线变更控制规程》
版权所有©北京赛柏科技有限责任公司 第 PAGE 2 页 / 共 NUMPAGES 9 页
