工件： 变更请求
 变更请求 |
开发工件的变更是通过变更请求（CR）提出的。变更请求用于记录和追踪缺陷、扩展请求和任何其他类型的产品变更请求。变更请求的优点在于，它们提供了决策记录，且其评估的流程还确保了变更的影响可在整个项目范围内得到认同和理解。 |
| 角色： | 变更控制经理负责变更请求 |
| 详细信息： | |
| 活动的输入： | 活动的输出： |
目的 
变更的必要性是演进中的软件或现有软件系统所固有的。变更控制经理负责确定变更请求管理的过程，维护变更请求（CR），并确保以可控制的方式变更系统，以便预测变更对系统的影响。变更请求可以用于记录和追踪所有类型的系统变更请求，包括扩展请求和缺陷。
系统分析员可以利用扩展请求确定将来要在产品中包含的特性。为了理解涉众需要，在收集涉众请求时，扩展请求将用作输入。
缺陷就是已交付工作产品中的异常情况或瑕疵。缺陷包含诸如在生命周期早期阶段发现的遗漏和缺点，和/或是用于测试或操作的成熟软件中包含的故障症状（瑕疵）。缺陷还包括与预期目的的偏差或任何要加以跟踪并进行解决的问题。
缺陷的目的在于反映问题的细节，以便可以采取纠正措施、解决方法，并跟踪发生的情况。下列人员使用变更请求：
- 系统分析员，使用确定为扩展请求的变更请求，来确定产品的新特性，
- 项目经理，使用变更请求分配工作，
- 测试员，使用变更请求确定和说明在测试过程中发现的缺陷，
- 实施员，使用变更请求分析缺陷，查找变更请求的故障或起因，
- 测试设计员，使用变更请求计划核实已解决的变更请求的测试，分析收集的缺陷来评测软件和流程的质量。
提要
在进行与任何已提交的变更请求有关的决策时，以下属性非常实用：
大小
- 必须要变更的现有工作量是多少？
- 需要添加的多少新工作量？
备选方案
- 是否有备选方案？
复杂程度
提议的变更是否容易实现？
- 变更可能导致哪些连锁反应？
严重性
不实施这个请求的会导致哪些影响？
- 是否涉及到工作或数据丢失？
- 是否为扩展请求？
- 是否为次要的错误？
进度
- 何时需要进行变更？
- 是否可行？
影响
- 进行变更的后果如何？
- 不进行变更的后果如何？
成本
- 进行变更的成本或节约的资金是多少？
与其他变更的关系
- 其他变更是否可以取代此变更或使其无效吗，或者此变更是否依赖于其他变更？
测试
- 是否存在任何特殊的测试需求？
示例变更请求表
-
标识信息
项目：
变更请求号：
变更请求类型：（问题或扩展）
标题：
提交日期：
始发人:
变更请求优先级：
-
当前问题
当前问题的说明：
严重故障：
障碍：
扩展：
新请求：
观察问题的环境：
当前环境：硬件
操作系统
编译器
当前问题的来源：
当前问题的成本影响：
-
提议的变更（始发人）
提议的变更的说明：
实施提议变更的预计成本：
-
提议的变更（变更复审团队）
操作：
批准：
不批准：
延期：
提议的变更的说明：
影响的配置项：
类别：
错误修复：
扩展：
新特性：
其他：
-
解决方案
实施提议变更的预计成本：
实施员：
实施变更的实际时间：
分析：
实施：
测试：
文档：
影响的代码行数：
-
评估
测试方法：
检查
分析
演示
测试：
测试平台：
测试实例：
-
变更复审团队的处理
批准的变更和接受的变更：
时机
通常在项目生命周期的初期使 CM 操作制度化或建立 CM 操作。因此，变更请求（CR）作为构成变更流程整体的一部分，可以随时在项目过程中提出。
缺陷的主要来源是运行测试的结果（集成、系统和性能测试）。然而，缺陷可以随时出现在软件开发生命周期过程中，缺陷还可包括缺失的或不完整的用例、测试用例或文档的确认。
职责
有关项目的任何人员都应该可以提出变更请求。 然而，变更请求要得到提出变更请求角色上司的复审和批准才能成为合法请求。变更请求的最后仲裁由复审团队或变更控制委员会（CCB）执行。
变更控制经理负责缺陷的完整性，以确保：
- 所有确定缺陷、说明缺陷和如何发现缺陷的信息都是准确的。
- 缺陷是唯一的，或不是再次出现的已确定缺陷。
定制
准确确定、说明和追踪缺陷需要的实际字段/数据取决于实施的标准、指南和变更控制系统。
