我們將圍繞著“需求變更”這個(gè)主題展開(kāi)討論，希望對(duì)各位開(kāi)發(fā)能有所幫助。讓我們先來(lái)看一個(gè)需求變更的典型案例：
 
　　Steven剛出任項(xiàng)目經(jīng)理，并承接了一個(gè)中型軟件項(xiàng)目。公司再三叮嚀他一定要尊重客戶，充分滿足客戶需求。項(xiàng)目開(kāi)始比較順利，但進(jìn)入到后期，客戶頻繁的需求變更帶來(lái)很多額外工作。Steven動(dòng)員大家加班，保持了項(xiàng)目的正常進(jìn)度，客戶相當(dāng)滿意。

　　但需求變更卻越來(lái)越多。為了節(jié)省時(shí)間，客戶的業(yè)務(wù)人員不再向Steven申請(qǐng)變更，而是直接找程序員商量。程序員疲于應(yīng)付，往往直接改程序而不做任何記錄，很多相關(guān)文檔也忘記修改。很快Steven就發(fā)現(xiàn)：需求、設(shè)計(jì)和代碼無(wú)法保持一致，甚至沒(méi)有人能說(shuō)清楚現(xiàn)在系統(tǒng)“到底改成什么樣了”。版本管理也出現(xiàn)了混亂，很多人違反配置管理規(guī)定，直接在測(cè)試環(huán)境中修改和編譯程序。但在進(jìn)度壓力下，他也只能佯裝不知此事。但因頻繁出現(xiàn)“改好的錯(cuò)誤又重新出現(xiàn)”的問(wèn)題，客戶已經(jīng)明確表示“失去了耐心”。

　　而這還只是噩夢(mèng)的開(kāi)始。一個(gè)程序員未經(jīng)許可擅自修改了核心模塊，造成系統(tǒng)運(yùn)行異常緩慢，大量應(yīng)用程序超時(shí)退出。雖然最終花費(fèi)了整整3天的時(shí)間解決了這個(gè)問(wèn)題，但客戶卻投訴了，表示“無(wú)法容忍這種低下的項(xiàng)目管理水平”。更糟糕的是，因?yàn)閾?dān)心系統(tǒng)中還隱含著其他類(lèi)似的錯(cuò)誤，客戶高層對(duì)項(xiàng)目的質(zhì)量也疑慮重重。

　　隨后發(fā)生的事情讓Steven更加為難：客戶的兩個(gè)負(fù)責(zé)人對(duì)界面風(fēng)格的看法不一致，并為此發(fā)生了激烈爭(zhēng)執(zhí)。Steven知道如果發(fā)表意見(jiàn)可能會(huì)得罪其中一方，于是保持了沉默。最終客戶決定調(diào)整所有界面， Steven只好立刻動(dòng)員大家抓緊時(shí)間修改?？珊髞?lái)當(dāng)聽(tīng)說(shuō)因修改界面而造成了項(xiàng)目一周的延誤后，客戶方原來(lái)發(fā)生爭(zhēng)執(zhí)的兩人這次卻非常一致，同時(shí)氣憤地質(zhì)問(wèn)Steven：“為什么你不早點(diǎn)告訴我們要延期！早知這樣才不會(huì)讓你改呢！”Steven很無(wú)耐，疑惑自己到底錯(cuò)在哪里了。

　　段落導(dǎo)航：
 
　　為了方便大家的閱讀，我們將本期內(nèi)容進(jìn)行了合理的分類(lèi)，您可以使用下面的鏈接瀏覽您感興趣的主題?！　?br /> 
　　對(duì)軟件需求和需求變更的理解
　　需求變更的原因
　　需求變更的代價(jià)
　　減少需求變更
　　如何控制需求變更
　　需求變更的管理
　　實(shí)施需求變更管理需要遵循以下六大原則
　　應(yīng)對(duì)之道
 
　　對(duì)軟件需求和需求變更的理解

　　軟件需求是整個(gè)軟件項(xiàng)目的最關(guān)鍵的一個(gè)輸入，和傳統(tǒng)的生產(chǎn)企業(yè)相比較，軟件的需求具有模糊性、不確定性、變化性和主觀性的特點(diǎn)，它不像生產(chǎn)汽車(chē)、電腦等硬件的需求，是有形的、客觀的、可描述的、可檢測(cè)的。軟件需求是軟件項(xiàng)目最難把握的問(wèn)題，同時(shí)又是關(guān)系項(xiàng)目成敗的關(guān)鍵因素，因此對(duì)于需求分析和需求變更的處理十分重要。
 

