需求變更是要經過申請、審批、執行、確認等流程。

        為什麼要做需求變更的管理？主要原因有兩個:

1. 防止範圍蔓延引起的進度、成本、質量上，甚至嚴重時導致專案全面失敗的問題；

2. 為以後留下籌碼，以後要求追加費用也好，或者讓客戶看到我們送給他們的人情也好，總之是為了使以後與客戶相關的工作更順暢。除了這兩個原因之外，當然還有一些不是特別重要的原因，比如使需求、設計、開發、測試之間對變更的理解等等。

        需求變更管理的流程

1. 就是與客戶一起，約定變更管理的流程. 最好在合同中約定，至少也要在啟動會上約定

2. 提出變更申請. 而變更申請的提出，也應該按照約定的流程通過由負責人提交給專案經理

3. 專案經理收到需求變更申請，先了解前因後果和客戶的目標，然後優先從系統外解決，如果不行的話再進行變更工作量的評估和影響的分析，進行審批

4. 審評過程中銷售人員起到很重要的作用，因為銷售要給出變更所需費用的來源，並要給出承諾，否則變更沒辦法繼續。

5. 其他審批人則根據自己的角色和職責進行審批即可。

6. 審批結束，進入執行環節，對絕大多數的變更，都可以不用馬上執行變更動作，可以幾個變更作為一批一起執行，一方面可以降低頻繁變更對專案工作的影響，另一方面對一些客戶一時興起變過來過不久又變回去的變更可以起到攔截作用。

7. 採用敏捷的開發方式進行開發，所以將需求納入產品Backlog,然後分成

敏捷可以提供最佳的實踐做法,比如測試驅動開發(TDD[編寫的case當前不能通過，實現後通過])、特徵驅動開發(FDD),結對程式設計(Paring Coding)或者快速Review 粒子任務等,並且提供給軟體開發組織各種敏捷的開發和管理框架,其中應用最為廣泛的是SCRUM。敏捷也需要概要設計，要設計出各模組的功能與介面;

有幾點是在制定產品Backlog中要明確的:

第一,產品Backlog　SCRUM實施過程允許隨著專案進展而進行變更,或者增加,或者修改,或者刪減其中的一些特徵;

第二,產品Backlog的制定需要客戶參與,並且由客戶做出選擇;

第三,產品Back-log有一個擁有者;

產品Backlog的優先排序原則將取決於特徵的價值,也就是說,如果不是現在就實現這個功能,會存在哪些風險,或者要丟失什麼樣市場機遇,應該根據價值原則做出決定;

需要對產品Backlog的各特徵項進行大小和複雜程度進行估計；

8.再之後是確認，需求變更之後的原型，需要在修改完之後就確認，而最終變更結果，則在系統驗收時，統一確認。