王海濤 馬秀紅

摘要:計(jì)算機(jī)軟件項(xiàng)目的需求分析是項(xiàng)目開發(fā)的一個(gè)重要階段，需求分析做的好壞直接關(guān)系到系統(tǒng)設(shè)計(jì)的工作質(zhì)量，甚至影響到項(xiàng)目的成敗。為此，軟件項(xiàng)目的需求分析必須規(guī)范執(zhí)行其流程，熟悉項(xiàng)目用戶與開發(fā)人全貌及項(xiàng)目需求確認(rèn)和需求評審等，只有這樣才能保證軟件開發(fā)的順利完成。

關(guān)鍵詞:需求分析；項(xiàng)目干系人；系統(tǒng)分析員

中圖分類號：F270 文獻(xiàn)標(biāo)識碼：A 文章編號：1003-3890（2012）05-0056-03

需求分析是軟件開發(fā)過程的核心，其結(jié)果直接影響到整個(gè)的軟件開發(fā)過程。據(jù)相關(guān)資料顯示，因需求分析因素所造成的軟件項(xiàng)目失敗或缺陷約占60%，屬于系統(tǒng)實(shí)施階段的代碼錯(cuò)誤，而導(dǎo)致軟件項(xiàng)目失敗的比率約為40%。項(xiàng)目失敗的根源在于需求分析不明確，需求調(diào)研不徹底，從而引發(fā)需求不斷變更，最終導(dǎo)致項(xiàng)目停滯。這些變更不僅加大了開發(fā)成本、項(xiàng)目無法按時(shí)完成等嚴(yán)重問題，而且，還有可能引發(fā)用戶方與開發(fā)方之間互相指責(zé)，導(dǎo)致項(xiàng)目擱淺。

一、軟件項(xiàng)目需求分析的重要性

軟件系統(tǒng)的開發(fā)主要分為五個(gè)階段，分別是系統(tǒng)的需求分析階段、系統(tǒng)設(shè)計(jì)階段、系統(tǒng)實(shí)施階段、系統(tǒng)測試階段和系統(tǒng)維護(hù)階段。而需求分析階段是整個(gè)五階段中的重中之重，在該階段所占的工作量大概是整個(gè)軟件開發(fā)項(xiàng)目的50%，邏輯方案是該階段的最終成果。邏輯方案不僅是進(jìn)行系統(tǒng)設(shè)計(jì)的依據(jù)，而且，還是系統(tǒng)最終驗(yàn)收的說明性文件。從以往的經(jīng)驗(yàn)來看，需求分析做的不徹底，沒有深層次的挖掘用戶需求，往往可能導(dǎo)致整個(gè)項(xiàng)目無法達(dá)到預(yù)期的效果，或者說設(shè)計(jì)開發(fā)出來的產(chǎn)品不能滿足用戶的需求。

需求分析首先要對現(xiàn)有系統(tǒng)有充分的認(rèn)識和了解，在此基礎(chǔ)上，通過識別關(guān)鍵問題、分析項(xiàng)目的可行性、詳細(xì)調(diào)查研究、系統(tǒng)化分析，最終設(shè)計(jì)完成該項(xiàng)目的新系統(tǒng)邏輯方案。只有系統(tǒng)分析員明白了用戶的真正需求，才能開發(fā)出滿足用戶的軟件產(chǎn)品。在這里，要強(qiáng)調(diào)一點(diǎn)的是，在做需求分析的時(shí)候，開發(fā)方一定要指派有實(shí)際工作經(jīng)驗(yàn)的系統(tǒng)分析員來與用戶溝通，而不是指派具體的開發(fā)人員，這將避免一些溝通不暢的問題發(fā)生。系統(tǒng)分析員在了解用戶的基本需求之后，要以書面的形式，準(zhǔn)確地制定出軟件需求報(bào)告。該報(bào)告主要說明系統(tǒng)的行為屬性，是項(xiàng)目開發(fā)過程中對系統(tǒng)的制約。要實(shí)現(xiàn)這一目標(biāo)，就需要系統(tǒng)分析員與用戶之間做到緊密協(xié)作，甚至系統(tǒng)分析員要深入到用戶方的實(shí)際業(yè)務(wù)當(dāng)中，把自己當(dāng)做是用戶，從用戶的角度思考問題，只有這樣，開發(fā)方才可以真正了解用戶需要什么，系統(tǒng)應(yīng)該做什么。

二、規(guī)范執(zhí)行需求分析的流程

需求分析的過程，要嚴(yán)格執(zhí)行規(guī)范化操作，囫圇吞棗式的需求調(diào)研是不可取的。開發(fā)方在做需求分析過程中，一定要嚴(yán)格把關(guān)，從對用戶負(fù)責(zé)的角度出發(fā)，并且也為了降低自己的開發(fā)成本，對無法與用戶實(shí)現(xiàn)很好溝通的項(xiàng)目經(jīng)理要及時(shí)叫停，避免后續(xù)工作無法正常進(jìn)行。

