需求變更是軟件項目一個突出的特點，也是軟件項目最為普遍的一個特點。雖然這與人類認識問題的自然規律是一致的，但是頻繁而無管理的需求變更非常容易導致復雜、無形的軟件在多變的情況下失控，加劇了
軟件開發過程中的不穩定性，從而造成多方的損失。那么如何對需求變更加以有效的控制和管理，從而保證軟件開發的進度、成本和質量，便成為軟件開發過程中一個值得思考的問題。
下面，我們將“需求變更管理”作為一個“項目”，按照問題定義、需求分析、設計、開發等步驟，從軟件工程的角度來加以分析，而這樣的討論過程也正符合了我們的開發流程，相信大家會對需求變更管理的認識更加深刻。
問題定義
根據軟件工程思想，需求說明書一般要經過需求評審的過程。在需求說明書經過論
證后，需要在原有基礎上補充新的需求或對其進行修改和刪減，則均屬于需求變更。
這是軟件開發過程中不可避免的問題，如何有效應對和處理需求變更，已經成為一個廣泛受到關注的話題。
需求分析及評價
由于頻繁需求變更且同時缺乏有效控制流程而導致軟件項目失敗的案例不勝枚舉，
面臨這種不穩定性，如果開發團隊缺少明確的需求變更管理控制或者采用的控制機制無效，很可能出現成本增高、人力緊缺、項目拖延甚至是失敗，這也就有了進行需求變更管理的需求。
誠然，需求變更管理不可能根本解決問題，但是實施嚴格的軟件需求變更管理能最大限度地控制需求變更帶來的負面影響，從而保證項目的可控性和穩定性，這也正是進行需求變更管理的目的所在。
設計
這里的設計指的就是如何來制定需求變更管理的執行計劃。主要分以下幾個階段：
獲取需求基線：需求的基線是指是否容許需求變更的分界線。需求分析人員在充分與客戶用戶進行溝通的基礎上形成第一個版本的需求文檔，這個需求文檔在通過需求評審后即可以建立第一個需求基線。此后每次需求變更并經過需求評審后，都要重新確定新的需求基線。變更控制委員會為有效進行需求變更控制，必然要做的
工作就是保存好各個版本的需求基線，維護需求基線文檔，以備不時之需。隨著項目的進展，基線將越定越高，即容許的需求變更將越來越少。
分析變更影響：對于提交的每項需求變更請求，應確定它對項目整體進度的影響和對其他相關開發任務的影響，并且一定要明確完成這些變更相關任務的工作量。只有經過全面的分析，變更控制委員會才能夠做出更好的決策。進行變更影響分析可以對申請的需求變更有更深刻的理解，通過對變更內容的更深刻的理解，才能做出對正在進行的工作的調整的部署。
維護變更記錄：記錄每個需求變更文檔的版本號、日期、所做的變更、原因等，當然應該明確該文檔由誰來負責更新。
衡量需求穩定性：變更控制委員會需要對需求變更的整體有良好的把握，通過記錄需求基準的數量可以獲得宏觀需求的變更次數；同時還應該記錄一段時間內（如每周、每月）的變更數量，最好按變更的類別來列出詳細信息。如果某一需求過于頻繁變更，則說明對該問題的認識還不深入或者說還沒有達成一致的處理意見；如果需求變更的總體數量過高，則意味著項目范圍并未很好地確定下來或是政策變化較大。
使用
需求管理工具：需求變更控制委員會可以采取商業化的需求管理工具，以此來在
數據庫中存儲不同類型的需求。這些工具提供了對每項需求的屬性描述，狀態跟蹤等，并可以在需求與其它的相關工作產品建立跟蹤能力聯系鏈。
開發
這里的開發指的就是如何在項目的開發過程中有效實施需求變更管理。實施需求變更管理需要遵循如下三個階段的原則：
需求變更的前緒工作：
1.項目的高效進行，需要良好的高質量的需求，同時它也是需求變更的依據。
2.建立以文檔形式存在的簡單、有效的變更控制流程。
3.建立項目變更管理執行小組及變更控制委員會。委員會成員組成涉及項目的多方人員，至少應包括用戶方代表和開發方的決策人員。小組成員可以由負責需求的人員中有經驗的需求分析員來擔當。
需求變更進行時：
需求變更的流程一定要遵循由變更控制委員會制定的變更控制流程。變更控制一般要經過變更申請、變更評估、委員會決策、委員會回復、實施變更、變更驗證六個步驟。
1.變更申請：隨著項目的深入，需求變更也是不可避免的。需求分析小組一定要在充分考慮用戶需求，項目進度，需求基線的基礎上提交變更申請，并提供盡可能詳細的說明以供變更控制委員會進行變更評估。
2.變更評估：需要對提出的變更需求進行影響分析，評估變更是否在項目范圍內，對項目計劃安排和其它需求的影響，需要的工作量等等。
3.委員會決策：根據評估作出決策以確定選擇哪些，放棄哪些，并設置實現的優先順序，制定目標版本。
4.委員會回復：回復包括同意實施變更和拒絕實施變更，并制定相應變更方案或說明拒絕理由。
5.實施變更：維護需求變更文檔，包括：日期以及所做的變更、原因、負責人及新的版本號等等。該工作可以由委員會或者責成執行小組來完成。
6.變更驗證：充分和提交變更申請人進行溝通，以使其得到滿意答復。然后根據變更方案和需求基線，進行相應的需求變更后的工作。該工作可以由執行小組來完成。
需求變更后：
參照需求跟蹤能力矩陣找到受需求變更影響的工作產品，并進行一致性變更，同時要維護變更歷史記錄。所有這些工作也是至關重要的內容，需要慎重細致對待，否則對持續的需求變更來講，將是一場災難。
項目結束
一個項目的交付驗收，并不意味著項目的真正結束，一個優秀的項目管理人員善于在項
目結束后進行總結。項目總結工作當然要包括那些沒有預料到而發生的需求變更，以及這些變更的應對措施。根據實際工作中遇到的需求變更管理的問題，筆者總結如下幾點，以供參考和交流：
◆良好氣氛下的充分交流 討論需求及變更需求時，需求人員與客戶及用戶應該盡量采取協作的態度，良好的工作氛圍也會提高工作效率，很難想象雙方在“刁難”與“對付”的態度下是一種該有多糟糕的工作場景。確定需求基線的過程也就是與客戶用戶交流的過程，而頻繁大量的需求變更在很大程度上也是交流不充分的后果。所以，有效的充分的交流尤為重要，需求人員認真聽取客戶用戶的要求，進行分析和整理。同時還應該有能力設想項目的開發過程中可能會遇到的由該需求導致的問題，同時要讓客戶認識到如果此時再提出需求變更，將會給整個項目帶來的各種影響和沖擊。
◆專職人員負責需求變更管理 在具有相當規模的項目中，專職的需求人員和由此組成的需求變更執行小組是項目穩定、進度良好的保證。沒有變更管理而直接由開發人員處理的需求變更將會給項目帶來毀滅性的災難。這些專職人員應該具有專業的需求分析技巧技能，針對用戶的變更需求，可以給用戶說明利弊，可以按緊迫程度為開發人員提供工作重點，同時， 他們應該還能控制需求變更的頻率。
◆明確合同約束，限制需求變更 需求在軟件項目中的地位已經越來越重要，需求變更給軟件開發帶來的影響也是有目共睹，甚至因為質量低下的需求或者頻繁無控制的需求變更而導致項目的失敗。因此，應該讓客戶明白需求變更給項目帶來的工期、成本等各方面的影響，在互相理解的基礎上增加合同條款，比如明確說明客戶可以提出需求變更的期限，超過期限的需求變更的具體處理細則(如增加開發費用等，需求變更與開發費用本身也是關聯的，這個要求并不過分)。
◆良好的軟件結構適應需求變更 優秀的軟件體系結構可以快速應對不同情況的需求變
更，這樣就可以適當降低需求的基線（當然是在成本影響的允許范圍內），從而來提高客戶的滿意度。適應需求變更必須遵循一些設計原則，如松散耦合、合理的接口定義等，要力求減少會對接口入口參數產生變化。