需求變更管理的應(yīng)對(duì)六大原則【精選文檔】

1、需求變更管理的應(yīng)對(duì)六大原則【精選文檔】需求變更是因?yàn)樾枨蟀l(fā)生變化。根據(jù)軟件工程思想，需求說(shuō)明書(shū)一般要經(jīng)過(guò)論證,如果在需求說(shuō)明書(shū)經(jīng)過(guò)論證以后，需要在原有需求基礎(chǔ)上追加和補(bǔ)充新的需求或?qū)υ行枨筮M(jìn)行修改和削減，均屬于需求變更.需求變更的出現(xiàn)主要是因?yàn)樵陧?xiàng)目的需求確定階段，用戶往往不能確切地定義自己需要什么。用戶常常以為自己清楚,但實(shí)際上他們提出的需求只是依據(jù)當(dāng)前的工作所需，而采用的新設(shè)備、新技術(shù)通常會(huì)改變他們的工作方式；或者要開(kāi)發(fā)的系統(tǒng)對(duì)用戶來(lái)說(shuō)也是個(gè)未知數(shù),他們以前沒(méi)有過(guò)相關(guān)的使用經(jīng)驗(yàn)。隨著開(kāi)發(fā)工作的不斷進(jìn)展,系統(tǒng)開(kāi)始展現(xiàn)功能的雛形，用戶對(duì)系統(tǒng)的了解也逐步深入。于是,他們可能會(huì)想到各種新的功能和

2、特色，或?qū)σ郧疤岢龅囊筮M(jìn)行改動(dòng)。他們了解得越多，新的要求也就越多，需求變更因此不可避免地一次又一次出現(xiàn)。這時(shí),如果開(kāi)發(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ù)。在開(kāi)發(fā)過(guò)程中，需求

3、確定并經(jīng)過(guò)評(píng)審后（用戶參與評(píng)審），可以建立第一個(gè)需求基線。此后每次變更并經(jīng)過(guò)評(píng)審后，都要重新確定新的需求基線。（2)制訂簡(jiǎn)單、有效的變更控制流程，并形成文檔。在建立了需求基線后提出的所有變更都必須遵循這個(gè)控制流程進(jìn)行控制.同時(shí)，這個(gè)流程具有一定的普遍性,對(duì)以后的項(xiàng)目開(kāi)發(fā)和其他項(xiàng)目都有借鑒作用。（3)成立項(xiàng)目變更控制委員會(huì)（CCB）或相關(guān)職能的類似組織,負(fù)責(zé)裁定接受哪些變更。CCB由項(xiàng)目所涉及的多方人員共同組成，應(yīng)該包括用戶方和開(kāi)發(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)的變更，以保持

4、和更新的需求一致。(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é)出了軟件開(kāi)發(fā)人員在需求變更管理實(shí)踐中的幾點(diǎn)對(duì)策:優(yōu)先排序 分批實(shí)現(xiàn)每個(gè)需求的重要性是不同的。由于資源或技術(shù)條件的限制，會(huì)顯得“僧多粥少”，因此不可能把所有的需求一次完成。怎么辦?把每個(gè)需求按照對(duì)效益的貢獻(xiàn)打個(gè)分，排出個(gè)優(yōu)先級(jí)來(lái)，優(yōu)先級(jí)高的需求先實(shí)現(xiàn),低的到一下版式本實(shí)現(xiàn).由于不斷有新的需求進(jìn)來(lái)，有的需求可能永遠(yuǎn)沒(méi)有機(jī)會(huì)被子實(shí)現(xiàn),但不緊，還是要記錄下來(lái)，并一起參加排序

5、，保證在每個(gè)版本發(fā)布時(shí)重要的需求先得到滿足。每個(gè)需求的實(shí)現(xiàn)是需要花時(shí)間的，沒(méi)人有百分百的把握預(yù)估得很清楚，但借鑒過(guò)去的經(jīng)驗(yàn)可以大概估算出人力成本,然后根據(jù)開(kāi)發(fā)人員和開(kāi)發(fā)周期得出可用人力投入作為上限。從優(yōu)先級(jí)高的需求中挑，直到挑中的人力成本總和剛剛低于可用投入上限,這樣得出的就是需求的錄取榜。今后的軟件開(kāi)發(fā)規(guī)劃也會(huì)以此為依據(jù),分期分批地在不同的回合中實(shí)現(xiàn).最合理的不一定是優(yōu)先級(jí)最高的，也就是說(shuō)不一不定是最先考慮的，“經(jīng)濟(jì)為本”是指導(dǎo)優(yōu)先排序的最終原則。相互協(xié)作很難想像遭到用戶抵制的項(xiàng)目能夠成功.在討論需求時(shí),開(kāi)發(fā)人員與用戶應(yīng)該盡量采取相互理解、相互協(xié)作的態(tài)度，對(duì)能解決的問(wèn)題盡量解決。即使用戶提出

