需求變更既然不可避免，那么就必須有一套規范的處理流程。對于需求變更的處理流程應該分以下步驟：提出變更à變更評估à實施變更。下圖簡要地描述了一般需求變更的處理流程：
需求變更處理流程
因為現實世界的軟件系統可能有不同的嚴格程度和復雜性，所以事先預言所有的相關需求是不可能的。系統原計劃的操作環境會改變，用戶的需求會改變，甚至系統的角色也有可能改變。實現和測試系統的行為可能導致對正解決的問題產生新的理解和洞察，這種新的認識就有可能導致需求變更。CMM提出“分配需求的變更被復審，并加入到軟件項目中來”，其關鍵是在需求發生變更時，沒有必要馬上把這些變更付諸于軟件開發工作之中。實際上，堅持把需求變更付諸開發努力，企業就會形成一種混亂且不穩定的氛圍，進而嚴重破壞項目的控制和管理。需求管理關鍵過程試圖通過把分配需求的變更囤積到可管理的組中，等到開發工作允許的時候再引人相應的方法，避免產生這種混亂的氛圍。結果，需求管理創建了一個隔絕開發工作與所有真實的、潛在無序的、來自于客戶的變更。這個緩沖器允許真實的變更被注意、記錄、追蹤，同時開發工作又不會因此而被擾亂。開發項目應該周期性地暫停來吸收最新的需求變更積累，此時，所有的計劃、設計、行為都根據剛剛吸收的需求變更的影響進行更新。
需求變更的控制當然與項目管理范疇之外的純技術因素息息相關，比如面向對象的分析、面向對象的設計、面向對象的編碼方式等等。但所有技術的發展趨勢都是一樣，那就是為了使變更管理變得更容易，因此，不論在項目變更控制中采取什么方法、策略，對于項目本身的變化一定要時時洞悉，處處留意，只有這樣才能從真正意義上對項目進行很好的變更控制。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