　　需求變更會(huì)給項(xiàng)目帶來(lái)巨大的風(fēng)險(xiǎn),會(huì)導(dǎo)致項(xiàng)目的成本費(fèi)用增加、開(kāi)發(fā)周期延長(zhǎng)、產(chǎn)品質(zhì)量下降及團(tuán)隊(duì)工作效率下降等不良后果，因而軟件開(kāi)發(fā)項(xiàng)目中應(yīng)該盡量減少需求變更的出現(xiàn)頻率。然而由于政府對(duì)特定軟件的相關(guān)要求、用戶部門(mén)市場(chǎng)戰(zhàn)略的調(diào)整、工業(yè)界的發(fā)展等因素都可能帶來(lái)需求的變更，而這些因素往往不可避免。在軟件開(kāi)發(fā)過(guò)程中如果只有一條真理的話，那一定是：需求的變化是永恒的，需求不可能是完備的。因而，對(duì)于需求變更應(yīng)該正確的對(duì)待，盡量將其負(fù)面影響降低到最低。
 
　　需求變更的原因

　　需求包括業(yè)務(wù)需求、用戶需求和功能需求。業(yè)務(wù)需求（Business Requirement ）反映了組織機(jī)構(gòu)或客戶對(duì)系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，用戶需求（User Requirement ）描述了用戶使用產(chǎn)品必須完成的任務(wù)，功能需求（Functional Requirement ）定義了開(kāi)發(fā)人員必須實(shí)現(xiàn)的軟件功能。
 
　　會(huì)導(dǎo)致需求變更的原因會(huì)有很多，如老板臨時(shí)改變想法、項(xiàng)目預(yù)算增加或減少、客戶對(duì)功能的需求改變等。在IT項(xiàng)目中，變更可能來(lái)自方案服務(wù)商、客戶或產(chǎn)品供應(yīng)商等，也可能來(lái)源于項(xiàng)目組內(nèi)部。在軟件系統(tǒng)開(kāi)發(fā)過(guò)程中，有很多問(wèn)題都是由于在需求分析階段沒(méi)有正確地收集、編寫(xiě)、協(xié)商、修改產(chǎn)品真實(shí)需求而產(chǎn)生的，造成這樣的狀況有以下幾方面的基本原因:
 

　　（1）對(duì)需求的理解分歧

　　當(dāng)客戶向需求分析人員提出需求的時(shí)候往往是通過(guò)自己的想法用自然語(yǔ)言來(lái)表達(dá)的，這樣的表達(dá)結(jié)果對(duì)于真實(shí)的需求來(lái)說(shuō)是一種描述（甚至只是某個(gè)角度的描述），遠(yuǎn)遠(yuǎn)不能保證這樣的描述可以得到百分之百的正確理解，也許在同客戶交流的第一時(shí)刻就埋下了理解分歧的種子，打一個(gè)比方說(shuō)客戶說(shuō)我要的是大象，身子象一堵墻，耳朵象扇子，四條腿象四根柱子，尾巴象繩子，分析人員想，哦，墻、扇子、柱子、繩子這些我都知道，但是真的畫(huà)出來(lái)的時(shí)候客戶當(dāng)然會(huì)跳起來(lái)了！這是理解分歧的問(wèn)題，一般跟分析員的知識(shí)、背景，還有客戶表述的標(biāo)準(zhǔn)程度、雙方的交流情況有關(guān)。
 
　?。?）系統(tǒng)實(shí)施時(shí)間過(guò)長(zhǎng)

　　一個(gè)大中型系統(tǒng)的建設(shè)可能要延續(xù)一段時(shí)間，當(dāng)客戶提出要求之后，他當(dāng)時(shí)并不能看到系統(tǒng)的運(yùn)行情況，當(dāng)雙方認(rèn)為理解大概沒(méi)有分歧的時(shí)候（事實(shí)上還會(huì)有個(gè)Deadline ），開(kāi)發(fā)方就開(kāi)始工作了。當(dāng)客戶拿到差不多可以試用的產(chǎn)品時(shí)他可以實(shí)際操作，這時(shí)候他就會(huì)對(duì)系統(tǒng)的界面、操作、功能、性能等有一些切身的體會(huì)，有可能提出需求變更要求。
 
