事實上，項目總結工作應作為現有項目或將來項目持續(xù)改進工作的一項重要內容，同時也可以作為對項目合同、設計方案內容與目標的確認和驗證。項目總結工作包括項目中事先識別的風險和沒有預料到而發(fā)生的變更等風險的應對措施的分析和總結，也包括項目中發(fā)生的變更和項目中發(fā)生問題的分析統計的總結。
一、需求變更的管理
需求變更是因為需求發(fā)生變化。根據軟件工程思想，需求說明書一般要經過論證，如果在需求說明書經過論證以后，需要在原有需求基礎上追加和補充新的需求或對原有需求進行修改和削減，均屬于需求變更。需求變更的出現主要是因為在項目的需求確定階段，用戶往往不能確切地定義自己需要什么。
用戶常常以為自己清楚，但實際上他們提出的需求只是依據當前的工作所需，而采用的新設備、新技術通常會改變他們的工作方式;或者要開發(fā)的系統對用戶來說也是個未知數，他們以前沒有過相關的使用經驗。隨著開發(fā)工作的不斷進展，系統開始展現功能的雛形，用戶對系統的了解也逐步深入。于是，他們可能會想到各種新的功能和特色，或對以前提出的要求進行改動。他們了解得越多，新的要求也就越多，需求變更因此不可避免地一次又一次出現。
這時，如果開發(fā)團隊缺少明確的需求變更控制過程或采用的變更控制機制無效，抑或不按變更控制流程來管理需求變更，那么很可能造成項目進度拖延、成本不足、人力緊缺，甚至導致整個項目失敗。當然，即使按照需求變更控制流程進行管理，由于受進度、成本等因素的制約，軟件質量還是會受到不同程度的影響。但實施嚴格的軟件需求管理會最大限度地控制需求變更給軟件質量造成的負面影響，這也正是我們進行需求變更管理的目的所在。
實施需求變更管理需要遵循以下六大原則
?。?）建立需求基線
需求基線是需求變更的依據。在開發(fā)過程中，需求確定并經過評審后（用戶參與評審），可以建立第一個需求基線。此后每次變更并經過評審后，都要重新確定新的需求基線。
（2）制訂簡單、有效的變更控制流程，并形成文檔
在建立了需求基線后提出的所有變更都必須遵循這個控制流程進行控制。同時，這個流程具有一定的普遍性，對以后的項目開發(fā)和其他項目都有借鑒作用。
?。?）成立項目變更控制委員會（CCB）或相關職能的類似組織，負責裁定接受哪些變更。CCB由項目所涉及的多方人員共同組成，應該包括用戶方和開發(fā)方的決策人員在內。
?。?）需求變更一定要先申請然后再評估，最后經過與變更大小相當級別的評審確認。
?。?）需求變更后，受影響的軟件計劃、產品、活動都要進行相應的變更，以保持和更新的需求一致。
（6）妥善保存變更產生的相關文檔。
二、應對之道
需求變更控制一般要經過變更申請、變更評估、決策、回復這四大步驟。如果變更被接受，還要增加實施變更和驗證兩個步驟，有時還會有取消變更的步驟。針對變更控制流程，在實際工作中總結出了軟件開發(fā)人員在需求變更管理實踐中的幾點對策：
1、優(yōu)先排序，分批實現
每個需求的重要性是不同的。由于資源或技術條件的限制，會顯得“僧多粥少”，因此不可能把所有的需求一次完成。怎么辦？把每個需求按照對效益的貢獻打個分，排出個優(yōu)先級來，優(yōu)先級高的需求先實現，低的到一下版式本實現。
由于不斷有新的需求進來，有的需求可能永遠沒有機會被子實現，但不緊，還是要記錄下來，并一起參加排序，保證在每個版本發(fā)布時重要的需求先得到滿足。每個需求的實現是需要花時