介绍
需求管理的目的是用于管理项目产品或产品部件的需求以便可以标识处需求与项目计划,工作产品之间的不一致性.
分类
需求又包含技术与非技术性的需求.
技术性的需求又包含各种功能性的需求和性能的需求. 如满足各种业务功能,支持不同的配置,产品的容错性,产品的不间断提供服务,单位时间内的业务处理能力等等.
非技术性的需求,包含产品交付时间,交付方式,相关培训,手册等等..
需求管理的特别实践
取得对需求的理解
· 需求应当是被清晰的陈述的
· 需求应当是完整的
· 需求应当是相互一致无冲突的
· 需求应当被唯一标识
· 需求适合于去实现
· 需求实现后是可被验证的
· 需求是可以被跟踪的
在实践中,输入部分包括
辨别合适的需求提供者的标准清单
评估和接受需求的标准
输出部分
根据标准的需求分析结果
一个同意的(agree-to)需求集合.
(agree-to)需求集合记录在需求评审会议纪要中
一般在实际项目中,这个实践用于需求分析.
取得对需求的承诺
这个实践用于处理在所有参与需求实现的人取得一致意见并获得承诺.
在实践中,输入部分包括
一个同意的(agree-to)需求集合
输出部分
需求影响评估
文档化的对需求或需求变更的承诺.
实际上可以将承诺记录在需求评审报告中
关键子实践
要在已经做出承诺的基础上评估需求
谈判和记录承诺
管理需求变更
随着需要的变化和工作的开展,会产生额外的需求和对已有需求的变更.关键是有效的管理这些额外需求和对已有需求的变更.
输入部分
新的需求和对需求的变更
输入和输出都相关部分
需求状态
需求数据库
需求决定
执行者
变更管理委员会
维护需求的双向可追踪性
这个实践的目的在于维护产品分解的不同级别上对需求的双向可追踪性.
典型工作产品
需求追踪矩阵
需求跟踪系统
子实践
维护需求的跟踪性去确保低层需求的来源文档化
维护需求的可追踪性从一个需求到衍生的需求和功能,接口,对象,人员,流程和工作部件的分布.
生成需求矩阵.
标识项目工作和需求的不一致性
该实践用于发现在需求,项目计划和工作产品中发现不一致.并启动纠正措施来解决问题.
典型工作产品
文档化发生的不一致问题,包括源,条件和基本原理
改正措施
子实践
回顾项目计划,活动和工作产品来检查需求和变更与计划活动和工作产品的一致性.
标识不一致的源头和基本原因
标识由于需求基线变动而导致的计划和工作产品变动
启动纠正措施
注:通用实践部分不在复述.
例子
该范例来自RequisitePro工具
样例项目为”ClassicsCD.com”
需求管理计划
定义组织,职责和接口
- 项目经理,质量保证,组长,配置经理,需求说明者,变更控制经理
定义需求工件
- 文档类型
- 愿景,用例规范,术语表,SUPP,RMP
- 需求类型
- 特性,用例,术语,补充需求,..
- 属性和属性值
- 优先级,状态,难度
- 追踪
RequisitePro中的特性
在vision 文档中增加一个新特性
在用例规范中增加一条用例
RequisitePro中的用例显示
跟踪性