需求变更控制步骤

图1 7 - 1说明了一个描述一项变更控制步骤的模板，它能够应用于需求变更和其它项目变更。下面主要讨论关于过程是如何处理需求变更的。步骤中的4个组件和若干个过程描述将会是很有用的：
• 开始条件（ entry criteria）—在执行过程或步骤前应该满足的条件。
• 过程和步骤中所包含的不同任务（ t a s k）及项目中负责完成它们的角色。
• 验证（v e r i f y）任务正确完成的步骤。
• 结束条件（ exit criteria）—指出过程或步骤完成的条件。

a. 绪论
绪论主要说明此步骤（ p r o c e d u r e）的目的，并且确定了步骤能够应用的范围。如果步骤仅仅适合特定产品中的变更，在绪论中应该明确表示。绪论还指明是否忽略特定种类的变更。例如对于项目开发过程中产生的过渡或临时产品，我们可能忽略掉变更，同时为了理解文档的其余部分定义了必要的条款。
b. 角色和责任
列出（按角色分类，而非姓名顺序）参与变更控制活动的项目组成员并且描述他们的责任。表1 7 -1提供了一些有关的角色。按你所处的环境和需要调整这些角色和相应的责任，在保持有效性的前提下尽可能使过程简单。一个人不必只担任一个角色。例如，项目管理者也可接收提交的变更需求。对于一些小项目，几个—也可能所有—角色均由一个人担任。

c. 变更请求状态
一个变更请要求有一个生存期，相应地有不同的状态。可以使用状态转换图来表示这些状态的变化，如图1 7 - 2所示，只有当特定条件满足时才能更新状态。
d. 开始条件
变更控制步骤的基本开始条件是：
• 通过合适的渠道接受一个合法的变更请求。
所有潜在的建议者应该知道如何提交一个变更请求，是通过书面、通过基于We b的表单、或者发个电子邮件，还是使用变更控制工具。将所有变更控制传递到一个联系点，且为每一个变更请求赋予统一的标识标签。
e. 任务
接收到一新的变更要求后下一步是评估建议的技术可行性、代价、业务需求和资源限制。变更控制委员会主席要求评估者执行一个系统影响分析（详情见第1 8章）、风险分析、危害分析及其它评估。这些分析确保能很好理解接受变更所带来的潜在影响。评估者和变更控制委员会同样应考虑拒绝变更所带来的对业务和技术的影响。制定决策的人应进入变更控制委员会，决定是采纳或还是拒绝请要的变更。C C B给每个采纳的变更需求设定一个优先级或变更实现日期，或将它分配给指定的产品。变更控制委员会通过更新请求状态和通知所有涉及到的小组成员来传达变更决定。相关人员可能不得不改变工作产品，如软件需求规格说明文档、需求数据库、设计模型、用户界面部件、代码、测试文档、用户文档。修改者在必要时应更新涉及的工作产品。
f. 验证
验证需求变更的典型方法是通过检查确保更新后的软件需求规格说明文档、使用实例文档、分析模型均正确反映变更的各个方面。使用跟踪能力信息找出受变更影响的系统的各个部分，然后验证他们实现了变更（详见第1 8章）。属于多个团组的成员可能会通过对下游工作产品测试或检查工作来参与验证变更工作。验证后，修改者安装更新后的部分工作产品并通过调试使之能与其它部分正常工作。
g. 退出条件
为了完成变更控制执行过程，下列退出条件应该得到满足：
• 请求的状态为“拒绝”，“结束”或“取消”。
• 所有修改后的工作产品安装至合适的位置。
• 建议者，变更控制主席，项目管理者和其他相关的项目参与者已经注意到了变更的细节和当前的状态。
• 已经更新需求跟踪能力矩阵（详见第1 8章）。
h. 变更控制状态报告
用报告、图表来总结变更控制数据库的内容和按状态分类的变更请求数量。描述产生报告的步骤。项目管理者通常使用这些报告来跟踪项目状态。
表1 7 - 2列出了每一个变更请求存储的一些数据项。当定义自己的列表时，指出什么是必选项，什么是可选项。同时指出每一项的值是由变更控制工具自动修正还是由指定的人员手工修正。有经验后可能喜欢自己修正数据项，所以当你使用电子表格或一张纸实验处理过程后，再让自动工具着手这事。