　　（3）用戶業(yè)務(wù)需求改變

　　當(dāng)前客戶的運(yùn)營(yíng)情況不確定，有可能客戶行業(yè)的競(jìng)爭(zhēng)度高，需要隨時(shí)作出調(diào)整和反應(yīng)，那么他們自然會(huì)經(jīng)常提出需求變更的要求；也有可能客戶所在的行業(yè)操作不規(guī)范，本身存在很多人為因素，這時(shí)候開(kāi)發(fā)方更是需要隨時(shí)準(zhǔn)備應(yīng)變。
 
　?。?）系統(tǒng)正常升級(jí)

　　有可能是來(lái)自開(kāi)發(fā)方自身版本升級(jí)或性能改進(jìn)、設(shè)計(jì)修正的要求出現(xiàn)需求變更，這時(shí)更是無(wú)法繞開(kāi)這個(gè)問(wèn)題的了！
 
　　所以說(shuō)就算分析人員和客戶之間不存在理解分歧，客戶對(duì)于實(shí)際的系統(tǒng)還是會(huì)提出一些個(gè)人意見(jiàn)，就算沒(méi)有個(gè)人意見(jiàn)，他們自己的業(yè)務(wù)會(huì)變化或環(huán)境發(fā)生變化，這些都是無(wú)法避免的，所以不要夢(mèng)想那么理想的需求分析，當(dāng)你開(kāi)始一個(gè)項(xiàng)目的時(shí)候就應(yīng)該意識(shí)到，客戶需求變更一定會(huì)有的，那么對(duì)于這樣的現(xiàn)狀，我們?cè)撛趺崔k呢？客戶是上帝，難道我們就象以前一樣，跟著客戶的需求不停地修改軟件，到最后工期延長(zhǎng)，員工疲憊，成本成倍增長(zhǎng)，客戶滿意度降低，原來(lái)的設(shè)計(jì)也會(huì)改變得支離破碎，系統(tǒng)難以維護(hù)？
 
　　需求變更的代價(jià)

　　一般來(lái)講，需求的變更通常意味著需求的增加，需求的減少相對(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ā)人員就不必修改了，可以記錄下需求，待到下一版本再做修改；客戶不接受變更的代價(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ù)，因此客戶對(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ì)上允許任意的提出需求，并將這些需求整理成檔后由客戶代表和需求分析人員共同商議可選的功能，這樣能夠盡量使得需求完備。在需求開(kāi)發(fā)時(shí)，開(kāi)發(fā)人員采用原型的方法啟發(fā)客戶思考功能需求也不失為一個(gè)好辦法。
 

　　雖然需求不可能是完備的、變更不可能沒(méi)有的，但是在項(xiàng)目開(kāi)始設(shè)計(jì)時(shí)使得需求盡可能完備還是應(yīng)該的，也是值得的，完備需求的過(guò)程也就相應(yīng)的減少了因?yàn)樾枨蟛磺宄a(chǎn)生變更的幾率。
 
　　如何控制需求變更
 
　　按照現(xiàn)代項(xiàng)目管理的概念，一個(gè)項(xiàng)目的生命周期分為啟動(dòng)、實(shí)施、收尾三個(gè)過(guò)程。需求變更的控制不應(yīng)該只是項(xiàng)目實(shí)施過(guò)程考慮的事情，而是要分布在整個(gè)項(xiàng)目生命周期的全過(guò)程。為了將項(xiàng)目變更的影響降低到最小，就需要采用綜合變更控制方法。綜合變更控制主要內(nèi)容有找出影響項(xiàng)目變更的因素、判斷項(xiàng)目變更范圍是否已經(jīng)發(fā)生等。
 

　　進(jìn)行綜合變更控制的主要依據(jù)是項(xiàng)目計(jì)劃、變更請(qǐng)求提供了項(xiàng)目執(zhí)行狀況信息的績(jī)效報(bào)告。為保證項(xiàng)目變更的規(guī)范和有效實(shí)施，通常項(xiàng)目實(shí)施組織會(huì)有以下幾種措施：

