一、做好需求工程
需求分析是軟體工程專案最重要、最基礎的起始階段，為後續的規劃設計階段提供參照依據。在軟體研發專案過程中一定要樹立需求工程的意識，將需求視為一項系統工程。為了能夠全面做好需求管理，應根據專案實際情況嚴格劃分專案階段，清晰界定、定義專案階段的基線，在每個專案階段制訂、執行階段性需求管理計畫，逐一認真落實。
1.需求工程的結構及目標任務
需求工程是乙個包括建立和維護系統需求文件所必需的一切活動的過程。需求工程中的活動可分為兩大類，一類屬於需求開發，另一類屬於需求管理。
需求開發的目的是通過調查與分析，獲取使用者需求並定義產品需求。需求開發過程有3個主要活動：需求調查、需求分析、需求定義。需求開發過程可分為兩個階段：使用者需求調查階段和產品需求定義階段，兩個階段在邏輯上通常是以迭代的形式進行的。需求開發過程產生的主要文件有《使用者需求說明書》、《產品需求規格說明書》(對於軟體產品而言就是《軟體需求規格說明書》)。
需求管理的目的是在使用者與開發商之間建立對需求的共同理解，維護需求與軟體工作成果的一致性，並控制需求的變更。需求管理過程有三項主要活動：
(1)需求確認:開發商和使用者共同對需求文件進行評審，雙方就需求達成共識後做出書面承諾，使需求文件具有商業合同效果。
(2)需求跟蹤:通過比較需求文件與後續工作成果之間的對應關係，建立與維護「需求跟蹤矩陣」，確保產品依據需求文件進行開發。
(3)需求變更控制:依據「變更申請、審批、實施、重新確認」的流程處理需求的變更，防止需求變更失去控制而導致專案發生混亂。
需求管理過程產生的主要文件有《需求評審報告》、《需求跟蹤報告》、《需求變更控制報告》等。
2.需求的跟蹤
需求跟蹤的目的是建立與維護「需求、設計、程式設計、測試」過程的一致性，確保所有的工作成果符合使用者需求。需求跟蹤有兩種方式：
(1)正向跟蹤：檢查《產品需求規格說明書》中的每個需求是否都能在後繼工作成果中找到對應點。
正向跟蹤和逆向跟蹤合稱為「雙向跟蹤」。不論採用何種跟蹤方式，都要建立與維護需求跟蹤矩陣。
二、組建變更控制管理機構
專案變更是指專案實施過程中由於環境或者其他因素的變化而對專案部分或者全部功能、效能、架構、技術指標、整合方案、進度、質量等方面做出改變。
1.變更控制管理的任務及目標
資訊系統專案實施過程中變更是無法避免的。變更控制管理的任務是：建立規範、嚴格、可行、高效的變更控制體系機制，組建變更控制管理機構，出台變更管理制度;對使用者提交的變更請求進行快速的響應、受理;及時分析、研究、評估變更的可行性、成本、代價、範圍;對於確定接受的變更請求制訂變更實施計畫方案及配套應對措施，實施變更任務，進行變更測試檢查，做好變更記錄。需求變更控制的最終目標是：通過建立嚴格規範的變更控制管理流程,拒絕不切合實際的變更，減少變更帶來的風險，防止變更範圍擴大、蔓延，杜絕隨意的變更申請及受理過程等。
2.變更控制管理機構的建立
組建有效的變更控制管理機構和制訂配套的變更控制管理制度，是進行變更控制管理的重要基礎和前提保障，否則變更控制管理將成為一紙空文。變更控制管理機構(形式上可以是「變更控制管理委員會」、「變更控制管理辦公室」、「變更控制管理組」等)是乙個特殊組織，對專案負責人直接負責，它不受現存的職能組織結構的束縛,可由來自不同機構、不同部門、不同專業、不同崗位的人員組成，各成員劃分許可權崗位、明確職責、落實責任、協同工作。一般情況下，變更控制管理機構內部應至少配備以下四種角色的成員：
專案管理人員(類似於「專案經理」)：主要負責制訂專案管理制度和專案管理計畫，督促、檢查、落實、考核專案執行過程，做好專案干係人之間的溝通協調工作。
技術負責人員(類似於「總工程師」)：主要負責專案中資訊科技平台的分析、建模、設計、測試、實現。
通訊聯絡人員：主要負責專案組織內部成員之間的資訊發布。
需求變更控制管理工作程式
需求變更的目的是希望軟體產品更加符合使用者的需求，但是變更涉及的人員多、範圍廣、影響大，在進行變更控制管理時必須建立嚴格、規範的變更控制管理工作程式，這樣才能使專案始終按照預定的方向、模式、進度進行。
需求變更控制過程中最難辦的事情不是「滿足使用者提出的變更請求」，而是「在使用者認同支援、追加專案投資經費的前提下盡快完成變更任務」。使用者往往認為提出變更需求是基本權利，而軟體開發商往往認為只有義務解決在《使用者需求說明書》、《產品需求規格說明書》中預先定義的各類需求，除此以外都應該拒絕或者在使用者追加投資的前提下解決。
現實中資訊系統專案的目標是具有一定彈性的，這一點尤其重要，使用者和軟體開發商之間為了達成共同目標不可能針鋒相對，專案管理人員需要利用高超的管理藝術、溝通技巧、人格魅力，在對立博弈的關係之中尋求最佳的平衡點。
另外，有必要強調的是，在專案實施過程中，變更處理越早，難度越小，損失越小;變更處理越遲，難度越大，損失也越大。而且，任何變更都必須經過專案建設全部相關方(建設單位、承建單位和監理單位)多方確認後才能計畫實施，嚴禁任何一方擅自變更。對專案變更的範圍要有明確的界定，而且專案建設全部相關方對變更範圍的理解上都沒有任何異議。
最後，變更對專案質量、成本、進度都會產生影響,需要對變更過程加強監控，實施變更風險管理，不能因為變更而引發新的風險。專案管理人員在做出變更決策時，應及時將變更資訊、變更計畫方案公布於眾，這樣才能及時調整專案團隊的工作，朝著新的方向努力。
需求變更管理
需求變更 是業界公認的專案管理重大挑戰，尤其是專案後期產生的需求變更，對專案的影響是非常大的。但是，需求開發不可能做到完美無瑕，而且隨著客戶對專案和系統的了解，很有可能提出新的需求或者對原有的需求作出修正。因此，需求的變化是不可避免的。對於如何應對需求變更，主要的思路有兩條 首先是從源頭做起，提高需...
專案管理問題之需求變更
案例情景 該專案整個週期為2個月 有3 能測試，當第 3 能測試結束時也就是即將進入預發布階段時，需求提出方才把使用者反饋資訊給了我們，要求我們按使用者的要求去改。改動的地方涉及到頁面的樣式，文案，sql語句，校驗邏輯等，總共可能有 20個左右的檔案要被改動。我們建議只改頁面的樣式和文案，其他部分先...
軟體開發需求變更管理 摘錄
當乙個需求 或者策劃案 還處在策劃階段，還沒有被送去開發與實現的時候，我們允許這個需求發生改變，甚至允許它發生任何的改變，沒有任何限制。而一旦這個需求被送去開發與實現了，那麼我們將不再允許這個需求發生任何改變，需求與設計將會被鎖定，開發人員將會按照鎖定的版本進行開發。如果在開發過程中，策劃人員實在忍...