6、了在開(kāi)發(fā)人員看來(lái)"過(guò)分"的要求,也應(yīng)該仔細(xì)分析原因,積極提出可行的替代方案。充分交流需求變更管理的過(guò)程很大程度上就是用戶與開(kāi)發(fā)人員的交流過(guò)程。軟件開(kāi)發(fā)人員必須學(xué)會(huì)認(rèn)真聽(tīng)取用戶的要求、考慮和設(shè)想，并加以分析和整理。同時(shí)，軟件開(kāi)發(fā)人員應(yīng)該向用戶說(shuō)明，進(jìn)入設(shè)計(jì)階段以后，再提出需求變更會(huì)給整個(gè)開(kāi)發(fā)工作帶來(lái)什么樣的沖擊和不良后果.安排專職人員負(fù)責(zé)需求變更管理有時(shí)開(kāi)發(fā)任務(wù)較重，開(kāi)發(fā)人員容易陷入開(kāi)發(fā)工作中而忽略了與用戶的隨時(shí)溝通，因此需要一名專職的需求變更管理人員負(fù)責(zé)與用戶及時(shí)交流。合同約束需求變更給軟件開(kāi)發(fā)帶來(lái)的影響有目共睹,所以在與用戶簽訂合同時(shí)，可以增加一些相關(guān)條款，如限定用戶提出

7、需求變更的時(shí)間，規(guī)定何種情況的變更可以接受、拒絕接受或部分接受，還可以規(guī)定發(fā)生需求變更時(shí)必須執(zhí)行變更控制流程。區(qū)別對(duì)待隨著開(kāi)發(fā)進(jìn)展,有些用戶會(huì)不斷提出一些在項(xiàng)目組看來(lái)確實(shí)無(wú)法實(shí)現(xiàn)或工作量比較大、對(duì)項(xiàng)目進(jìn)度有重大影響的需求。遇到這種情況，開(kāi)發(fā)人員可以向用戶說(shuō)明，項(xiàng)目的啟動(dòng)是以最初的基本需求作為開(kāi)發(fā)前提的，如果大量增加新的需求(雖然用戶認(rèn)為是細(xì)化需求，但實(shí)際上是增加了工作量的新需求)，會(huì)使項(xiàng)目不能按時(shí)完成.如果用戶堅(jiān)持實(shí)施新需求,可以建議用戶將新需求按重要和緊迫程度劃分檔次,作為需求變更評(píng)估的一項(xiàng)依據(jù)。同時(shí)，還要注意控制新需求提出的頻率。選用適當(dāng)?shù)拈_(kāi)發(fā)模型采用建立原型的開(kāi)發(fā)模型比較適合需求不明確的

8、開(kāi)發(fā)項(xiàng)目。開(kāi)發(fā)人員先根據(jù)用戶對(duì)需求的說(shuō)明建立一個(gè)系統(tǒng)原型，再與用戶溝通。一般用戶看到一些實(shí)際的東西后，對(duì)需求會(huì)有更為詳細(xì)的解釋,開(kāi)發(fā)人員可根據(jù)用戶的說(shuō)明進(jìn)一步完善系統(tǒng)原型.這個(gè)過(guò)程重復(fù)幾次后，系統(tǒng)原型逐漸向最終的用戶需求靠攏,從根本上減少需求變更的出現(xiàn).目前業(yè)界較為流行的疊代式開(kāi)發(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ā)生。變更控制流程如圖所示.需求變更的代價(jià)一般來(lái)講，需求的變更通常意味著需求的增