　?。?）項(xiàng)目啟動(dòng)階段的變更預(yù)防
 
　　對(duì)于任何項(xiàng)目，變更都無(wú)可避免，也無(wú)從逃避，只能積極應(yīng)對(duì)，這個(gè)應(yīng)對(duì)應(yīng)該是從項(xiàng)目啟動(dòng)的需求分析階段就開(kāi)始了。對(duì)一個(gè)需求分析做得很好的項(xiàng)目來(lái)說(shuō)，基準(zhǔn)文件定義的范圍越詳細(xì)清晰，用戶跟項(xiàng)目經(jīng)理扯皮的幌子就越少。如果需求沒(méi)做好，基準(zhǔn)文件里的范圍含糊不清，被客戶抓住空子，往往要付出許多無(wú)謂的犧牲。如果需求做得好，文檔清晰且又有客戶簽字，那么后期客戶提出的變更就超出了合同范圍，需要另外收費(fèi)。這個(gè)時(shí)候千萬(wàn)不能手軟，這并非要刻意賺取客戶的錢(qián)財(cái)，而是不能讓客戶養(yǎng)成經(jīng)常變更的習(xí)慣，否則后患無(wú)窮。相對(duì)于需求來(lái)說(shuō)，什么WBS、風(fēng)險(xiǎn)管理、計(jì)劃進(jìn)度都是次要的，只要需求做好了就會(huì)一帆風(fēng)順。
 
　　（2）項(xiàng)目實(shí)施階段的需求變更
 
　　成功項(xiàng)目和失敗項(xiàng)目的區(qū)別就在于項(xiàng)目的整個(gè)過(guò)程是否是可控的。項(xiàng)目經(jīng)理應(yīng)該樹(shù)立一個(gè)理念——“需求變更是必然的、可控的、有益的”。項(xiàng)目實(shí)施階段的變更控制需要做的是分析變更請(qǐng)求，評(píng)估變更可能帶來(lái)的風(fēng)險(xiǎn)和修改基準(zhǔn)文件?？刂菩枨鬂u變需要注意以下幾點(diǎn)：
 
　　需求一定要與投入有聯(lián)系，如果需求變更的成本由開(kāi)發(fā)方來(lái)承擔(dān)，則項(xiàng)目需求的變更就成為必然了。所以，在項(xiàng)目的開(kāi)始，無(wú)論是開(kāi)發(fā)方還是出資方都要明確這一條：需求變，軟件開(kāi)發(fā)的投入也要變。
 
　　需求的變更要經(jīng)過(guò)出資者的認(rèn)可，這樣才會(huì)對(duì)需求的變更有成本的概念，能夠慎重地對(duì)待需求的變更。
 
　　小的需求變更也要經(jīng)過(guò)正規(guī)的需求管理流程，否則會(huì)積少成多。在實(shí)踐中，人們往往不愿意為小的需求變更去執(zhí)行正規(guī)的需求管理過(guò)程，認(rèn)為降低了開(kāi)發(fā)效率，浪費(fèi)了時(shí)間。但正是由于這種觀念才使需求逐漸變?yōu)椴豢煽?，最終導(dǎo)致項(xiàng)目的失敗。
 
　　精確的需求與范圍定義并不會(huì)阻止需求的變更。并非對(duì)需求定義得越細(xì)，就越能避免需求的漸變，這是兩個(gè)層面的問(wèn)題。太細(xì)的需求定義對(duì)需求漸變沒(méi)有任何效果。因?yàn)樾枨蟮淖兓怯篮愕?，并非需求?xiě)細(xì)了，它就不會(huì)變化了。
 
　　注意溝通的技巧。實(shí)際情況是用戶、開(kāi)發(fā)者都認(rèn)識(shí)到了上面的幾點(diǎn)問(wèn)題，但是由于需求的變更可能來(lái)自客戶方，也可能來(lái)自開(kāi)發(fā)方，因此，作為需求管理者，項(xiàng)目經(jīng)理需要采用各種溝通技巧來(lái)使項(xiàng)目的各方各得其所。
 
