需求變更控制的流程和(如何有效控制需求變更)
1.如何有效控制需求變更
需求變更對軟件開發(fā)項(xiàng)目成敗有重要影響，既不能一概拒絕客戶的變更要求，也不能一味地遷就客戶，所以實(shí)施需求變更之前必須做好控制。
需求變更控制的目的不是控制變更的發(fā)生，而是對變更進(jìn)行管理，確保變更有序進(jìn)行。 （1）明確合同約束，建立需求基線 需求變更給軟件開發(fā)帶來的影響有目共睹，所以在與客戶簽訂合同時(shí)，可以增加一些相關(guān)條款，如限定客戶提出需求變更的時(shí)間，規(guī)定何種情況的變更可以接受、拒絕或部分接受，還可以規(guī)定發(fā)生需求變更時(shí)必須執(zhí)行變更管理流程。
雖然軟件開發(fā)合同很難在簽訂之初就能夠精確定義每項(xiàng)需求，單靠合同是幫不上忙的，但也不能忽視合同的約束力。 明確和樹立需求基線是需求變更的依據(jù)。
在開發(fā)過程中，需求確定并經(jīng)過評審后（客戶參與評審），建立第一個(gè)需求基線。此后每次變更并經(jīng)過評審后，都要重新確定新的需求基線，做到小需求可以變更，但大方向要力保不頻繁變更。
例如，對于項(xiàng)目中的需求，可以實(shí)行分級管理，以達(dá)到對需求變更的控制和管理。 （2）建立變更審批流程 在實(shí)踐中，人們往往不愿意為小的需求變更去執(zhí)行正規(guī)的需求管理過程，認(rèn)為降低開發(fā)效率，浪費(fèi)時(shí)間。
正是這種觀念才使需求變更變得不可控，最終導(dǎo)致項(xiàng)目的失敗。因此，小的需求變更也要經(jīng)過正規(guī)的需求管理流程，否則會(huì)積少成多，積重難返。
明確需求變更審批環(huán)節(jié)、審批人員、審批事項(xiàng)、審批流程。這么做的目的有兩個(gè)：一是將客戶下達(dá)變更的流程盡可能地規(guī)范化，減少張嘴就來的非必要、非緊急、非合理、非高層領(lǐng)導(dǎo)意圖的無效變更。
二是留下書面依據(jù)，為今后可能的成本變更和索賠準(zhǔn)備好“變更賬”。凡未履行審批程序的“變更”，一律是無效變更不予受理。
（3）分級管理變更，定時(shí)批量處理 軟件開發(fā)項(xiàng)目中，“客戶永遠(yuǎn)是對的”和“客戶是上帝”并不完全正確，因?yàn)樵谝呀?jīng)簽定的項(xiàng)目合同中，任何新需求的變更和增加除了影響項(xiàng)目的正常進(jìn)行以外，還影響到客戶的成本投入收益。因此，用戶不斷提出對項(xiàng)目進(jìn)度有重大影響的需求對雙贏也并不是好事。
當(dāng)遇到客戶提出需求，不及時(shí)處理可能會(huì)使項(xiàng)目不能驗(yàn)收通過時(shí)，也不能一味拒絕不予開發(fā)。因此，當(dāng)客戶堅(jiān)持變更新需求時(shí)，可以建議客戶將新需求按重要和緊迫程度劃分檔次，作為需求變更評估的一項(xiàng)依據(jù)。
例如，每周或每兩周甚至每月召開一次需求變更專題會(huì)議，集中研究處理這些零碎變更事項(xiàng)，主動(dòng)控制好工作節(jié)奏，盡量避免由于處理零碎變更而影響項(xiàng)目進(jìn)度。針對會(huì)議結(jié)果可向客戶正式提交一份需求變更計(jì)劃，注明變更引起的時(shí)間、成本、工期代價(jià)和增加工作量等。
要求客戶配合需求變更計(jì)劃，確定變更時(shí)限，控制變更規(guī)模，過時(shí)變更不候，離譜變更不做，保大局棄小變。 （4）安排專職人員負(fù)責(zé)變更管理 有時(shí)開發(fā)任務(wù)較重，開發(fā)人員容易陷入開發(fā)工作中而忽略了與客戶的隨時(shí)溝通。
因此，需要安排一名專職的需求變更聯(lián)絡(luò)人員，負(fù)責(zé)與客戶及時(shí)交流，跟蹤和匯報(bào)需求變更完成進(jìn)度和情況。同時(shí)，可以成立項(xiàng)目變更控制小組，負(fù)責(zé)裁定接受哪些變更，小組由項(xiàng)目所涉及的多方人員共同組成，應(yīng)該包括客戶方和開發(fā)方的決策人員在內(nèi)。
（5）確認(rèn)客戶是否接受變更的代價(jià) 要讓客戶認(rèn)識到變更都是有代價(jià)的，要和客戶一起判斷需求變更是否依然進(jìn)行。例如，變更是沒有問題的，但是要明確客戶能否接受由此引起的如進(jìn)度延遲、費(fèi)用增加、效率下降等問題。
一般來說，如果客戶認(rèn)為該變更是必須的（不是其上級領(lǐng)導(dǎo)拍腦袋提出的）就會(huì)接受這些后果。通過與客戶協(xié)商，這樣開發(fā)團(tuán)隊(duì)即使沒有回報(bào)，也不會(huì)招致公司和客戶雙方的埋怨。
如果客戶認(rèn)為該變更雖然有必要但是可以暫緩，雙方簽署備忘錄后留待以后解決。如果客戶認(rèn)為該變更可有可無，多數(shù)情況下會(huì)取消變更。
這樣即可防止頻繁變更，也讓客戶認(rèn)識到不是所有的需求都需要變更。
2.如何做好需求變更管理
項(xiàng)目是以客戶的需求為中心，而不是為技術(shù)而遷就需求。
本章包括以下內(nèi)容： 一. 讓客戶暢所欲言，羅列出所有的需求 二. 透過現(xiàn)象分析潛在的需求 三. 利用自然的語言描述項(xiàng)目模型 四. 利用示意圖和圖表將用戶的需求表現(xiàn)出來。 五. 什么人要看需求分析報(bào)告？ 六. 建立需求變更日志，制作新版本的需求分析報(bào)告。
七. 本階段重點(diǎn)工作角色 八. 總結(jié) 一：讓客戶暢所欲言，羅列出所有的需求 讓用戶將所有的想法盡可能的闡述清楚，并把所有的要求羅列出來，不要遺漏。這時(shí)候不應(yīng)該害怕“勾引”起客戶的潛在需求而增加設(shè)計(jì)開發(fā)的工作量，從而被今后客戶無止境的變更拖入泥潭，直接明白地跟客戶把問題和要求一條條地列出來，把條理、歸納、分析先都扔到一邊去，將用戶最原始、最完整的要求準(zhǔn)確地記錄下來就完成了第一步的工作。
很明顯，假如客戶的需求做的都不完整，隨時(shí)可能會(huì)產(chǎn)生意想之外的變更，甚至這個(gè)變更會(huì)破壞已經(jīng)做的模型及結(jié)構(gòu)，那么這個(gè)項(xiàng)目從開始就注定了會(huì)失??；比如站點(diǎn)所有的功能都實(shí)現(xiàn)了，本地測試起來也沒有什么問題了，但是你卻不知道客戶的系統(tǒng)是要承受每天100萬獨(dú)立IP的訪問，而你原來想當(dāng)然的以為了不起就是1萬獨(dú)立IP訪問的訪問流量，稍微有經(jīng)驗(yàn)的開發(fā)人員都會(huì)明白這樣的設(shè)計(jì)是個(gè)災(zāi)難，無論是應(yīng)用服務(wù)器、數(shù)據(jù)庫還是程序全部要重新開發(fā)！ 二：透過現(xiàn)象分析潛在的需求 很多情況下客戶并非專業(yè)人士，在他們滔滔不絕的描述中不能指望他們幫助我們整理出重點(diǎn)和技術(shù)難關(guān)，這需要我們?nèi)榭蛻暨M(jìn)行分析、歸納和整理，尤其是客戶談的不多卻又是技術(shù)上實(shí)現(xiàn)難度和強(qiáng)度很高的地方特別值得注意。 客戶往往對需求的概念是非常模糊的，大多時(shí)候給出的需求都是籠統(tǒng)而且尺度難以控制的，這就要求業(yè)務(wù)人員在傾聽了客戶的詳細(xì)說明以后，幫助客戶進(jìn)行整理和分析，同時(shí)預(yù)測客戶在開發(fā)過程中變更及今后應(yīng)用中可能進(jìn)行修改升級的潛在需求。
比如在為客戶設(shè)計(jì)辦公自動(dòng)化系統(tǒng)的時(shí)候，也許就要為客戶預(yù)留將來與他們的業(yè)務(wù)單位進(jìn)行交互的通道；在設(shè)計(jì)郵件系統(tǒng)的時(shí)候要考慮可能會(huì)需要廣告管理服務(wù)器；設(shè)計(jì)網(wǎng)絡(luò)電子商店時(shí)今后增加庫存產(chǎn)品進(jìn)銷存統(tǒng)計(jì)分析等等；限于時(shí)間財(cái)力的考慮，客戶通常能夠接受分階段實(shí)施的開發(fā)過程，在需求分析時(shí)，提早為客戶設(shè)想到今后的需求變更除了使項(xiàng)目開發(fā)更加順利以外，也為今后業(yè)務(wù)的進(jìn)一步深入打下了更好的基礎(chǔ)。 筆者曾負(fù)責(zé)一個(gè)大型新聞網(wǎng)站的設(shè)計(jì)，當(dāng)客戶拿著將近五十頁厚的一本設(shè)計(jì)要求報(bào)告時(shí)，我發(fā)現(xiàn)有四十頁的內(nèi)容對程序開發(fā)來說都是重復(fù)的，而在其中一頁的角落卻畫了個(gè)“搜索其他網(wǎng)站相關(guān)新聞”的按鈕，并且沒有做任何說明，僅僅這10個(gè)字所完成的工作量完全頂?shù)纳掀渌氖撝貜?fù)贅述所做的工作，客戶完全不知道這個(gè)要求引發(fā)的問題實(shí)際就是一個(gè)搜索引擎的開發(fā)，通過協(xié)商，客人同意了修改成站內(nèi)搜索的引擎。
三：利用自然的語言描述項(xiàng)目模型 在業(yè)務(wù)員與客戶進(jìn)行溝通和調(diào)查時(shí)撰寫的需求分析，盡可能用自然的語言進(jìn)行描述，雖然客戶的水平和資歷有所不同，但是最自然的描述能夠使項(xiàng)目開發(fā)的各個(gè)成員都能清楚地理解需求含義，不至于在理解上產(chǎn)生偏差。對客戶而言，這樣的模型描述最接近真實(shí)，容易參與修訂，并能以此為測試和驗(yàn)收的依據(jù)。
3.如何控制需求變更
你必須面對這個(gè)現(xiàn)實(shí)：需求變更是不可避免的。項(xiàng)目經(jīng)理應(yīng)該做的，是如何在發(fā)生需求變更的情況盡量減少其對項(xiàng)目的影響。需求變更不可避免，不是說就不做需求變更的控制了，需求變更如果量很大，對項(xiàng)目的影響無論如何也降不下來，因此還是要在控制需求變更上下功夫，但不要奢望杜絕需求變更。
對于管理信息系統(tǒng)的項(xiàng)目，其需求的核心點(diǎn)在于業(yè)務(wù)流程，如果業(yè)務(wù)流程保證沒問題了，那么系統(tǒng)就不會(huì)發(fā)生大的需求變更，界面調(diào)整一下，多一兩個(gè)字段，甚至多一兩個(gè)查詢頁面，都對系統(tǒng)不會(huì)產(chǎn)生太大的影響；但是如果流程變了，比如中間加了一個(gè)環(huán)節(jié)，或是環(huán)節(jié)間數(shù)據(jù)交互的變更，都可能會(huì)給整個(gè)系統(tǒng)帶來很大甚至致命的影響，有可能因?yàn)槟沉鞒痰淖兓瘜?dǎo)致整個(gè)系統(tǒng)都要重新翻一遍，這樣的修改對質(zhì)量的影響是非?？膳碌?。
要把握用戶的流程，首先看用戶這個(gè)業(yè)務(wù)流程是否正在正常的運(yùn)行，在這種情況下，你把這個(gè)流程調(diào)研清楚了就沒有問題了；但是如果業(yè)務(wù)流程是用戶新構(gòu)想出來，正指望著你通過系統(tǒng)去實(shí)施（也可以說試試）這個(gè)流程，那你就要小心了，必須仔細(xì)的分析這個(gè)流程的可行性，主動(dòng)的和客戶探討這個(gè)流程的缺陷，可能面臨的問題，必要時(shí)請有關(guān)專家做咨詢，總之，一定要保證流程的可行性，否則流程一旦執(zhí)行不下去，雖然軟件本身沒有任何質(zhì)量問題，你還得改。
對于流程分析要了解哪些關(guān)鍵點(diǎn)呢，首先當(dāng)然是有哪些環(huán)節(jié)，環(huán)節(jié)間的運(yùn)作關(guān)系，比如報(bào)銷流程，有填單、部門領(lǐng)導(dǎo)審批、財(cái)務(wù)稽核、主管副總審批、結(jié)算這些環(huán)節(jié)，簡單來說是依次傳遞的；其次要了解每一環(huán)節(jié)的控制點(diǎn)，比如領(lǐng)導(dǎo)審批，可以通過、不通過，一定要注意不通過這個(gè)非正常流程的下一節(jié)點(diǎn)，也許是終點(diǎn)（該報(bào)銷單作廢，要求報(bào)銷人重填），也許又到了填報(bào)環(huán)節(jié)（報(bào)銷人可以修改后重新提交審批）；然后一定要搞清楚環(huán)節(jié)間的數(shù)據(jù)和傳遞關(guān)系，這是非常重要的，因?yàn)檫@些數(shù)據(jù)和關(guān)系至少會(huì)影響兩個(gè)環(huán)節(jié)的處理，甚至可能影響整個(gè)流程的處理，而其他的無需傳遞的數(shù)據(jù)項(xiàng)，一般只對某個(gè)環(huán)節(jié)的處理產(chǎn)生影響，即使發(fā)生變化也無關(guān)大局。
這三點(diǎn)把握住了，流程也就基本清楚了，但是要注意，了解這些信息首先是通過和客戶的直接交流，同時(shí)一定要注意分析客戶提供的每一環(huán)節(jié)的表單和最終的分析報(bào)表，確定每一信息的來源，因?yàn)楸韱魏蛨?bào)表的數(shù)據(jù)理論上講都是通過流程的處理得到的，它們真的都包含在流程處理中了嗎？
4.如何控制需求變更
你必須面對這個(gè)現(xiàn)實(shí)：需求變更是不可避免的。
項(xiàng)目經(jīng)理應(yīng)該做的，是如何在發(fā)生需求變更的情況盡量減少其對項(xiàng)目的影響。需求變更不可避免，不是說就不做需求變更的控制了，需求變更如果量很大，對項(xiàng)目的影響無論如何也降不下來，因此還是要在控制需求變更上下功夫，但不要奢望杜絕需求變更。
對于管理信息系統(tǒng)的項(xiàng)目，其需求的核心點(diǎn)在于業(yè)務(wù)流程，如果業(yè)務(wù)流程保證沒問題了，那么系統(tǒng)就不會(huì)發(fā)生大的需求變更，界面調(diào)整一下，多一兩個(gè)字段，甚至多一兩個(gè)查詢頁面，都對系統(tǒng)不會(huì)產(chǎn)生太大的影響；但是如果流程變了，比如中間加了一個(gè)環(huán)節(jié)，或是環(huán)節(jié)間數(shù)據(jù)交互的變更，都可能會(huì)給整個(gè)系統(tǒng)帶來很大甚至致命的影響，有可能因?yàn)槟沉鞒痰淖兓瘜?dǎo)致整個(gè)系統(tǒng)都要重新翻一遍，這樣的修改對質(zhì)量的影響是非?？膳碌?。 要把握用戶的流程，首先看用戶這個(gè)業(yè)務(wù)流程是否正在正常的運(yùn)行，在這種情況下，你把這個(gè)流程調(diào)研清楚了就沒有問題了；但是如果業(yè)務(wù)流程是用戶新構(gòu)想出來，正指望著你通過系統(tǒng)去實(shí)施（也可以說試試）這個(gè)流程，那你就要小心了，必須仔細(xì)的分析這個(gè)流程的可行性，主動(dòng)的和客戶探討這個(gè)流程的缺陷，可能面臨的問題，必要時(shí)請有關(guān)專家做咨詢，總之，一定要保證流程的可行性，否則流程一旦執(zhí)行不下去，雖然軟件本身沒有任何質(zhì)量問題，你還得改。
對于流程分析要了解哪些關(guān)鍵點(diǎn)呢，首先當(dāng)然是有哪些環(huán)節(jié)，環(huán)節(jié)間的運(yùn)作關(guān)系，比如報(bào)銷流程，有填單、部門領(lǐng)導(dǎo)審批、財(cái)務(wù)稽核、主管副總審批、結(jié)算這些環(huán)節(jié)，簡單來說是依次傳遞的；其次要了解每一環(huán)節(jié)的控制點(diǎn)，比如領(lǐng)導(dǎo)審批，可以通過、不通過，一定要注意不通過這個(gè)非正常流程的下一節(jié)點(diǎn)，也許是終點(diǎn)（該報(bào)銷單作廢，要求報(bào)銷人重填），也許又到了填報(bào)環(huán)節(jié)（報(bào)銷人可以修改后重新提交審批）；然后一定要搞清楚環(huán)節(jié)間的數(shù)據(jù)和傳遞關(guān)系，這是非常重要的，因?yàn)檫@些數(shù)據(jù)和關(guān)系至少會(huì)影響兩個(gè)環(huán)節(jié)的處理，甚至可能影響整個(gè)流程的處理，而其他的無需傳遞的數(shù)據(jù)項(xiàng)，一般只對某個(gè)環(huán)節(jié)的處理產(chǎn)生影響，即使發(fā)生變化也無關(guān)大局。 這三點(diǎn)把握住了，流程也就基本清楚了，但是要注意，了解這些信息首先是通過和客戶的直接交流，同時(shí)一定要注意分析客戶提供的每一環(huán)節(jié)的表單和最終的分析報(bào)表，確定每一信息的來源，因?yàn)楸韱魏蛨?bào)表的數(shù)據(jù)理論上講都是通過流程的處理得到的，它們真的都包含在流程處理中了嗎？。
5.軟件項(xiàng)目管理實(shí)踐之如何控制需求變更?
需求變更的控制關(guān)鍵在于建立建立相應(yīng)的控制組織、變更控制和跟蹤系統(tǒng)以及規(guī)范變更流程，主要有：
1、建立組織。項(xiàng)目啟動(dòng)時(shí)，需要盡可能的與客戶溝通，建立正式的對變更進(jìn)行控制的組織，成員包括雙方高層（掛名）、甲乙雙方的項(xiàng)目負(fù)責(zé)人、相關(guān)的需求負(fù)責(zé)人等。如果客戶認(rèn)為無需單獨(dú)設(shè)置這樣的正式組織，也會(huì)要求客戶指定項(xiàng)目的負(fù)責(zé)人，每個(gè)相關(guān)的業(yè)務(wù)科室指定一名需求負(fù)責(zé)人，這樣做的目的是如出現(xiàn)變更可以很快的臨時(shí)組建一個(gè)對變更負(fù)責(zé)的組織，并且可以找到相應(yīng)的負(fù)責(zé)人；
2、建立變更控制和跟蹤系統(tǒng)。建立該系統(tǒng)的目的是統(tǒng)一管理需求變更和跟蹤變更的狀態(tài)，便于項(xiàng)目組測試人員、開發(fā)人員、系統(tǒng)分析員以及PM相互之間的溝通和交流；經(jīng)比較和選型，可以選用了JIRA作為變更控制和跟蹤系統(tǒng)；
3、規(guī)范流程。甲乙雙方的項(xiàng)目組成立后，根據(jù)角色定義，確定變更流程。
1）變更申請。系統(tǒng)界面如按鈕的位置、字段的位置的細(xì)微調(diào)整，不涉及到業(yè)務(wù)規(guī)則，對基線基本沒有影響的變更，由測試人員直接在變更控制系統(tǒng)中提出；其他如操作風(fēng)格的較大變化、業(yè)務(wù)規(guī)則的變化等，均要求客戶提出電子和書面的需求變更單；
2）變更評估。由項(xiàng)目組組織人員對變更進(jìn)行變更的合理性分析，變更替換方案分析，工作量的估算以及涉及什么模塊、影響什么模塊等影響分析；
3）變更決策。根據(jù)上節(jié)確定的溝通策略，與客戶溝通交流，確定變更的處理方式；
4）變更實(shí)施。由測試人員在變更控制系統(tǒng)中填寫變更信息（狀態(tài)：待處理），由系統(tǒng)分析員填寫處理方法和影響分析后交由開發(fā)人員實(shí)施（狀態(tài)：處理中）；
5）變更驗(yàn)證。測試人員根據(jù)變更控制系統(tǒng)的變更狀態(tài)反饋（狀態(tài)：已解決），待相應(yīng)的版本發(fā)布后，對變更進(jìn)行驗(yàn)證測試，這時(shí)候特別要注意的是記錄該變更的修改是否引起了該模塊或其他模塊產(chǎn)生缺陷。通常，測試人員根據(jù)系統(tǒng)分析員在變更控制系統(tǒng)中標(biāo)注的影響模塊，逐一進(jìn)行回歸測試，以確保不影響原有模塊的前提下變更已正確實(shí)施；內(nèi)部測試完畢后，如系統(tǒng)已上線，則由客戶相關(guān)負(fù)責(zé)人在模擬生產(chǎn)環(huán)境中進(jìn)行驗(yàn)收測試；
6）溝通歸檔。變更驗(yàn)證后，測試人員關(guān)閉變更（狀態(tài)：已關(guān)閉），項(xiàng)目經(jīng)理告知客戶已測試完畢，溝通發(fā)布時(shí)間并說明那些模塊可能有影響以及發(fā)現(xiàn)問題的反饋途徑和方式。
通過以上幾種手段，如執(zhí)行實(shí)施到位，基本可以有效的把變更置于控制之下。
最后，值得一提的是，變更實(shí)施或者系統(tǒng)缺陷修復(fù)涉及到多方面的人員，可能牽涉軟件系統(tǒng)中的多個(gè)模塊，處理和驗(yàn)證的流程復(fù)雜，溝通等管理成本高昂，如果變更和質(zhì)量控制不好，會(huì)直接影響項(xiàng)目的進(jìn)度和成本。
6.如何做好需求變更管理
項(xiàng)目是以客戶的需求為中心，而不是為技術(shù)而遷就需求。
本章包括以下內(nèi)容： 一. 讓客戶暢所欲言，羅列出所有的需求 二. 透過現(xiàn)象分析潛在的需求 三. 利用自然的語言描述項(xiàng)目模型 四. 利用示意圖和圖表將用戶的需求表現(xiàn)出來。 五. 什么人要看需求分析報(bào)告？ 六. 建立需求變更日志，制作新版本的需求分析報(bào)告。
七. 本階段重點(diǎn)工作角色 八. 總結(jié) 一：讓客戶暢所欲言，羅列出所有的需求 讓用戶將所有的想法盡可能的闡述清楚，并把所有的要求羅列出來，不要遺漏。這時(shí)候不應(yīng)該害怕“勾引”起客戶的潛在需求而增加設(shè)計(jì)開發(fā)的工作量，從而被今后客戶無止境的變更拖入泥潭，直接明白地跟客戶把問題和要求一條條地列出來，把條理、歸納、分析先都扔到一邊去，將用戶最原始、最完整的要求準(zhǔn)確地記錄下來就完成了第一步的工作。
很明顯，假如客戶的需求做的都不完整，隨時(shí)可能會(huì)產(chǎn)生意想之外的變更，甚至這個(gè)變更會(huì)破壞已經(jīng)做的模型及結(jié)構(gòu)，那么這個(gè)項(xiàng)目從開始就注定了會(huì)失?。槐热缯军c(diǎn)所有的功能都實(shí)現(xiàn)了，本地測試起來也沒有什么問題了，但是你卻不知道客戶的系統(tǒng)是要承受每天100萬獨(dú)立IP的訪問，而你原來想當(dāng)然的以為了不起就是1萬獨(dú)立IP訪問的訪問流量，稍微有經(jīng)驗(yàn)的開發(fā)人員都會(huì)明白這樣的設(shè)計(jì)是個(gè)災(zāi)難，無論是應(yīng)用服務(wù)器、數(shù)據(jù)庫還是程序全部要重新開發(fā)！ 二：透過現(xiàn)象分析潛在的需求 很多情況下客戶并非專業(yè)人士，在他們滔滔不絕的描述中不能指望他們幫助我們整理出重點(diǎn)和技術(shù)難關(guān)，這需要我們?nèi)榭蛻暨M(jìn)行分析、歸納和整理，尤其是客戶談的不多卻又是技術(shù)上實(shí)現(xiàn)難度和強(qiáng)度很高的地方特別值得注意。 客戶往往對需求的概念是非常模糊的，大多時(shí)候給出的需求都是籠統(tǒng)而且尺度難以控制的，這就要求業(yè)務(wù)人員在傾聽了客戶的詳細(xì)說明以后，幫助客戶進(jìn)行整理和分析，同時(shí)預(yù)測客戶在開發(fā)過程中變更及今后應(yīng)用中可能進(jìn)行修改升級的潛在需求。
比如在為客戶設(shè)計(jì)辦公自動(dòng)化系統(tǒng)的時(shí)候，也許就要為客戶預(yù)留將來與他們的業(yè)務(wù)單位進(jìn)行交互的通道；在設(shè)計(jì)郵件系統(tǒng)的時(shí)候要考慮可能會(huì)需要廣告管理服務(wù)器；設(shè)計(jì)網(wǎng)絡(luò)電子商店時(shí)今后增加庫存產(chǎn)品進(jìn)銷存統(tǒng)計(jì)分析等等；限于時(shí)間財(cái)力的考慮，客戶通常能夠接受分階段實(shí)施的開發(fā)過程，在需求分析時(shí)，提早為客戶設(shè)想到今后的需求變更除了使項(xiàng)目開發(fā)更加順利以外，也為今后業(yè)務(wù)的進(jìn)一步深入打下了更好的基礎(chǔ)。 筆者曾負(fù)責(zé)一個(gè)大型新聞網(wǎng)站的設(shè)計(jì)，當(dāng)客戶拿著將近五十頁厚的一本設(shè)計(jì)要求報(bào)告時(shí)，我發(fā)現(xiàn)有四十頁的內(nèi)容對程序開發(fā)來說都是重復(fù)的，而在其中一頁的角落卻畫了個(gè)“搜索其他網(wǎng)站相關(guān)新聞”的按鈕，并且沒有做任何說明，僅僅這10個(gè)字所完成的工作量完全頂?shù)纳掀渌氖撝貜?fù)贅述所做的工作，客戶完全不知道這個(gè)要求引發(fā)的問題實(shí)際就是一個(gè)搜索引擎的開發(fā)，通過協(xié)商，客人同意了修改成站內(nèi)搜索的引擎。
三：利用自然的語言描述項(xiàng)目模型 在業(yè)務(wù)員與客戶進(jìn)行溝通和調(diào)查時(shí)撰寫的需求分析，盡可能用自然的語言進(jìn)行描述，雖然客戶的水平和資歷有所不同，但是最自然的描述能夠使項(xiàng)目開發(fā)的各個(gè)成員都能清楚地理解需求含義，不至于在理解上產(chǎn)生偏差。對客戶而言，這樣的模型描述最接近真實(shí)，容易參與修訂，并能以此為測試和驗(yàn)收的依據(jù)。
7.怎么樣處理需求變更
可以在合同上規(guī)定，
在正式確定《需求說明書》前，可以由客戶自由提出需求（當(dāng)然需求分析人員保證需求的質(zhì)量）。
一旦《軟件需求說明書》完成，并且客戶簽字確認(rèn)了它。那么就禁止客戶隨意的更改需求。
1）客戶新/變更的需求按照某個(gè)價(jià)格另外的收取費(fèi)用。
2）開發(fā)方有權(quán)拒絕客戶的某種新/變更需求。
不過這要在合同中明確客戶在確認(rèn)了《需求說明書》后不得隨意的提出新/變更需求。
8.什么是需求變更
需求變更，即對項(xiàng)目或者軟件開發(fā)需求的更變，是指在跟客戶簽訂了項(xiàng)目或軟件開發(fā)協(xié)議之后，在完成交付之前，客戶提出的對項(xiàng)目或者軟件的功能或非功能性的更改要求。
客觀地說，“項(xiàng)目一旦啟動(dòng)，變更也就隨之而來”，但是，需求的變更必然會(huì)影響到項(xiàng)目的開展或者軟件的開發(fā)，需求變更對項(xiàng)目或者軟件開發(fā)成敗有重要影響，我們既不能一概拒絕客戶的變更要求，也不能一味地遷就客戶，所以控制需求變更才是最好的應(yīng)對策略。當(dāng)然，需求變更控制的目的不是控制變更的發(fā)生，而是對變更進(jìn)行科學(xué)的管理，要確保變更有序地進(jìn)行。
一般地說，為了確保需求變更符合雙方的利益，可以采取如下措施來控制需求變更：
1.分級管理客戶需求，重點(diǎn)客戶重點(diǎn)管理；
2.項(xiàng)目開發(fā)生命周期全過程需求變更管理，確保整個(gè)項(xiàng)目順利完成；
3.專人負(fù)責(zé)需求變更管理工作，確保工作同步進(jìn)行；
4.契約化管理需求變更。合作雙方在簽訂協(xié)議之初，書面約定需求變更的提出方式、評價(jià)程序、修改要求、執(zhí)行過程以及驗(yàn)收要求等。只有這樣，才能確保需求變更按程序和要求有序進(jìn)行。
5.需求變更必須提前溝通，雙方要加強(qiáng)信息交換，防止搞突然襲擊，更不能提出超越雙方能力的需求變更。
