變化并不是人們最害怕的，最怕的是跟不上變化的步伐。同樣，在軟件研發(fā)過程中需求的變更會給研發(fā)帶來不確定性，但只要把需求變更作為重點、難點小心加以控制，軟件研發(fā)的進度、成本和質量也就有了"安全"的基礎。
　　需求變更管理的需求
　　需求變更是因為需求發(fā)生變化。根據軟件工程思想，需求說明書一般要經過論證，如果在需求說明書經過論證以后，需要在原有需求基礎上追加和補充新的需求或對原有需求進行修改和削減，均屬于需求變更。
　　需求變更的出現主要是因為在項目的需求確定階段，用戶往往不能確切地定義自己需要什么。用戶常常以為自己清晰，但實際上他們提出的需求只是依據當前的工作所需，而采用的新設備、新技術通常會改動他們的工作方式;或要研發(fā)的系統(tǒng)對用戶來說也是個未知數，他們以前沒有過相關的使用經驗。隨著研發(fā)工作的不斷進展，系統(tǒng)開始展現功能的雛形，用戶對系統(tǒng)的了解也逐步深入。于是，他們可能會想到各種新的功能和特色，或對以前提出的需求進行改動。他們了解得越多，新的需求也就越多，需求變更因此不可避免地一次又一次出現。
　　這時，如果研發(fā)團隊缺少明確的需求變更控制過程或采用的變更控制機制無效，抑或不按變更控制流程來管理需求變更，那么非?？赡茉斐身椖窟M度拖延、成本不足、人力緊缺，甚至導致整個項目失敗。當然，即使按照需求變更控制流程進行管理，由于受進度、成本等因素的制約，軟件質量還是會受到不同程度的影響。但實施嚴格的軟件需求管理會最大限度地控制需求變更給軟件質量造成的負面影響，這也正是我們進行需求變更管理的目的所在。
　　六大原則
　　實施需求變更管理需要遵循如下原則：
　　1.建立需求基線。需求基線是需求變更的依據。在研發(fā)過程中，需求確定并經過評審后(用戶參和評審)，能建立第一個需求基線。此后每次變更并經過評審后，都要重新確定新的需求基線。
　　2.制訂簡單、有效的變更控制流程，并形成文件。在建立了需求基線后提出的所有變更都必須遵循這個控制流程進行控制。同時，這個流程具有一定的普遍性，對以后的項目研發(fā)和其他項目都有借鑒作用。
　　3.成立項目變更控制委員會(CCB)或相關職能的類似組織，負責裁定接受哪些變更。CCB由項目所涉及的多方人員一起組成，應該包括用戶方和研發(fā)方的決策人員在內。
　　4.需求變更一定要先申請然后再評估，最后經過和變更大小相當級別的評審確認。
　　5.需求變更后，受影響的軟件計劃、產品、活動都要進行相應的變更，以保持和更新的需求一致。
　　6.妥善保存變更產生的相關文件?！　獙χ?
　　需求變更控制一般要經過變更申請、變更評估、決策、回復這四大步驟。如果變更被接受，還要增加實施變更和驗證兩個步驟，有時還會有取消變更的步驟。變更控制流程如圖所示。針對變更控制流程，筆者在實際工作中總結出了軟件研發(fā)人員在需求變更管理實踐中的幾點對策：
相互協(xié)作　非常難想像遭到用戶抵制的項目能夠成功。在討論需求時，研發(fā)人員和用戶應該盡量采取相互理解、相互協(xié)作的態(tài)度，對能解決的問題盡量解決。即使用戶提出了在研發(fā)人員看來"過分"的需求，也應該仔細分析原因，積極提出可行的替代方案。
　　充分交流　需求變更管理的過程非常大程度上就是用戶和研發(fā)人員的交流過程。軟件研發(fā)人員必須學會認真聽取用戶的需求、考慮和設想，并加以分析和整理。同時，軟件研發(fā)人員應該向用戶說明，進入設計階段以后，再提出需求變更會給整個研發(fā)工作帶來什么樣的沖擊和不良后果。
　　安排專職人員負責需求變更管理　有時研發(fā)任務較重，研發(fā)人員容易陷入研發(fā)工作中而忽略了和用戶的隨時溝通，因此需要一名專職的需求變更管理人員負責和用戶及時交流。
　　合同約束　需求變更給軟件研發(fā)帶來的影響有目共睹，所以在和用戶簽訂合同時，能增加一些相關條款，如限定用戶提出需求變更的時間，規(guī)定何種情況的變更能接受、拒絕接受或部分接受，還能規(guī)定發(fā)生需求變更時必須執(zhí)行變更控制流程。
　　差別對待　隨著研發(fā)進展，有些用戶會不斷提出一些在項目組看來確實無法實現或工作量比較大、對項目進度有重大影響的需求。遇見這種情況，研發(fā)人員能向用戶說明，項目的啟動是以最初的基本需求作為研發(fā)前提的，如果大量增加新的需求(雖然用戶認為是細化需求，但實際上是增加了工作量的新需求)，會使項目不能按時完成。如果用戶堅持實施新需求，能建議用戶將新需求按重要和緊迫程度劃分檔次，作為需求變更評估的一項依據。同時，還要注意控制新需求提出的頻率。
　　選用適當的研發(fā)模型　采用建立原型的研發(fā)模型比較適合需求不明確的研發(fā)項目。研發(fā)人員先根據用戶對需求的說明建立一個系統(tǒng)原型，再和用戶溝通。一般用戶看到一些實際的東西后，對需求會有更為周詳的解釋，研發(fā)人員可根據用戶的說明進一步完善系統(tǒng)原型。這個過程重復幾次后，系統(tǒng)原型逐漸向最終的用戶需求靠攏，從根本上減少需求變更的出現。目前業(yè)界較為流行的疊代式研發(fā)方法對工期緊迫的項目的需求變更控制非常有成效。 
　　用戶參和需求評審　作為需求的提出者，用戶理所當然是最具權威的發(fā)言人之一。實際上，在需求評審過程中，用戶往往能提出許多有價值的意見。同時，這也是由用戶對需求進行最后確認的機會，能有效減少需求變更的發(fā)生。