按照需求分析的過程，同樣也可將其分為五個(gè)階段：首先要獲取用戶需求，其次是分析用戶的需求，第三是編寫需求文檔，第四是評審需求文檔，最后是管理需求。規(guī)范執(zhí)行需求分析的流程，是需求分析能否成功的關(guān)鍵。圖1是根據(jù)實(shí)際工作經(jīng)驗(yàn)總結(jié)出的需求分析工作流程：

在需求分析過程中，開發(fā)方要深入用戶方的各個(gè)部門，最簡單的項(xiàng)目也要做到用戶確認(rèn)需求和需求評審兩個(gè)過程，復(fù)雜的項(xiàng)目甚至要做到多次。

三、盡快熟悉項(xiàng)目用戶方干系人全貌

項(xiàng)目干系人又稱為項(xiàng)目相關(guān)利益者，是指積極參與項(xiàng)目、或其利益會受到項(xiàng)目執(zhí)行或完成情況影響的個(gè)人或組織，項(xiàng)目干系人對項(xiàng)目的目的和結(jié)果施加影響。項(xiàng)目管理團(tuán)隊(duì)，即開發(fā)方，必須識別項(xiàng)目干系人，確定他們的需求和期望，盡最大可能地管理與需求相關(guān)的因素，以獲得項(xiàng)目的成功。因此，應(yīng)當(dāng)從項(xiàng)目的啟動開始，系統(tǒng)分析員用戶方相關(guān)人員的配合下，逐步分清項(xiàng)目用戶方干系人具體包含哪些人和部門，通過開方法與其溝通加之用戶方領(lǐng)導(dǎo)的協(xié)調(diào)以驅(qū)動他們對項(xiàng)目的支持，從而減小其對項(xiàng)目的阻力。

有些項(xiàng)目在做需求調(diào)研時(shí)，因受用戶方提出的進(jìn)度要求等因素影響，有些系統(tǒng)分析員不愿與用戶過多地交流，只是發(fā)一些調(diào)研表做一些大概的了解。往往是因?yàn)殚_發(fā)方已有與該建設(shè)單位相似的原型，會亟不可待地去推廣，這樣會導(dǎo)致某些差異需求得不到深入了解，用戶方只能被動地去適應(yīng)原型系統(tǒng)，這樣的做法是不可取的。另一種情況則是開發(fā)方與用戶方的技術(shù)部門交流比較多，而向業(yè)務(wù)部門和實(shí)際使用人員調(diào)查的力度不夠，往往容易造成原型試用后，與用戶的需求不一致，不得不再對需求做較大調(diào)整，造成開發(fā)周期不斷延期，開發(fā)成本大大增加。因此，熟悉項(xiàng)目用戶方干系人全貌是進(jìn)行需求調(diào)研的第一步，也是需求調(diào)研的基礎(chǔ)。在定制的開發(fā)項(xiàng)目中，最重要的是要弄清楚用戶方中的組織結(jié)構(gòu)關(guān)系、業(yè)務(wù)流程關(guān)系、數(shù)據(jù)流程關(guān)系。制定該項(xiàng)目的牽頭單位，在此基礎(chǔ)上，使用圖表的形式將這三種關(guān)系表現(xiàn)出來。

四、采取正確的方法獲取用戶需求

軟件開發(fā)項(xiàng)目的首要目標(biāo)就是要發(fā)現(xiàn)用戶的需求。在對用戶進(jìn)行需求調(diào)研過程中，使用的方式很多，初期調(diào)研可以采用會議的形式，后續(xù)的詳細(xì)調(diào)研以及需求確認(rèn)，可以采用電話、郵件、小組討論等方式，模擬演示也是一種很有效的形式，用戶比較直觀，容易發(fā)現(xiàn)、提出問題，但每一次調(diào)研過程當(dāng)中，都要做好筆錄，當(dāng)與用戶交流完畢以后，要對交流的結(jié)果進(jìn)行整理、分類，便于后續(xù)的分析活動。系統(tǒng)分析人員要對收集到需求做進(jìn)一步的梳理和分析工作，在這個(gè)過程中，首先要對用戶提出的具體需求，包括可能該項(xiàng)目目前不涉及的需求，都要知道“為什么”，并且判斷用戶提出的需求是否合理，對于不合理的需求，開發(fā)方要給出不合理的理由和原因。其次，要集中精力，把關(guān)注點(diǎn)放在需求分析階段關(guān)注的目標(biāo)上，即“做什么”，而不是“如何做”，第三就是要分析用戶提出的需求當(dāng)中所衍生出的隱含需求，這一點(diǎn)往往容易忽略掉，這就需要系統(tǒng)分析員在與用戶交流當(dāng)中，關(guān)注用戶的表情、眼神、用語，因?yàn)閷﹄[含需求不加以考慮或考慮不充分，往往會引起永無止境的需求變更。

在需求調(diào)研中，還要把握要求相關(guān)業(yè)務(wù)人員與領(lǐng)導(dǎo)同時(shí)出席，這將避免用戶所提需求的不負(fù)責(zé)任性和隨意性，以及對需求的確認(rèn)不夠積極等問題。項(xiàng)目開發(fā)方應(yīng)掌握用戶干系人需求，用戶干系人也應(yīng)具有一定的技術(shù)基礎(chǔ)，兩者缺一不可，只有這樣雙方溝通起來才比較容易達(dá)成一致。對某些需求，用戶可能無法想到，系統(tǒng)分析員要做到引導(dǎo)用戶的作用，并且要有足夠的耐心聆聽用戶的講述。

五、分析用戶需求并編寫需求調(diào)研報(bào)告

調(diào)研結(jié)束后，開發(fā)方要根據(jù)用戶的需求編寫需求調(diào)研報(bào)告，即提出新系統(tǒng)的邏輯方案。獲取用戶需求與分析用戶需求二者之間并不沖突，完全可以同時(shí)進(jìn)行，關(guān)鍵問題是如何詳細(xì)地描述用戶的需求，常用的方式是通過建立相關(guān)的模型來操作。通過建立模型，抽象出用戶的需求，以一種可視化的方式與用戶進(jìn)一步溝通。獲取用戶需求與分析需求二者之間有著類似的步驟，不同之處僅在于分析用戶需求時(shí)采用模型來描述。分析用戶需求所執(zhí)行的活動如下：

1. 用業(yè)務(wù)流程圖描述系統(tǒng)的整體業(yè)務(wù)活動，包括系統(tǒng)之間的接口和邊界。

2. 用數(shù)據(jù)流程圖模型來描述系統(tǒng)的數(shù)據(jù)流關(guān)系?？梢圆捎枚鄬哟蔚臄?shù)據(jù)流程圖加以描述，對于復(fù)雜的數(shù)據(jù)流關(guān)系或功能處理模塊要配以數(shù)據(jù)字典。

