置項的修改提出一個變更請求，說明對軟件變更的需求。這是因為變更控制過程是通過變更請求的流動來實現的，而且對軟件的任何請求都必須和相應的變更請求對應。
變更請求的狀態(tài)包括：
1)提交：變更請求提交給配置管理員；
2)拒絕：變更控制委員會拒絕變更請求；
3)接受：變更控制委員會接受變更請求；
4)掛起：變更請求被掛起，以后再作決定；
5)已驗證：更改已執(zhí)行和驗證；
6)關閉：驗證并歸檔配置項，更新的配置項提交給用戶(例如：通過版本發(fā)布)。
變更請求的類型
1)增強型：變更請求要求對已批準的項目功能進行增強。
2)改進型：變更請求不會造成功能更改，但使配置項的維護更加有效率。
3)糾錯型：變更請求對錯誤進行修正(諸如bug)。
變更請求的優(yōu)先級
在評價變更請求的優(yōu)先級時，要對請求變更的配置項進行系統的分析，確定變更影響范圍和修改的程度，確定變更的級別，為確定是否有必要記錄變更提供參考依據。變更請求的優(yōu)先級可分為三類：
1)高：嚴重地影響一些用戶或許多用戶。
2)中：對用戶造成不方便，或是可以采取相應的變通方法處理的主要問題。
3)低：小問題。
修改完后簽入（Check in）
對變更的處理，要按照變更控制規(guī)程，將變更請求及其相關附件提交軟件配置控制委員會審批。配置管理組根據審批意見處理變更請求。
只有配置管理員具有Check in權限。在進行Check in之前，確認下面的事項：
1)所有對配置項所做的修改被批準；
2)所有的更改都經過審核或驗證；
3)所對應的變更請求已經被保存起來；
4)所有相關的審核記錄被保存；
5)Check in時須注明Check in原因，如對應的變更請求。
從數據庫中簽出（Check out）
1)對于文檔，配置管理員在更改審批人同意后，從配置庫中Check out配置項，發(fā)給項目組成員修改。
2)Check out時須注明Check out原因，如將要修改的問題。
3) 配置管理員一定要在配置狀態(tài)發(fā)布中跟蹤被Check out出來的配置項。