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

    項(xiàng)目經(jīng)理勝任力免費(fèi)測評PMQ上線啦！快來測測你排多少名吧~

    http://opto-elec.com.cn/pmqhd/index.html