是需求變更的依據(jù)。在開發(fā)過程中，需求確定并經(jīng)過評審后（用戶參與評審），可以建立第一個需求基線。此后每次變更并經(jīng)過評審后，都要重新確定新的需求基線。
2..制訂簡單、有效的變更控制流程，并形成文檔。在建立了需求基線后提出的所有變更都必須遵循這個控制流程進行控制。同時，這個流程具有一定的普遍性，對以后的項目開發(fā)和其他項目都有借鑒作用。
3.成立項目變更控制委員會（CCB）或相關(guān)職能的類似組織，負責裁定接受哪些變更。CCB由項目所涉及的多方人員共同組成，應(yīng)該包括用戶方和開發(fā)方的決策人員在內(nèi)。
4.需求變更一定要先申請然后再評估，最后經(jīng)過與變更大小相當級別的評審確認。
5.需求變更后，受影響的軟件計劃、產(chǎn)品、活動都要進行相應(yīng)的變更，以保持和更新的需求一致。
6.妥善保存變更產(chǎn)生的相關(guān)文檔。
需求變更既然不可避免，那么就必須有一套規(guī)范的處理流程。對于需求變更的處理流程應(yīng)該分以下步驟：提出變更à變更評估à實施變更。
需求變更處理流程
因為現(xiàn)實世界的軟件系統(tǒng)可能有不同的嚴格程度和復(fù)雜性，所以事先預(yù)言所有的相關(guān)需求是不可能的。系統(tǒng)原計劃的操作環(huán)境會改變，用戶的需求會改變，甚至系統(tǒng)的角色也有可能改變。實現(xiàn)和測試系統(tǒng)的行為可能導(dǎo)致對正解決的問題產(chǎn)生新的理解和洞察，這種新的認識就有可能導(dǎo)致需求變更。CMM提出“分配需求的變更被復(fù)審，并加入到軟件項目中來”，其關(guān)鍵是在需求發(fā)生變更時，沒有必要馬上把這些變更付諸于軟件開發(fā)工作之中。實際上，堅持把需求變更付諸開發(fā)努力，企業(yè)就會形成一種混亂且不穩(wěn)定的氛圍，進而嚴重破壞項目的控制和管理。需求管理關(guān)鍵過程試圖通過把分配需求的變更囤積到可管理的組中，等到開發(fā)工作允許的時候再引人相應(yīng)的方法，避免產(chǎn)生這種混亂的氛圍。結(jié)果，需求管理創(chuàng)建了一個隔絕開發(fā)工作與所有真實的、潛在無序的、來自于客戶的變更。這個緩沖器允許真實的變更被注意、記錄、追蹤，同時開發(fā)工作又不會因此而被擾亂。開發(fā)項目應(yīng)該周期性地暫停來吸收最新的需求變更積累，此時，所有的計劃、設(shè)計、行為都根據(jù)剛剛吸收的需求變更的影響進行更新。
需求變更的控制當然與項目管理范疇之外的純技術(shù)因素息息相關(guān)，比如面向?qū)ο蟮姆治?、面向?qū)ο蟮脑O(shè)計、面向?qū)ο蟮木幋a方式等等。但所有技術(shù)的發(fā)展趨勢都是一樣，那就是為了使變更管理變得更容易，因此，不論在項目變更控制中采取什么方法、策略，對于項目本身的變化一定要時時洞悉，處處留意，只有這樣才能從真正意義上對項目進行很好的變更控制。
項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~
http://m.opto-elec.com.cn/pmqhd/index.html
