CMM中的需求管理与需求开发

需求管理（Requirements Management ）是属于CMM2中的过程域，简称为REQM ，需求开发（Requirements Development ）是CMM3中的过程域，简称RD 。

这两个过程域是CMMI 体系中关于需求的全部内容，下面分别对这两部分进行介绍。

本文对CMM 的一些基础知识、基础术语不再介绍。

需求管理与需求开发的分界线：
市场营销
用户需求
管理层
需求开发
需求管理
市场
营销
管理层项目环境
项目变更 大家可以这样理解，需求管理是指对需求变更的管理、对需求的跟踪，而获取需求、定义需求则属于需求开发部分。

需求管理
在CMMI 中，需求管理的目标定义为：
a. 把软件需求建立一个基线供软件工程和管理使用。

b. 软件计划、活动和工作产品同软件需求保持一致。

更高的目标：
软件需求的复用
需求管理的原则和方法
a. 必须与需求工程的其他活动紧密整合
b. 需求必须是文档化的、正确的、最新的、可管理的、可理解的
c. 只要需求变化了，需求变更的影响就必须被评估
d. 需求必须分优先级
e. 需求一定要分类管理
需求管理的主要工作：
特定目标和特定实践
特定目标
●管理需求
管理需求并识别需求与项目计划和工作产品之间的差
异。

●SP 1.1 取得需求理解
●SP 1.2 取得需求承诺
●SP 1.3 管理需求变更
●SP 1.4 维护需求的双向追溯性
●SP 1.5 识别项目工作与需求间的差异
REQM特定目标的关系
SP 1.1 取得需求理解
SP 1.1 和需求提出者一同来了解需求。

l 识别出谁是需求的提供者
l 识别出需求的接受标准：
a. Clearly and properly stated得到清晰和恰当的定义
b. Complete完整的
c. Consistent with each other相互一致的
d. Uniquely identified得到唯一标识的
e. Appropriate to implement适宜实现
f. Verifiable (testable)可以验证（测试）
g. Traceable可追溯
l 分析需求，确保符合已建立的准则。

l 与需求提供者达到需求共识，以使项目成员能承诺它们SP1.2 获取对需求的承诺
SP1.2 取得项目成员对需求的承诺。

●评估需求对现有承诺的影响。

需求变更或新需求发生时，评估它们对项目成员的影
响。

●协商并记录承诺。

在项目成员对需求或需求改变承诺之前，对现有承诺
的改变应先进行协商。

●承诺的时间点：
a. 需求刚建立时
b. 需求变更时
产出物
●需求影响评估
●需求和需求变更承诺的纪录
●项目组成员工作任务书
SP 1.3 管理需求变更
SP 1.3 当需求在项目执行期间逐渐开发时，管理
需求的变更。

●在项目执行期间，造成需求变更的原因很多：
a. 需要改变
b. 工作进行中产生新需求
●提出需求变更的动机是好的，目的是希望产品更加符合用户的需求。

对项目
开发小组而言，变更需求意味着要调整资源、重新分配任务、修改前期工作成果等，开发小组要为此付出较重的代价。

如果每次需求变更请求都被采纳的话，这个项目也许永远不能按时完成。

配置变更委员会CCB
●CCB是授权进行正式基线变更的机构
✓例如客户需求、设计基线。

●职能：
✓确保变更被分类以及被评估
✓评审和批准变更
✓确保只有被批准的变更得到实施
✓决定需要实施的变更的优先级
●变更控制活动必须在整个项目中具有可视性
●CCB成员可能包括：项目经理，配置管理员，质量保证人员，开发人员代表，
客户代表。

需求变更的阶段
●提交
●评估
●审批
●实施
●验证
●关闭
产出物
●需求变更申请表
●需求变更汇总表
SP 1.4 维护需求的双向追溯性
●维护需求与项目计划和工作产品间的双向追溯性。

●产出物：
需求跟踪矩阵
需求跟踪矩阵的主要作用
RTM的作用
A、验证需求的可实现性、可测试性
B、进行需求变更的影响分析
C、维护阶段，管理需求的变更
需求跟踪矩阵分为：纵向跟踪和横向跟踪
应该建立哪些需求跟踪矩阵？
●在SEI的调查中达成的基本共识是：纵向跟踪是必须的，如果没有，则REQM
SP1.4无法通过。

●对于纵向跟踪矩阵：
必需的：
✓客户需求与产品需求的跟踪
✓产品需求与测试用例的跟踪
✓100%的接口需求
✓全局性需求
✓核心需求
并非必需的：
✓性能需求
✓不影响系统架构的功能需求
需求跟踪矩阵由谁来建立？
●有多个角色参与建立RTM：
a. 需求开发人员
b. 设计人员
c. 测试用例的编写人员
d. PPQA
RTM是否纳入基线管理？
●RTM要纳入基线管理。

●纳入基线后，每次变更都要申请，RTM的变更一般是和其他配置项的变更一
起申请，很少单独申请变更RTM，除非RTM有错误。

●如何简化RTM的工作？
●由于在RTM中，需求可能有很多项，设计、测试用例、代码等都有多项，所
以建立和维护RTM的工作量还是比较大、比较烦琐。

对于变化频繁的项目，更是如此。

在实践中，为了简化该RTM的建立与维护工作，有的企业仅仅通
过需求与设计、代码、测试用例的编号来实现跟踪，如需求为：r1,r2,……
等编号，而设计的编号为：r1-d1,r1-d2,…….,测试用例的编号为：
r1-t1,r1-t2等等。

需要注意的是需求与它们之间是多对多的关系，仅通过编号是无法实现这种关系的。

如果不借助DOORS之类的需求管理工具，一般只能通过EXCEL来维护RTM，工作量就
●是比较大。

要简化，就要平衡管理的投入与产出。

●当然也可以考虑增大需求、设计、代码、测试用例的颗粒度大小，但是那样
RTM的作用就打了折扣，还是一个平衡问题。

SP1.5 确认项目工作和需求间的差异
主要活动：
●评审项目计划、活动和工作产品是否与需求和需求变更相符。

●识别差异来源及其理由。

●当需求基线有变动时，识别有关计划和工作产品所需的变更。

●启动纠正措施。

识别差距的时机？
●评审时
●变更时
●日常工作中
识别出的不一致问题要有记录，并跟踪问题的关闭需求管理我们需要客户方如何做。

●了解乙方需求变更流程，并与乙方就此流程达成一致
●指定专人负责需求变更
●内部形成一个需求变更流程
●针对内部提交的需求变更，在提交乙方之前横向分析对业务的影响
●在提交乙方之前，内部达成一致意见
●需求变更必将导致乙方开发成本增加，为保证项目成功，必要时追加合同资
金。