需求管理

2010-05-11 作者：wzy0623 来源：wzy0623的blog

把所有与需求直接相关的活动通称为需求工程。需求工程的活动可分为两大类，一类属于需求开发，另一类属于需求管理。

需求开发的过程有四个主要活动：

（1）需求获取

积极地与用户进行交流，捕捉、分析和修正用户对目标系统的需求，并提炼出符合解决问题的用户需求，产生《用户需求说明书》

（2）需求分析

需求分析的目的是对各种需求信息进行分析并抽象描述，为目标系统建立一个概念模型。

（3）需求定义

需求定义的目标是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《需求规格说明书》。系统设计人员将依据《需求规格说明书》开展系统设计工作。

（4）需求验证

需求验证是指开发方和用户共同对需求文档评审，经双方对需求达成共识后做出书面承诺，使需求文档具有商业合同效果。

集成的能力成熟度模型（CMMI）中的需求管理流程

1. 制定需求管理计划

2. 求得对需求的理解

3. 求得对需求的承诺

4. 管理需求变更

5. 维护对需求的双向跟踪性

6. 识别项目工作与需求之间的不一致

需求属性

创建需求的时间

需求的版本号

创建需求的作者

负责认可该需求的人员

需求状态（已建议、已批准、已实现、已验证、已删除等）

需求的原因或根据（或信息的出处）

需求涉及的子系统

需求涉及的产品版本号

使用的验证方法或接受的测试标准

产品的优先级或重要程度（如高、中、低）

需求的稳定性（在将来需求可能变更的指示器，不稳定的需求意味你应给于较多的关注，因为你将面临不定的、混沌的、或不能重复的业务过程。）

制定需求管理计划的主要步骤

[步骤1] 建立并维护需求管理的组织方针

[步骤2] 确定需求管理需使用的资源

[步骤3] 分配责任

[步骤4] 培训计划

[步骤5] 确定需求管理的项目干系人，并确定其介入时机

[步骤6] 制定判断项目工作与需求不一致的准则和纠正规程

[步骤7] 制定需求跟踪性矩阵

[步骤8] 制定需求变更审批规程

[步骤9] 制定审批规程

需求规格说明书的版本控制

每一个公布的需求文档的版本应该包括一个修正版本的历史情况，即已做变更的内容、变更日期、变更人的姓名以及变更的原因。版本控制的最简单方法是根据标准约定手工标记软件需求规格说明的每一次修改。

需求变更管理

变更控制过程

1. 变更控制策略

所有需求变更必须遵循的过程，按照此过程，如果一个变更需求未被采纳，则其后过程不再予以考虑。

对于未获批准的变更，除可行性论证之外，不应再做其他设计和实现工作。

简单请求一个变更不能保证能实现变更，要由项目变更控制委员会（CCB）决定实现哪些变更。

项目风险承担者应该能够了解变更数据库的内容。

绝不能从数据库中删除或修改变更请求的原始文档。

每一个集成的需求变更必须能跟踪到一个经核准的变更请求。

2. 变更控制步骤

     a 绪论
      a.1 目的
      a.2 范围
      a.3 定义
    b 角色和责任
    c 变更请求状态
    d 开始条件
    e 任务
      e.1 产生变更请求
      e.2 评估变更请求
      e.3 作出决策
      e.4 通知变更人员
    f. 验证
    g. 结束条件

3. 变更控制状态报告

数据项名称	定义
变更由来	请求变更的功能区域，可能包括的团体，有市场、管理、客户、软件工程、硬件工程和测试
变更要求ID号	分配给每个请求的标签或顺序号
变更类型	变更请求的类型，如需求变更，建议性增改，错误报告
提交日期	提交变更请求的日期
更新日期	最近更新变更请求的日期
描述	以自由格式文本描述已请求的变更
实现优先级	由变更控制委员会赋予的每个变更的相对重要性，如低、中、高
修改者	实现变更的主要负责人姓名
建议者	提交变更请求的人名，也可以存储与此人相关的信息
建议者设置的优先级	建议者赋予每个变更的相对重要性，如：低，中，高
实现版本	计划中实现此变更的产品版本号
项目	要求变更的项目名称
反映文档	与每个变更相对应的反映文档，可以做出各种反映文档，所有反映文档均应保留
状态	变更请求的当前状态
标题	对变更的简短总结（最好仅一行）
验证者	负责决定是否正确实现变更的人名