置项的修改提出一个变更请求，说明对软件变更的需求。这是因为变更控制过程是通过变更请求的流动来实现的，而且对软件的任何请求都必须和相应的变更请求对应。
变更请求的状态包括：
1)提交：变更请求提交给配置管理员；
2)拒绝：变更控制委员会拒绝变更请求；
3)接受：变更控制委员会接受变更请求；
4)挂起：变更请求被挂起，以后再作决定；
5)已验证：更改已执行和验证；
6)关闭：验证并归档配置项，更新的配置项提交给用户(例如：通过版本发布)。
变更请求的类型
1)增强型：变更请求要求对已批准的项目功能进行增强。
2)改进型：变更请求不会造成功能更改，但使配置项的维护更加有效率。
3)纠错型：变更请求对错误进行修正(诸如bug)。
变更请求的优先级
在评价变更请求的优先级时，要对请求变更的配置项进行系统的分析，确定变更影响范围和修改的程度，确定变更的级别，为确定是否有必要记录变更提供参考依据。变更请求的优先级可分为三类：
1)高：严重地影响一些用户或许多用户。
2)中：对用户造成不方便，或是可以采取相应的变通方法处理的主要问题。
3)低：小问题。
修改完后签入（Check in）
对变更的处理，要按照变更控制规程，将变更请求及其相关附件提交软件配置控制委员会审批。配置管理组根据审批意见处理变更请求。
只有配置管理员具有Check in权限。在进行Check in之前，确认下面的事项：
1)所有对配置项所做的修改被批准；
2)所有的更改都经过审核或验证；
3)所对应的变更请求已经被保存起来；
4)所有相关的审核记录被保存；
5)Check in时须注明Check in原因，如对应的变更请求。
从数据库中签出（Check out）
1)对于文档，配置管理员在更改审批人同意后，从配置库中Check out配置项，发给项目组成员修改。
2)Check out时须注明Check out原因，如将要修改的问题。
3) 配置管理员一定要在配置状态发布中跟踪被Check out出来的配置项。