問題二：用戶與需求分析人員缺乏有效溝通，雙方誤解需求

　　人們?cè)诮涣鞯臅r(shí)候，經(jīng)常會(huì)發(fā)生“答非所問，問非所求”的事情，軟件用戶與開發(fā)人員缺乏有效溝通方法，交流上存在障礙，用戶與開發(fā)人員存在知識(shí)背景差異，都從自己的角度，使用自己的專業(yè)術(shù)語或語言表達(dá)方式來描述和理解問題，使得雙方并不能夠很好地就軟件需求達(dá)成共識(shí)。2005年北京某公司到我公司做調(diào)查，對(duì)方技術(shù)人員常掛在嘴邊的就是“BOM”，但作為用戶還沒有完全接受這個(gè)詞，他們用得最多的是流水號(hào)、生產(chǎn)線、配套件等。一般說來，用戶不太容易從計(jì)算機(jī)的角度去理解自己的需求問題。從而使需求描述的不一致，不規(guī)范，多義性。筆者今年夏季為某事業(yè)部編寫庫房管理軟件的時(shí)候，筆者采用快速原型化開發(fā)了此軟件，雙方出現(xiàn)了誤解的情況，比如：針對(duì)“數(shù)量”，我理解為整數(shù)，但實(shí)際上庫房數(shù)據(jù)中“數(shù)量”就是以小數(shù)為單位，她認(rèn)為我應(yīng)該理解了這個(gè)問題，實(shí)際上她前面輸入的數(shù)據(jù)的確都是整數(shù)，使用到一定的程度，結(jié)果顯示大相徑庭。對(duì)策：分析人員需要花更多的時(shí)間去了解系統(tǒng)用戶的特點(diǎn)，多學(xué)習(xí)用戶行業(yè)的專業(yè)術(shù)語，用用戶看得懂的語言來表達(dá)需求的內(nèi)容。其次，分析人員除了需要過硬的專業(yè)知識(shí)，還要具備較強(qiáng)的溝通交流能力。謙虛、誠懇地向用戶學(xué)習(xí)，才能探索出用戶的真正需求。如果能在用戶方找到即對(duì)生產(chǎn)過程了解，又懂計(jì)算機(jī)知識(shí)的行家來為開發(fā)人員與用戶牽線架橋則是最好不過的事情。

　　問題三：用戶的需求不斷變更

　　由于需求識(shí)別不全、業(yè)務(wù)發(fā)生變化、需求本身錯(cuò)誤、需求不清楚等原因，隨著客戶對(duì)項(xiàng)目的越來越深刻的理解，對(duì)他過去提出的需求要求一變?cè)僮儯鎸?duì)這種情況：需求人員要意識(shí)，做軟件就像裝修房子，永遠(yuǎn)可以找到需要增加的東西、需要改變的地方，“需求的變化是永恒，需求不可能是完備的”。因此我們?cè)谛枨螳@取的時(shí)候，一方面應(yīng)該跟用戶講清楚需求開發(fā)的重要性，讓用戶明白減少后期的需求變更的重要性，且隨意的需求變更帶來的風(fēng)險(xiǎn)（成本增加、進(jìn)度延后等）必將由用戶和開發(fā)者共同承擔(dān)。另一方面也需讓用戶明白：開發(fā)者和用戶更多的是戰(zhàn)略合作伙伴關(guān)系，其共同的目標(biāo)是：開發(fā)出適合用戶需要的軟件。

　　2、需求分析

　　問題一：主次不分

　　需求分析人員常站在自身的角度去理解用戶的需求造成主次不分。而實(shí)際上不同的系統(tǒng)對(duì)系統(tǒng)的功能與非功能性需求要求很不一樣。比如，金融系統(tǒng)一般對(duì)系統(tǒng)的安全質(zhì)量要求比較高。企業(yè)ERP系統(tǒng)一般對(duì)信息傳遞速度要求高一些。針對(duì)這種情況，首先需求分析人員可以借用當(dāng)前的需求分析工具和圖形的方式，明確用戶的功能需求和非功能需求，特別注意產(chǎn)品性能、使用性、完整性、可靠性等非功能性需求。其次就要充分考慮到哪些需求是相對(duì)固定的需求，哪些可能會(huì)產(chǎn)生變動(dòng)的需求，哪些需求會(huì)牽一發(fā)而動(dòng)全身，區(qū)分這些需求，設(shè)定用戶的每項(xiàng)需求、特性或使用實(shí)例的優(yōu)生級(jí)并安排在特定的產(chǎn)品版本或?qū)崿F(xiàn)步驟中，以應(yīng)付客戶后期的需求變更。

　　問題二：需求分析時(shí)間不夠