3. 通過原型向用戶展示系統(tǒng)界面以及各項(xiàng)功能模塊，用戶可以拿自己的需求與其相比較，存優(yōu)去劣。

4. 采用實(shí)體關(guān)系圖描述實(shí)體、屬性、關(guān)系三者之間的聯(lián)系。

在編寫需求說明書時(shí)，可以采用自然語言或結(jié)構(gòu)化語言來加以描述，當(dāng)然，可以將需求分析階段的各類圖表列入到需求調(diào)研報(bào)告中，需求文檔應(yīng)該包括用戶的所有需求（包括功能性需求和非功能性需求），這便于在需求確認(rèn)和需求評審階段，使用戶一目了然，容易理解。

六、項(xiàng)目的需求確認(rèn)和需求評審

開發(fā)方要從兩個(gè)角度出發(fā)來描述系統(tǒng)，一是全面詳細(xì)地描述現(xiàn)行系統(tǒng)的缺陷和不足，以及業(yè)務(wù)流程存在的不合理之處。二是在業(yè)務(wù)流程重組的基礎(chǔ)上，提出新系統(tǒng)所優(yōu)化的各項(xiàng)業(yè)務(wù)流程和系統(tǒng)所具有的優(yōu)點(diǎn)。并將二者業(yè)務(wù)流程文檔化后與客戶進(jìn)行探討，對于描述不準(zhǔn)確不精確的地方要加以細(xì)化，對于錯(cuò)誤的地方要進(jìn)行修改，最終讓客戶進(jìn)行確認(rèn)。需求評審的目的就是對需求分析階段的成果做出評價(jià)，提出不足，進(jìn)一步優(yōu)化流程，糾偏、完善需求調(diào)研報(bào)告。需求確認(rèn)與評審是不可逾越的兩個(gè)階段，有研究表明：由客戶發(fā)現(xiàn)的一個(gè)錯(cuò)誤，然后更正錯(cuò)誤，約需要多花90倍的時(shí)間，可以看出，需求確認(rèn)和評審階段的重要性。

需求評審的關(guān)鍵在于邀請這方面的專家、用戶、領(lǐng)導(dǎo)對新系統(tǒng)進(jìn)行評價(jià)。當(dāng)然，在確認(rèn)評審階段，開發(fā)使用雙方都要在場，開發(fā)方在講解需求報(bào)告時(shí)，要做到細(xì)致入微，不能放過任何一個(gè)功能模塊，使得雙方共同找出需求調(diào)研中不合理的、不完善的、有歧義的、遺漏的問題。需求評審的目的是要獲得用戶的認(rèn)可，如果用戶用戶以種種理由不以確認(rèn)，那么系統(tǒng)分析員要盡快拿出原型系統(tǒng)來給用戶確認(rèn)，否則后續(xù)的工作將無法順利開展，并伴隨著無窮無盡的需求變更。

參考文獻(xiàn)：

[1]黃梯云.管理信息系統(tǒng)（第四版）[Ｍ].北京:高等教育出版社，2008.

[2]吳潔明.軟件工程應(yīng)用實(shí)踐教程[M].北京：清華大學(xué)出版社，2003，（８）.

[3]趙池龍.實(shí)用軟件工程[M].北京:電子工業(yè)出版社，2006.

[4]徐鋒.軟件需求最佳實(shí)踐:SERU過程框架原理與應(yīng)用[Ｍ].北京：電子工業(yè)出版社，2008.

責(zé)任編輯、校對：秦學(xué)詩