　　在開(kāi)發(fā)上盡量根據(jù)情況采用多次迭代的方式進(jìn)行項(xiàng)目的開(kāi)發(fā)，在每次迭代的同時(shí)讓客戶參與和使用軟件，對(duì)下一步的開(kāi)發(fā)做出建議爭(zhēng)取在項(xiàng)目前期有效的減少后期可能出現(xiàn)的變更情況。
 
　?。?）項(xiàng)目收尾階段的總結(jié)
 
　　能力的提高往往不是從成功的經(jīng)驗(yàn)中來(lái)，而是從失敗的教訓(xùn)中來(lái)。許多項(xiàng)目經(jīng)理不注重經(jīng)驗(yàn)教訓(xùn)總結(jié)和積累，即使在項(xiàng)目運(yùn)作過(guò)程中碰得頭破血流，也只是抱怨運(yùn)氣、環(huán)境和團(tuán)隊(duì)配合不好，很少系統(tǒng)地分析總結(jié)，或者不知道如何分析總結(jié)，以至于同樣的問(wèn)題反復(fù)出現(xiàn)。
 
　　事實(shí)上，項(xiàng)目總結(jié)工作應(yīng)作為現(xiàn)有項(xiàng)目或?qū)?lái)項(xiàng)目持續(xù)改進(jìn)工作的一項(xiàng)重要內(nèi)容，同時(shí)也可以作為對(duì)項(xiàng)目合同、設(shè)計(jì)方案內(nèi)容與目標(biāo)的確認(rèn)和驗(yàn)證。項(xiàng)目總結(jié)工作包括項(xiàng)目中事先識(shí)別的風(fēng)險(xiǎn)和沒(méi)有預(yù)料到而發(fā)生的變更等風(fēng)險(xiǎn)的應(yīng)對(duì)措施的分析和總結(jié)，也包括項(xiàng)目中發(fā)生的變更和項(xiàng)目中發(fā)生問(wèn)題的分析統(tǒng)計(jì)的總結(jié)。
 
　　需求變更的管理

　　需求變更是因?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ì)想到各種新的功能和特色，或?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í)施需求變更管理需要遵循以下六大原則

　?。?）建立需求基線，需求基線是需求變更的依據(jù)。在開(kāi)發(fā)過(guò)程中，需求確定并經(jīng)過(guò)評(píng)審后（用戶參與評(píng)審），可以建立第一個(gè)需求基線。此后每次變更并經(jīng)過(guò)評(píng)審后，都要重新確定新的需求基線。

　?。?）制訂簡(jiǎn)單、有效的變更控制流程，并形成文檔。在建立了需求基線后提出的所有變更都必須遵循這個(gè)控制流程進(jìn)行控制。同時(shí)，這個(gè)流程具有一定的普遍性，對(duì)以后的項(xiàng)目開(kāi)發(fā)和其他項(xiàng)目都有借鑒作用。

　?。?）成立項(xiàng)目變更控制委員會(huì)（CCB）或相關(guān)職能的類(lèi)似組織，負(fù)責(zé)裁定接受哪些變更。CCB由項(xiàng)目所涉及的多方人員共同組成，應(yīng)該包括用戶方和開(kāi)發(fā)方的決策人員在內(nèi)。

　?。?）需求變更一定要先申請(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é)出了軟件開(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)，并一起參加排序，保證在每個(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)題盡量解決。即使用戶提出了在開(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)什么樣的沖擊和不良后果。

　　安排專(zhuān)職人員負(fù)責(zé)需求變更管理　有時(shí)開(kāi)發(fā)任務(wù)較重，開(kāi)發(fā)人員容易陷入開(kāi)發(fā)工作中而忽略了與用戶的隨時(shí)溝通，因此需要一名專(zhuān)職的需求變更管理人員負(fù)責(zé)與用戶及時(shí)交流。

　　合同約束　需求變更給軟件開(kāi)發(fā)帶來(lái)的影響有目共睹，所以在與用戶簽訂合同時(shí)，可以增加一些相關(guān)條款，如限定用戶提出需求變更的時(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ā)模型比較適合需求不明確的開(kāi)發(fā)項(xiàng)目。開(kāi)發(fā)人員先根據(jù)用戶對(duì)需求的說(shuō)明建立一個(gè)系統(tǒng)原型，再與用戶溝通。一般用戶看到一些實(shí)際的東西后，對(duì)需求會(huì)有更為詳細(xì)的解釋?zhuān)_(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ā)生。