　　這個(gè)問題非常普通，用戶認(rèn)為“我出錢你出力，當(dāng)然以我的要求為準(zhǔn)”，但實(shí)際上不合理的要求會(huì)導(dǎo)致項(xiàng)目失敗，拿一個(gè)簡(jiǎn)單的例子來說明：假如1個(gè)人需要干100天時(shí)間才能把某件事情完成，為了趕進(jìn)度，現(xiàn)在增加人數(shù)，選100個(gè)人干一天把這件事情做完。絕大多數(shù)人都會(huì)認(rèn)為是不可能實(shí)現(xiàn)的。軟件項(xiàng)目也是如此，它有一個(gè)最短周期，也就是說無論你如何增加資源追趕進(jìn)度，都無法再縮短時(shí)間，在關(guān)鍵路徑上增加人力、物力資源，或許還會(huì)添亂。一般需求開發(fā)工作應(yīng)占全部工作量的15%。所以用戶方與開發(fā)方必須達(dá)成共識(shí)留足夠的時(shí)候給需求分析。

　　3、需求規(guī)格說明編寫

　　問題一：文檔混亂，文字表述過多

　　需求文檔是需求人員對(duì)前期工作的總結(jié)。需求人員寫出的文檔混亂，圖形連線錯(cuò)綜復(fù)雜。首先是需要理清思路：需求的描述可以從2個(gè)方面來進(jìn)行描述，一方面是對(duì)用戶現(xiàn)行系統(tǒng)的描述，一方面是對(duì)系統(tǒng)未來的設(shè)想。構(gòu)成企業(yè)信息系統(tǒng)主要包括基本要素：企業(yè)的組織結(jié)構(gòu)、流程、數(shù)據(jù)、商務(wù)規(guī)則與功能，其中從用戶的角度主要關(guān)注流程，是以流程為中心，通過流程將其他幾個(gè)要素貫穿起來，需求分析人員也應(yīng)該從這個(gè)角度來和用戶溝通；從開發(fā)者的角度主要關(guān)注企業(yè)的數(shù)據(jù)、商務(wù)規(guī)則與功能，以便于系統(tǒng)的實(shí)現(xiàn)；從實(shí)施者的角度主要關(guān)注企業(yè)的組織結(jié)構(gòu)與功能，以便于系統(tǒng)的發(fā)布與實(shí)施。企業(yè)組織結(jié)構(gòu)是用戶企業(yè)業(yè)務(wù)流程與信息的載體，對(duì)分析人員理解企業(yè)的業(yè)務(wù)和系統(tǒng)范圍有幫助；業(yè)務(wù)流程圖把企業(yè)的業(yè)務(wù)流程與部門職責(zé)結(jié)合起來了，且形象直觀；企業(yè)的數(shù)據(jù)（各種單據(jù)、帳本、報(bào)表等）可采用描述分類、格式化；企業(yè)商務(wù)規(guī)則與功能可以采用分類方法進(jìn)行。其次盡量采用SRS(需求規(guī)格說明書)，較好的模板為IEEE標(biāo)準(zhǔn)830-1998描述的SRS模板，下面是一個(gè)常見的需求說明書的模板：

　　1. 前言(目的、范圍、定義、縮寫詞、略語)www.mypm.net
　　2. 項(xiàng)目概述 （產(chǎn)品描述、產(chǎn)品功能、用戶特點(diǎn)、一般約束、假設(shè)和依據(jù)）
　　3. 功能性需求 （功能需求1、功能需求2….）
　　4. 外部接口 （用戶接口、硬件接口、軟件接口、通信接口）

　　5. 性能需求
　　6. 設(shè)計(jì)約束 （其他標(biāo)準(zhǔn)的約束、硬件的限制）
　　7. 屬性
　　8. 其他需求（數(shù)據(jù)庫….）
　　9. 附錄
　　10. 索引

　　4、需求論證

　　問題六：需求文檔口頭達(dá)到共識(shí)，缺乏文字依據(jù)

　　有時(shí)候因?yàn)闀r(shí)間緊湊或其他原因，即使達(dá)到了一致的共識(shí)，多數(shù)的用戶單位都不愿意在需求文檔上簽字。這種情況有可能導(dǎo)致后期需求不斷變更，需求變更影響軟件開發(fā)的進(jìn)度、成本，甚至有可能使得軟件開發(fā)中止。對(duì)策：需求分析人員與用戶建立良好的溝通渠道，強(qiáng)調(diào)需求文檔書面認(rèn)可的重要性，期望得到用戶的理解。

　　總結(jié)：

　　綜上所述，多數(shù)軟件項(xiàng)目都是在時(shí)間緊、人員少、項(xiàng)目預(yù)算有限的條件下完成的。在這些“先天不足”的條件下，如何做到項(xiàng)目進(jìn)度不延遲、工作量不超期、費(fèi)用不超支？首先就是關(guān)注需求分析。 “良好的開端就成功了一半”，需求分析做好了，對(duì)下一步的設(shè)計(jì)階段工作真正起到指導(dǎo)性作用，規(guī)避需求開發(fā)過程存在的問題，成功的軟件項(xiàng)目指日可待。