軟件項目在執行過程的變更，特別是需求的變更是難把握的，它也是影響到整個項目成敗的關鍵因素。
一、計算機系統集成軟件開發項目需求變更產生的原因
對于軟件項目的需求而言，產生變更的原因集中在下面幾個方面:
1.用戶對系統功能理解的分歧。在進行用戶需求調查分析時，分析人員的知識、背景、與用戶的交流情況等因素會造成系統分析人員和用戶在功能理解上的分歧，隨著項目的進行，這種分歧肯定會帶來變更。
2.用戶業務邏輯發生了變化。用戶自身的業務邏輯不太明確，特別是處于激烈競爭情況下的用戶肯定要隨著市場情況的變化，隨時調整自己的運作來適應這種變化，這肯定會對相關的軟件產品提出更多的變更要求。
3.用戶在試用過程中提出的變更。當用戶拿到測試版本可以進行實際操作時，用戶一般都會對功能、性能、界面、操作方式等提出新的意見，這時變更產生了。
4.技術的升級。技術的升級分為兩個方面，一方面是隨著信息化技術的迅速發展，原項目中使用的技術可能變成過時技術，需要對原技術進行升級;另一個方面是開發方自身對軟件版本升級、性能改進、設計修正時產生的變更。從上面可以看出，指望軟件項目需求能從始至終一成不變是不可能的。
二、計算機系統集成軟件開發項目需求變更的影響及管理原則
1.設定項目需求基線。需求基線是需求變更的參照標準，每次的變更均應在需求基線的基礎上進行。每次變更評審通過后要重新確定需求基線，使其符合需求變更后的狀況。
2.嚴格執行需求變更流程，并記錄在變更過程中產生的所有文檔。
3.成立項目變更控制委員會(CCB)，負責對項目變更進行評估，裁定哪些變更需要執行，哪些變更應該放棄。變更控制委員會的成員應由項目所涉及到的多方面人同組成，應該包括用戶方和開發方的決策人員在內。
4.需求變更后，受影響的相關軟件計劃、產品、活動都要進行相應的變更，以保持和更新的需求一致。
三、計算機系統集成軟件開發項目需求變更的流程
在軟件項目需求變更時，一般采用下面的流程進行控制:
1.申請變更。當項目開發組確認將要產生需求變更時，用標準的變更申請表格將用戶的每一次變更申請記錄存檔。
2.變更評估。項目開發組收到用戶提交的需求變更申請后，應對該變更所帶來的影響進行評估。它包括項目的人力、物力、資金、管理、時間、質量、工作負荷等內部因素，以及外部因素如資本、用戶要求的完工時間、項目負債情況等各個方面的影響。對于一個變更的申請，可能會有以下幾個可能的評估結果:(1)在現有資源和時間范圍允許的情況下可以采納該變更。(2)可以采納，但要延長交付時間。(3)在現有的可交付時間內可以采納，但需要額外的資源支持。(4)可以采納，但需要額外的資源和延長交付時間。(5)可以采納，但需要采取多次發布策略，并排定不同發布時期交付成果的優先次序。這種情況的發生非常頻繁，項目經理需要權衡將一些重要的工作提前完成，而有一些不重要的工作延遲完成。(6)不能采納。
3.變更的實施。一旦確定變更后，下一步是分析和選擇可行的實施方案。項目的目標、預算、團隊以及項目的進度是決定項目成功實施的主要因素。在需求變更時，力求在盡可能小的變動幅度內對這些主要的因素進行微調。為了將項目變更的影響降低到小，一定要認真執行變更的控制流程，減小項目風險。
四、實際項目分析
以某學院的信息管理系統軟件開發項目為例。該系統包括了學籍管理、排課管理、學生選課、教材管理、學生考勤管理、教學質量管理、考試管理、成績管理、宿舍管理、財務管理、證明管理、招生管理等子系統。在開發過程中，我們對需求變更進行了較嚴格的管理，產品得以按時保質地上線。在該管理信息系統的開發過程中，變更的因素有以下幾個:1.由于項目啟動時間距離第一個版本的上線時間很近，不可能在短時間內將所有的需求都獲取到。2.開發人員有時會對用戶的描述理解不正確，或遺漏某些要求，所以要對已有的需求進行修改。3.用戶在項目開始的時候，大都不是很了解自己到底需要什么，等他們使用一段時間管理系統后，會在實際使用中不斷發現這樣那樣的需求。4.主要的因素，是該學院成立時間不長，且不是采用國內常規的管理方法，而要使這些管理方法適合國內的高校管理體制，需要有一段磨合期，所以學院內部的管理經常變，導致系統的相應需求也必須變。變更控制委員會由主管這套系統開發的副院長、項目經理以及配置管理員三個人組成。根據開發的實際情況，我們制定了一套變更管理程序，是所有變更都必須以變更申請書的形式提交給變更控制委員會，變更控制委員會評估后，出具變更報告，然后才交給相關人員做相應處理，之后，由測試人員對變更后的相關用例進行測試跟蹤。一個需求變更申請提交后，變更控制委員會對其進行評估，如確認進行變更，則由我方項目經理出具一份變更報告，寫明變更事由、提出方、提出時間、變更評估結果。配置管理員將這份變更報告加到配置管理庫中存檔，并分發給變更申請人以及相關系統分析員。系統分析員對之進行分析，提交出一份變更列表，將該變更所影響到的文檔、程序都詳細的列出來，上交給配置管理員進行存檔。然后，系統分析員對列表的中所列出來的文檔逐個進行修改，再交由編程人員進行相應的代碼修改，然后提交測試員測試，出具測試報告。這些修改的文檔、代碼以及測試報告都要提交給配置管理員進行存檔管理，配置管理員還要根據提交情況對變更列表進行相應維護，如某項修改完成了，要在它后面打上完結標記。當該變更列表中的所有變更項都完結了，配置管理員在變更報告后要加上實際完成時間。這樣，變更所導致的文檔、程序變化可以在一個可以追溯、可以控制的狀態下進行了。減少了遺漏的可能性，并便于變更的追蹤。由于采取了上述變更控制方法，即使該項目的變更比較多，但還是能保持開發工作正常有序地進行。
五、結束語
對于軟件開發的過程中不可避免的會出現需求變更，并且這些變更會發生在項目的整個生命周期里，因此變更控制顯得尤其重要，變更控制的管理好壞對項目成敗有重要影響。
