近年來，網際網路推動了大型IT行業資訊科技的飛速發展，大型IT行業資訊化手段與技術的採用越來越突出，軟體需求量越來越大。在專案需求快速增長的現狀下，業內人士在專案管理過程中不得不面對一個貫穿整個專案始末的問題——即需求變更，需求的變更在大型IT專案管理過程中對整個生命週期產生非常大的影響，如果不能及時的管控，專案計劃和交付日期便會一拖再拖，不僅使企業對整個專案失去信心，同時開發人員也會產生很大的負面情緒。如何有效的對需求變更進行科學的管控是每一位專案參與成員需要思考的問題。
專案經理需要在變更產生之初，判斷其原因並確認涉及範圍，進而採用合適的變更管控方法。積極地控制專案中所產生的變更，而不是被變更所控制。
一、為什麼要變更需求
大型IT專案需求變更的表現形式是多方面的，比如：專案預算增加或減少、高層領導臨時改變決策、增加或者減少功能、行業政策的變化等。企業為什麼要變更需求，原因是什麼？
1、範圍沒有圈定就急於細化 需求細化是根據客戶提出的描述性的、總結性的語言去細化的，提取其中的功能，並給出細化的描述。當細化到一定程度後並開始系統設計時，範圍可能會發生變化，那細節用例的描述可能就有很多要改動。如原來需求文件是整體匯入匯出，要改為指定範圍和內容匯入匯出，如原來需求是多元交叉受理，要改為集中受理、統一需求入口和出口等。
2、沒有指定需求的基線 需求的基線是指是否容許需求變更的分界線。隨著專案的進展，需求的基線也在變化。是否容許變更的依據是合同以及對成本的影響，比如軟體整體結構已經設計出來是不容許改變需求範圍的，因為整體結構會對整個專案的進度和成本有初步預算。專案進展越深入，基線將越定越高，容許的變更將越少。
3、沒有良好的軟體結構適應變化 元件式的軟體結構就是提供了快速適應需求變化的體系結構，資料層封裝了資料訪間邏輯，業務層封裝了業務邏輯，表示層展現使用者表示邏輯。但適應變化必須遵循松耦合原則，各層之間還是存在一些聯絡的，設計要力求減少會對介面入口引數產生變化。如果業務邏輯封裝好了，則表示層介面上的一些排列或減少資訊的要求是很容易適應的。如果介面定義得合理，那麼即使業務流程有變化，也能夠快速適應變化。因此，在成本影響的容許範圍內可以降低需求的基線，提高客戶的滿意度。
二、需求變更管理的實施準則
大型IT專案需求變更時，如果開發團隊缺少明確的需求變更控制過程或採用的變更控制機制無效，抑或不按變更控制流程來管理需求變更，那麼，很可能造成專案進度拖延、成本不足、人力緊缺，甚至導致整個專案失敗。
當然，即使按照需求變更控制流程進行管理，由於受進度、成本等因素的制約，軟體質量還是會受到不同程度的影響。但實施嚴格的軟體需求管理會最大限度地控制需求變更給軟體質量造成的負面影響，具體實施準則如下：
1、建立需求基線，需求基線是需求變更的依據。在開發過程中，需求確定並經過評審後(使用者參與評審)，可以建立第一個需求基線。此後每次變更並經過評審後，都要重新確定新的需求基線。
2、制訂簡單、有效的變更控制流程，並形成文件。在建立了需求基線後提出的所有變更都必須遵循這個控制流程。同時，這個流程具有一定的普遍性，對以後的專案開發和其他專案都有借鑑作用。
3、成立專案變更控制委員會(CCB)或相關職能的類似組織，負責裁定接受變更。CCB由專案所涉及的多方人員共同組成，包括行方和開發方的決策人員在內。
4、需求變更一定要先申請然後再評估，最後經過與變更大小相當級別的評審確認。
5、需求變更後，受影響的軟體計劃、產品、活動都要進行相應的變更，以保持和更新的需求一致。
6、妥善儲存變更產生的相關文件。
三、需求變更的有效管理
需求變更對大型IT開發專案成敗有重要影響，既不能一概拒絕客戶的變更要求，也不能一味地遷就客戶，所以，實施需求變更之前必須做好控制。需求變更控制的目的不是控制變更的發生，而是對變更進行管理，確保變更有序進行。
1、明確合同約束，建立需求基線
對於大型IT開發專案，變更都無可避免，也無從逃避，只能積極應對，這個應對應該是從專案啟動的需求分析階段就開始了。對一個需求分析做得很好的專案來說，基準檔案定義的範圍越詳細清晰，客戶跟專案經理扯皮的幌子就越少。如果需求沒做好，基準檔案裡的範圍含糊不清，被客戶抓住空子，往往要付出許多無謂的犧牲。如果需求做得好，文件清晰且又有客戶簽字，那麼後期客戶提出的變更就超出了合同範圍，需要另外收費。這個時候千萬不能手軟，不能讓客戶養成頻繁變更的習慣。
在開發過程中，需求確定並經過評審後（客戶參與評審），建立第一個需求基線。此後每次變更並經過評審後，都要重新確定新的需求基線，做到小需求可以變更，但大方向要保證不頻繁變更。
2、建立變更審批流程
成功專案和失敗專案的區別就在於專案的整個過程是否是可控的。專案經理應該樹立一個理念——需求變更是必然的、可控的、有益的。控制需求漸變需要注意以下幾點：
一般來說，如果客戶認為該變更是必須的（不是其上級領導拍腦袋提出的）就會接受這些後果。透過與客戶協商，這樣開發團隊即使沒有回報，也不會招致公司和客戶雙方的埋怨。如果客戶認為該變更雖然有必要但是可以暫緩，雙方簽署備忘錄後留待以後解決。如果客戶認為該變更可有可無，多數情況下會取消變更。這樣即可防止頻繁變更，也讓客戶認識到不是所有的需求都需要變更。
3、用迭代方式應對需求頻繁修訂
大型IT專案開發過程中，建議採用迭代開發方式，每個階段的產品進行版本規劃，這樣在第一版本交付過程中，質量較好可以使客戶保持對專案成功的信心，這樣也可以使客戶需求更加明確和完善產品，客戶最關住的是研發過程中與實際後續版本提供系統構架和新技術領域的探索，在後續版本過程中不斷的對運營過程中分期完善，對系統的缺陷加以修訂，這樣才能保障軟體生命週期的延續。
四、需求管理工具體現的價值
Visual RM是一款基於大型IT專案管理特點的需求內容級管理工具，以大型IT專案管理視角，幫助IT專案實現需求“管得住、控得了、可跟蹤、可沉澱、可複用”的核心目標，其價值主要體現在以下方面：
1、由文件級轉為內容級需求管控，助力IT過程的精益管理：改變傳統的需求文件級管理過粗的方式，透過需求結構化、條目化技術，自動對需求文件進行自動化拆解，形成需求條目，將需求管理與跟蹤的顆粒度細化到條目級，使得需求內容切分（應用分配）、需求內容質量管控、開發和測試任務的需求分配、投產內容的需求跟蹤成為可能。
2、控好需求內容變更，維護好最新需求：Visual RM實現了需求文件級、條目級的需求基線管理，透過需求內容的變更控制手段，如：多人同時線上編制需求、變更需求、變更痕跡及歷史管理、變更內容前後比對、需求變更影響分析和自動通知受影響的相關人員，使需求變更過程方便、快捷，且變更過程透明、可回溯。
4、推動開發過程的需求協同，避免開發測試返工：需求傳遞由文件級過渡到需求內容級，使需求內容（全部或區域性）和需求變更都能快速傳遞到專案管理、開發、測試和投產過程的各環節對應的任務，使專案組所有成員都在同一份需求內容基礎上開展工作，形成以需求為主線的開發聯動，自動構建起從業務需求->專案->切分系統->軟體需求->開發->測試-投產版本的跟蹤脈絡，使需求的提出到落地實現過程變得透明。
5、需求資產沉澱，形成企業級的需求統一檢視：Visual RM可以幫助客戶按各類管理視角或框架（如：業務框架、應用系統框架、產品框架、組織框架）組織需求資產，透過從各專案需求文件中抽取需求資產，並按管理框架歸集和維護需求資產，確保可以從某一管理視角（如：某一系統、業務領域、產品型別等）獲取當前最新、最全的需求，以反映當前系統（或業務領域）的最新的需求全貌。
6、需求資產複用，快速編制需求：透過需求資產，需求分析人員在分析、編制需求時可以快速參考、引用需求資產內容，快速構建並形成新的需求；同時Visual RM可以支援多人協作並行編制需求，加速需求形成過程。
近年來，網際網路推動了大型IT行業資訊科技的飛速發展，大型IT行業資訊化手段與技術的採用越來越突出，軟體需求量越來越大。在專案需求快速增長的現狀下，業內人士在專案管理過程中不得不面對一個貫穿整個專案始末的問題——即需求變更，需求的變更在大型IT專案管理過程中對整個生命週期產生非常大的影響，如果不能及時的管控，專案計劃和交付日期便會一拖再拖，不僅使企業對整個專案失去信心，同時開發人員也會產生很大的負面情緒。如何有效的對需求變更進行科學的管控是每一位專案參與成員需要思考的問題。
專案經理需要在變更產生之初，判斷其原因並確認涉及範圍，進而採用合適的變更管控方法。積極地控制專案中所產生的變更，而不是被變更所控制。
一、為什麼要變更需求
大型IT專案需求變更的表現形式是多方面的，比如：專案預算增加或減少、高層領導臨時改變決策、增加或者減少功能、行業政策的變化等。企業為什麼要變更需求，原因是什麼？
1、範圍沒有圈定就急於細化 需求細化是根據客戶提出的描述性的、總結性的語言去細化的，提取其中的功能，並給出細化的描述。當細化到一定程度後並開始系統設計時，範圍可能會發生變化，那細節用例的描述可能就有很多要改動。如原來需求文件是整體匯入匯出，要改為指定範圍和內容匯入匯出，如原來需求是多元交叉受理，要改為集中受理、統一需求入口和出口等。
2、沒有指定需求的基線 需求的基線是指是否容許需求變更的分界線。隨著專案的進展，需求的基線也在變化。是否容許變更的依據是合同以及對成本的影響，比如軟體整體結構已經設計出來是不容許改變需求範圍的，因為整體結構會對整個專案的進度和成本有初步預算。專案進展越深入，基線將越定越高，容許的變更將越少。
3、沒有良好的軟體結構適應變化 元件式的軟體結構就是提供了快速適應需求變化的體系結構，資料層封裝了資料訪間邏輯，業務層封裝了業務邏輯，表示層展現使用者表示邏輯。但適應變化必須遵循松耦合原則，各層之間還是存在一些聯絡的，設計要力求減少會對介面入口引數產生變化。如果業務邏輯封裝好了，則表示層介面上的一些排列或減少資訊的要求是很容易適應的。如果介面定義得合理，那麼即使業務流程有變化，也能夠快速適應變化。因此，在成本影響的容許範圍內可以降低需求的基線，提高客戶的滿意度。
二、需求變更管理的實施準則
大型IT專案需求變更時，如果開發團隊缺少明確的需求變更控制過程或採用的變更控制機制無效，抑或不按變更控制流程來管理需求變更，那麼，很可能造成專案進度拖延、成本不足、人力緊缺，甚至導致整個專案失敗。
當然，即使按照需求變更控制流程進行管理，由於受進度、成本等因素的制約，軟體質量還是會受到不同程度的影響。但實施嚴格的軟體需求管理會最大限度地控制需求變更給軟體質量造成的負面影響，具體實施準則如下：
1、建立需求基線，需求基線是需求變更的依據。在開發過程中，需求確定並經過評審後(使用者參與評審)，可以建立第一個需求基線。此後每次變更並經過評審後，都要重新確定新的需求基線。
2、制訂簡單、有效的變更控制流程，並形成文件。在建立了需求基線後提出的所有變更都必須遵循這個控制流程。同時，這個流程具有一定的普遍性，對以後的專案開發和其他專案都有借鑑作用。
3、成立專案變更控制委員會(CCB)或相關職能的類似組織，負責裁定接受變更。CCB由專案所涉及的多方人員共同組成，包括行方和開發方的決策人員在內。
4、需求變更一定要先申請然後再評估，最後經過與變更大小相當級別的評審確認。
5、需求變更後，受影響的軟體計劃、產品、活動都要進行相應的變更，以保持和更新的需求一致。
6、妥善儲存變更產生的相關文件。
三、需求變更的有效管理
需求變更對大型IT開發專案成敗有重要影響，既不能一概拒絕客戶的變更要求，也不能一味地遷就客戶，所以，實施需求變更之前必須做好控制。需求變更控制的目的不是控制變更的發生，而是對變更進行管理，確保變更有序進行。
1、明確合同約束，建立需求基線
對於大型IT開發專案，變更都無可避免，也無從逃避，只能積極應對，這個應對應該是從專案啟動的需求分析階段就開始了。對一個需求分析做得很好的專案來說，基準檔案定義的範圍越詳細清晰，客戶跟專案經理扯皮的幌子就越少。如果需求沒做好，基準檔案裡的範圍含糊不清，被客戶抓住空子，往往要付出許多無謂的犧牲。如果需求做得好，文件清晰且又有客戶簽字，那麼後期客戶提出的變更就超出了合同範圍，需要另外收費。這個時候千萬不能手軟，不能讓客戶養成頻繁變更的習慣。
在開發過程中，需求確定並經過評審後（客戶參與評審），建立第一個需求基線。此後每次變更並經過評審後，都要重新確定新的需求基線，做到小需求可以變更，但大方向要保證不頻繁變更。
2、建立變更審批流程
成功專案和失敗專案的區別就在於專案的整個過程是否是可控的。專案經理應該樹立一個理念——需求變更是必然的、可控的、有益的。控制需求漸變需要注意以下幾點：
確認客戶是否接受變更的代價 要讓客戶認識到變更都是有代價的，要和客戶一起判斷需求變更是否依然進行。例如，變更是沒有問題的，但是要明確客戶能否接受由此引起的如進度延遲、費用增加、效率下降等問題。一般來說，如果客戶認為該變更是必須的（不是其上級領導拍腦袋提出的）就會接受這些後果。透過與客戶協商，這樣開發團隊即使沒有回報，也不會招致公司和客戶雙方的埋怨。如果客戶認為該變更雖然有必要但是可以暫緩，雙方簽署備忘錄後留待以後解決。如果客戶認為該變更可有可無，多數情況下會取消變更。這樣即可防止頻繁變更，也讓客戶認識到不是所有的需求都需要變更。
需求變更，不管大小都需要經過正規的需求管理流程，否則會積少成多。在實際大型IT專案執行中，專案經理往往不願意為小的需求變更去執行正規的需求管理過程，認為降低了開發效率，浪費了時間。但正是由於這種觀念才使需求逐漸變的不可控，最終導致專案失敗。3、用迭代方式應對需求頻繁修訂
大型IT專案開發過程中，建議採用迭代開發方式，每個階段的產品進行版本規劃，這樣在第一版本交付過程中，質量較好可以使客戶保持對專案成功的信心，這樣也可以使客戶需求更加明確和完善產品，客戶最關住的是研發過程中與實際後續版本提供系統構架和新技術領域的探索，在後續版本過程中不斷的對運營過程中分期完善，對系統的缺陷加以修訂，這樣才能保障軟體生命週期的延續。
四、需求管理工具體現的價值
Visual RM是一款基於大型IT專案管理特點的需求內容級管理工具，以大型IT專案管理視角，幫助IT專案實現需求“管得住、控得了、可跟蹤、可沉澱、可複用”的核心目標，其價值主要體現在以下方面：
1、由文件級轉為內容級需求管控，助力IT過程的精益管理：改變傳統的需求文件級管理過粗的方式，透過需求結構化、條目化技術，自動對需求文件進行自動化拆解，形成需求條目，將需求管理與跟蹤的顆粒度細化到條目級，使得需求內容切分（應用分配）、需求內容質量管控、開發和測試任務的需求分配、投產內容的需求跟蹤成為可能。
2、控好需求內容變更，維護好最新需求：Visual RM實現了需求文件級、條目級的需求基線管理，透過需求內容的變更控制手段，如：多人同時線上編制需求、變更需求、變更痕跡及歷史管理、變更內容前後比對、需求變更影響分析和自動通知受影響的相關人員，使需求變更過程方便、快捷，且變更過程透明、可回溯。
4、推動開發過程的需求協同，避免開發測試返工：需求傳遞由文件級過渡到需求內容級，使需求內容（全部或區域性）和需求變更都能快速傳遞到專案管理、開發、測試和投產過程的各環節對應的任務，使專案組所有成員都在同一份需求內容基礎上開展工作，形成以需求為主線的開發聯動，自動構建起從業務需求->專案->切分系統->軟體需求->開發->測試-投產版本的跟蹤脈絡，使需求的提出到落地實現過程變得透明。
5、需求資產沉澱，形成企業級的需求統一檢視：Visual RM可以幫助客戶按各類管理視角或框架（如：業務框架、應用系統框架、產品框架、組織框架）組織需求資產，透過從各專案需求文件中抽取需求資產，並按管理框架歸集和維護需求資產，確保可以從某一管理視角（如：某一系統、業務領域、產品型別等）獲取當前最新、最全的需求，以反映當前系統（或業務領域）的最新的需求全貌。
6、需求資產複用，快速編制需求：透過需求資產，需求分析人員在分析、編制需求時可以快速參考、引用需求資產內容，快速構建並形成新的需求；同時Visual RM可以支援多人協作並行編制需求，加速需求形成過程。