9、加，需求的減少相對(duì)很少，而且處理需求減少方面的問(wèn)題也比較容易。當(dāng)客戶提出新需求的時(shí)候,項(xiàng)目開(kāi)發(fā)人員應(yīng)該分析這些新需求對(duì)項(xiàng)目現(xiàn)階段帶來(lái)的風(fēng)險(xiǎn)，得出雙方實(shí)現(xiàn)變更需求的需要的成本，包括時(shí)間、人力、資源等等方面。變更都是有代價(jià)的,應(yīng)該評(píng)估一下變更的代價(jià)和對(duì)項(xiàng)目的影響,在評(píng)估代價(jià)并且與客戶討論的過(guò)程中，要讓客戶了解變更的后果,變更之后面臨最大的問(wèn)題就是項(xiàng)目延期，讓客戶一起做判斷：“我可以修改，但您能接受后果嗎？”?，F(xiàn)在會(huì)出現(xiàn)三種可能：客戶接受延期這一后果，開(kāi)發(fā)人員按客戶要求做出相應(yīng)修改，讓客戶知道為此需要付出延期的代價(jià)；如果客戶認(rèn)為代價(jià)太大，那開(kāi)發(fā)人員就不必修改了，可以記錄下需求，待到下一版本再做修改;

10、客戶不接受變更的代價(jià),導(dǎo)致項(xiàng)目夭折. 如果客戶不知道你為變更付出的代價(jià)，對(duì)你的辛苦便難以體會(huì)，以致沒(méi)完沒(méi)了的提出新的變更。減少需求變更正如前文所說(shuō)，需求變更往往是不可避免的。通常是項(xiàng)目負(fù)責(zé)人員花費(fèi)了大量的氣力避免需求變更，可最后需求變更總是會(huì)出現(xiàn)。但是這并不意味著項(xiàng)目開(kāi)發(fā)人員不應(yīng)該做這方面的工作，項(xiàng)目開(kāi)發(fā)人員對(duì)于需求變更的正確態(tài)度應(yīng)該和軟件測(cè)試的態(tài)度一樣，在需求變更發(fā)生之前盡量減少需求變更，以將需求變更帶來(lái)的風(fēng)險(xiǎn)降低到最低。項(xiàng)目開(kāi)發(fā)人員切忌在項(xiàng)目設(shè)計(jì)之前試圖消除需求變更，這樣做往往費(fèi)力不討好.相比于需求開(kāi)發(fā)人員而言，客戶可能對(duì)需求變更認(rèn)識(shí)不足，認(rèn)為他們出錢(qián),程序員或軟件開(kāi)發(fā)公司就要為它服務(wù)，因

11、此客戶對(duì)需求變更往往更加肆無(wú)忌彈，將需求變更視為兒戲，隨個(gè)人喜好隨意變更需求。因此，在需求人員同用戶代表或用戶部門(mén)主管人員接觸時(shí)，就應(yīng)該向他們挑明態(tài)度，和他們協(xié)商好，特別是應(yīng)該讓他們清楚軟件的定價(jià)應(yīng)該與軟件的功能相關(guān),以及需求隨意變更所帶來(lái)的風(fēng)險(xiǎn)的承擔(dān)者應(yīng)該由客戶和項(xiàng)目開(kāi)發(fā)者共同承擔(dān).通過(guò)這樣做，讓客戶在需求分析之前就盡量對(duì)他們所需要的功能有個(gè)整體的了解和確定的思路，而不是等到程序員開(kāi)始編碼了，才提出以前原本在需求分析時(shí)就可以提出的需求.讓客戶明白減少需求變更的重要性后，需求分析人員應(yīng)該采取合適的方法同客戶交流,幫助他們明確他們的需求。需求分析人員和客戶的關(guān)系不應(yīng)該僅僅是記錄人員和需求提供者,他們的關(guān)系應(yīng)該更多的是戰(zhàn)略合作伙伴關(guān)系。雖然需求分析人員和客戶存在著服務(wù)商和顧客的關(guān)系，但是他們有著一個(gè)共同的目標(biāo)：開(kāi)發(fā)出適合客戶需求的軟件,因此需求分析人員除了記錄客戶提出的需求以外，還應(yīng)和用戶討論，提出一些建議，使用合適的工具幫助客戶提出需求.在需求分析時(shí),盡量多的召集需求研討會(huì),邀請(qǐng)開(kāi)發(fā)人員和客戶共同協(xié)商探討,在研討會(huì)上允許任意的提出需求，并將