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