行需求變更。一般把需求變更或者新需求的確認最遲時間定在系統(tǒng)培訓(xùn)階段。也就是說，在系統(tǒng)培訓(xùn)完成后、開始準備雙線并行前，企業(yè)用戶還可以提出需求變更的申請，但是，當系統(tǒng)開始雙線運行時，就不允許用戶再提出需求變更等類似的請求了，如編碼的內(nèi)容和規(guī)則、表單的數(shù)量和格式、數(shù)據(jù)流轉(zhuǎn)和統(tǒng)計方式等，否則就要付出變更的代價。
建立變更控制組織系統(tǒng)。項目啟動時，盡可能地與客戶溝通，盡快建立正式的對變更進行控制的組織，通稱變更控制委員會(CCB)，成員可包括雙方高層(掛名)、甲乙雙方的項目負責(zé)人、相關(guān)的需求負責(zé)人等，負責(zé)裁定接受變更內(nèi)容、方法、步驟等。建立該系統(tǒng)的目的是統(tǒng)一管理需求變更和跟蹤變更的狀態(tài)，便于項目組測試人員、開發(fā)人員、系統(tǒng)分析員以及PM相互之間的溝通和交流。建立變更控制系統(tǒng)目的不是讓用戶不提出變更，而是讓用戶不輕易、隨便的提出變更。
嚴格規(guī)范變更流程。一旦需求分析階段結(jié)束，此后如果用戶要求有新的需求加入即將交付的軟件系統(tǒng)中，甲乙雙方的項目組或變更控制委員會，要根據(jù)角色定義，確定變更流程，規(guī)定嚴格的變更控制流程，并控制新需求提出的頻率。
1)變更申請。系統(tǒng)界面如按鈕的位置、字段的位置的細微調(diào)整，不涉及到業(yè)務(wù)規(guī)則，對基線基本沒有影響的變更，由測試人員直接在變更控制系統(tǒng)中提出;其他如操作風(fēng)格的較大變化、編碼內(nèi)容、業(yè)務(wù)規(guī)則的變化等，均要求用戶提出電子和書面的需求變更單。
2)變更評估。由項目組或變更控制委員會組織人員對變更進行變更的合理性分析，變更替換方案分析，工作量的估算以及涉及什么模塊、影響什么模塊等影響分析。
3)變更實施。由測試人員在變更控制系統(tǒng)中填寫變更信息，由系統(tǒng)分析員填寫處理方法和影響分析后交由開發(fā)人員實施。
需求變更后，受影響的軟件計劃、產(chǎn)品、活動都要進行相應(yīng)的變更，以保持和更新的需求一致。
選用適當?shù)拈_發(fā)模型防止多變更。采用建立原型的開發(fā)模型比較適合需求不明確的開發(fā)項目。軟件供應(yīng)商研發(fā)人員先根據(jù)用戶對基本需求的說明建立一個系統(tǒng)原型，再與用戶溝通。一般用戶看到一些實際的東西后，對需求會有更為詳細的解釋，開發(fā)人員可根據(jù)用戶的說明進一步完善系統(tǒng)原型。這個過程重復(fù)幾次后，系統(tǒng)原型逐漸向用戶最終、比較全面的需求靠攏，從根本上減少需求過多變更的出現(xiàn)。目前業(yè)界較為流行的疊代式開發(fā)方法對工期緊迫的項目的需求變更控制較為管用。通常情況下，原型之后的需求溝通就實際得多，雙方的理解迅速向一個全面折衷的方案貼近，一個可以指導(dǎo)研發(fā)過程、有針對性的需求說明書就可起到重要作用。
通過合同約束，建立有效的解決沖突機制。用戶、開發(fā)商在實施、驗收軟件項目過程中難免會發(fā)生沖突，而需求變更給軟件項目建設(shè)帶來的影響也是有目共睹，從而可能讓項目建設(shè)偏離軌道。關(guān)鍵是事先是否有明確的項目目標和項目要求，是否建立起有效的沖突解決機制。所以雙方在簽訂合同時，可以增加一些相關(guān)條款，主要是要明確今后雙方責(zé)權(quán)利關(guān)系，如限定用戶提出需求變更的時間，規(guī)定何種情況的變更可以接受、拒絕接受或部分接受，還可以規(guī)定發(fā)生需求變更時必須執(zhí)行變更控制流程，否則自擔(dān)變更的代價;而企業(yè)用戶，也可對將來可能發(fā)生重大事件或不可抗拒事件所引發(fā)可能的實施超期、費用超支、產(chǎn)品價格調(diào)整以及服務(wù)收費超標等事項、行為及其權(quán)責(zé)做出預(yù)測，并有效約定，從而使信息化項目從一開始就按雙方預(yù)定的規(guī)道行駛，互為制約、協(xié)調(diào)，避免再發(fā)意外。
驗收與發(fā)現(xiàn)、檢驗需求并舉。大型的ERP項目不少是邊實施邊驗收，然后再發(fā)現(xiàn)新問題新需求，再進一步返工完善，一步一步地把項目向前推進