5.1 本章概述
5.2 跟踪需求
track requirements
什么是跟踪需求
使用跟踪工具，跟踪产品需求的能力，可以是双向的
从其来源到满足他的交付物
跟踪需求的益处
确保需求带来业务价值
帮助满足客户的期望
帮助管理范围-避免出现范围蔓延
评估变更的影响程度，需求覆盖矩阵，需求跟踪矩阵
监督需求
monitor requirements
子主题 1
沟通需求
communicate requirements
更新需求
update requirements
5.3 关系和依赖性
子集
subsets
一条需求可能是另外一条需求的子集
实现依赖性
implementation dependency
有些需求需要依赖与其他需求的实现才能实现
价值依赖性
benefit or value dependency
除非另一条需求先实现，否则一条需求的价值就无法体现
5.4 批准需求
批准的流程在初始的商业分析计划中确定，记录并获得批准
一开始就确定流程有助于需求批准时避免冲突
工作授权系统
work authorization system
批准的层级
批准 approval 干系人
签署 signoff 发起人
审核人 reviewer
批准人 approver
BA 负责管理需求，项目经理确保需求得到管理，发起人对最终产品负责
需求驳回 rejection
CCB 变更控制委员会
预测形的开发，批准需求的最终来源
专家判断与批准流程
5.6 使用跟踪矩阵来监督需求
traceability matrix
定义
项目生命周期中的产品需求从来源到满足他们交付物之间关联
需求属性-每项需求的简短描述
选择确实会被跟踪与管理，而不会被忽略的属性
需求编号 requirements id
描述 description
目的 odjective
优先级 priority
需求来源 source
版本 version
干系人满意度
稳定度
复杂度
验收标准
适应形生命周期的可能不需要矩阵
益处
新出现的详细需求被关联至基准化的需求
基准化需求提供了构建一组特性所需的详细信息
避免范围蔓延 scope creep
为每项批准的需求创建工作成果
根据基准化需求创建为其提供支持的业务分析工作成果
跟踪矩阵的层级
包含不同的层级，从高层次需求开始，随需求的细化添加细节
业务需求
用户需求
功能性需求
5.7 需求生命周期
维护产品未完项
product backlog
产品负责人（product owner）负责产品需求-称为特性(features)
新需求被加入，优先级也会随时变化，跟踪这些变更，并向干系人进行沟通
生命周期
提出的诉求
分析需求
分析模型和需求描述
分析文档得到批准
干系人进行设计开发测试
开发中对需求进行实现
需求的批准
批准需求但推迟另外一个项目
将一项已经批准尚未启动的需求进行替换
取消或者驳回需求
5.8 管理需求变更
变更基本概念
记录变更的提议
变更控制流程
预测形的生命周期，需求需要正式批准，建立基准，
敏捷的就没那么正式，
每个登记的变更请求，都应该由CCB 批准-推迟-驳回
变更的请求
变更的控制流程
项目经理
评估变更
是否影响预算
是否需要争取更多时间和资源
变更管理与商业分析的关系
BA 维护需求与相关交付物/工作成果的完整性，
每条新需求都符合业务需要及业务域项目目标
变更控制工具与方法
配置管理系统
configuration managemennt system (CMS)
包含文档，跟踪流程，与审批
变更批准所需的不同层级
可以对一个产品及其想依赖的产品进行变更
提供方便而全面的访问控制
版本控制系统
version control system (VCS)
涵盖在CMS中
跟踪修改历史
可以使用EXCEL
影响分析
inpact analysis
对需求基准的影响
对商业分析工作的影响
对项目管理工作的影响
控制缺陷相关的变更
变更是修复解决方案中发现的问题
有些缺陷是审核中被提出，与干系人解决方案交互过程中发现
需求相关文档不受影响，而是解决方案部分被修改，与已经批准的需求相吻合
