軟件需求開發(fā)存在的問題及對(duì)策

杜君益

軟件開發(fā)包含需求、設(shè)計(jì)、編碼和測(cè)試等4個(gè)階段，其中需求是最關(guān)鍵的一個(gè)輸入。據(jù)統(tǒng)計(jì)，不成功的項(xiàng)目中有30%～40%的問題是由需求造成的。大量研究表明，需求階段發(fā)現(xiàn)和糾正錯(cuò)誤的代價(jià)是軟件開發(fā)各階段中成本最低的。

如何正確地獲取用戶的需求，圍繞其進(jìn)行管理，以便最終交付給用戶符合其期望的產(chǎn)品是需求工程的任務(wù)。需求工程的研究產(chǎn)生了如CMM（能力成熟度模型）、UML（統(tǒng)一建模語言）、RUP（Rational統(tǒng)一建模過程）、CASE（用例）等管理方法和開發(fā)工具，軟件思想家溫伯格（GeraldM.Weinberg）指出，CMM只是一種標(biāo)準(zhǔn)，UML也只是一種記錄需求的工具，而不是捕獲需求的方法，需求的管理主要還是靠經(jīng)驗(yàn)。準(zhǔn)確而有效獲取用戶需求、精確表述用戶需求并得到用戶認(rèn)可，是軟件項(xiàng)目開發(fā)成功的最重要的因素之一。

一、什么是需求?

1997年IEEE軟件工程標(biāo)準(zhǔn)詞匯表對(duì)軟件需求的定義為：用戶解決問題或達(dá)到目標(biāo)所需的條件或能力。系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其它正式規(guī)定文檔所需具有的條件或能力。需求分為需求開發(fā)和需求管理，而需求開發(fā)又分為需求獲取、需求分析、編寫規(guī)格說明書和需求驗(yàn)證。如何幫助用戶提出準(zhǔn)確的需求、理解和分析用戶環(huán)境是需求獲取的過程。為問題涉及的信息、功能及行為建立模型并將用戶需求精確化、完全化是需求分析的過程，最終形成需求規(guī)格說明書是編寫規(guī)格說明書的過程，將需求說明書交付用戶并得到用戶認(rèn)可是需求驗(yàn)證的過程。需求獲取、分析、編寫需求規(guī)格說明和需求驗(yàn)證并不遵循線性的順序，這些活動(dòng)是相互隔開、增量和反復(fù)地進(jìn)行。

二、需求開發(fā)四步驟

1．需求獲取

需求獲取可采取如下辦法：（1）成立需求分析小組，劃分任務(wù)，細(xì)化側(cè)重點(diǎn)，為獲取用戶需求做好準(zhǔn)備工作；（2）訪談?dòng)脩臬@取問題，了解功能需求，還需要注意非功能需求。訪談?dòng)脩羟?，首先要了解和劃分用戶的類型，針?duì)用戶的情況可以劃分組別，詳細(xì)描述出其個(gè)性特點(diǎn)及任務(wù)情況。其次，就要選擇好每類的代表，對(duì)其進(jìn)行訪談和調(diào)研。每次的交流都需要有記錄，對(duì)于交流的結(jié)果還可以分類，以便于后續(xù)的分析活動(dòng)開展。

2．需求分析

調(diào)研人員對(duì)于收集的需求信息要做進(jìn)一步的分析和整理。這是一個(gè)需求分析人員消化用戶資料的過程。這個(gè)過程主要通過建立模型來描述用戶的需求，實(shí)際上是抽象圖形化的過程。一般用圖形表示系統(tǒng)的整體結(jié)構(gòu)，用原型等方式向用戶提供可視化的界面，用系統(tǒng)可性行分析來說明軟件的效果和效率，用UML描述系統(tǒng)的需求及內(nèi)部關(guān)系。

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

需求規(guī)格說明書也稱為功能規(guī)格說明、需求協(xié)議或系統(tǒng)規(guī)格說明，它精確地闡述一個(gè)軟件系統(tǒng)必須提供的功能和性能以及它所要考慮的限制條件。它是開發(fā)設(shè)計(jì)的藍(lán)本，也是系統(tǒng)測(cè)試和用戶文檔的依據(jù)。

4．需求驗(yàn)證

需求驗(yàn)證是為了確保需求說明書準(zhǔn)確無誤、完整地表達(dá)必要的質(zhì)量的一種方式?？蛻?、分析人員、設(shè)計(jì)人員、測(cè)試人員等利益相關(guān)人員經(jīng)過多次評(píng)審后的需求說明書就可作為需求管理的基線。用戶和開發(fā)方對(duì)軟件項(xiàng)目內(nèi)容的描述是以需求規(guī)格說明書作為基礎(chǔ)，它是軟件驗(yàn)收時(shí)合同雙方確認(rèn)的重要依據(jù)。

三、需求開發(fā)中存在的困難以及對(duì)策

1．需求獲取

問題一：用戶對(duì)于自己的需求不太清楚或工作繁忙無暇理清需求。第一種情況是，他們認(rèn)為計(jì)算機(jī)是萬能的，對(duì)于自己的業(yè)務(wù)規(guī)則、工作流程都不愿多談。針對(duì)這種情況，其對(duì)策是需求分析人員一定要深入用戶工作場(chǎng)地，仔細(xì)查看用戶的資料和報(bào)表，與不同層面的用戶交流，且要多了解用戶實(shí)際工作的場(chǎng)景。

還有一種情況就是業(yè)務(wù)人員配合力度不夠。他們不愿意付出更多的時(shí)間向分析人員講解業(yè)務(wù)。面對(duì)這種用戶，其對(duì)策是：需求分析人員改變溝通技巧，講清楚軟件需求的重要性，抓住關(guān)鍵點(diǎn)，向其咨詢，以用例和模型的方式向其演示，達(dá)到用戶和分析人員互相理解。

問題二：用戶與需求分析人員缺乏有效溝通，雙方誤解需求。軟件用戶與開發(fā)人員缺乏有效溝通方法，交流上存在障礙，用戶與開發(fā)人員存在知識(shí)背景差異，都從自己的角度，使用自己的專業(yè)術(shù)語或語言表達(dá)方式來描述和理解問題，使得雙方并不能夠很好地達(dá)成共識(shí)。一般說來，用戶不太容易從計(jì)算機(jī)的角度去理解自己的需求問題。從而使需求描述的不一致，不規(guī)范，多義性。

上述問題對(duì)策為，分析人員需要花更多的時(shí)間去了解系統(tǒng)用戶的特點(diǎn)，多學(xué)習(xí)用戶行業(yè)的專業(yè)術(shù)語，用用戶看得懂的語言來表達(dá)需求的內(nèi)容。其次，分析人員除了需要過硬的專業(yè)知識(shí)，還要具備較強(qiáng)的溝通能力。如果能在用戶方找到既對(duì)生產(chǎn)過程了解，又懂計(jì)算機(jī)知識(shí)的行家來為開發(fā)人員與用戶牽線架橋則是最好不過的事情。

問題三：用戶的需求不斷變更。隨著客戶對(duì)項(xiàng)目的理解越來越深刻，對(duì)過去提出的需求要求一變?cè)僮儭Ｃ鎸?duì)這種情況，需求人員要意識(shí)到：需求的變化是永恒的，需求不可能是完備的。因此在需求獲取的時(shí)候，一方面應(yīng)該跟用戶講清楚需求開發(fā)的重要性，讓用戶明白減少后期的需求變更的重要性，且隨意的需求變更帶來的風(fēng)險(xiǎn)（成本增加、進(jìn)度延后等）必將由用戶和開發(fā)者共同承擔(dān)。另一方面也需讓用戶明白，開發(fā)者和用戶更多的是戰(zhàn)略合作伙伴關(guān)系，其共同的目標(biāo)是開發(fā)出適合用戶需要的軟件。

2．需求分析

問題一：主次不分。需求分析人員常站在自身的角度去理解用戶的需求，造成主次不分。針對(duì)這種情況，首先需求分析人員可以借用當(dāng)前的需求分析工具和圖形的方式，明確用戶的功能需求和非功能需求，特別注意非功能性需求。其次就要充分考慮到哪些需求相對(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è)問題非常普通，不合理的要求會(huì)導(dǎo)致項(xiàng)目失敗。軟件項(xiàng)目有一個(gè)最短周期，也就是說無論如何增加資源，追趕進(jìn)度，都無法再縮短時(shí)間，在關(guān)鍵路徑上增加人力、物力資源，或許還會(huì)添亂。一般需求開發(fā)工作應(yīng)占全部工作量的15%。所以用戶方與開發(fā)方必須達(dá)成共識(shí)，留出足夠的時(shí)間進(jìn)行需求分析。

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

問題一：文檔混亂，文字表述過多。需求人員寫出的文檔混亂，圖形連線錯(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ù)可采用描述分類、格式化；企業(yè)商務(wù)規(guī)則與功能可以采用分類方法進(jìn)行。其次盡量采用SRS（需求規(guī)格說明書），較好的模板為IEEE標(biāo)準(zhǔn)830—1998描述的SRS模板。

4．需求論證

問題一：需求文檔口頭達(dá)到共識(shí)，缺乏文字依據(jù)。因?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ù)算有限的條件下完成的。在這些“先天不足”的條件下，首先就是關(guān)注需求分析。需求分析做好了，對(duì)下一步的設(shè)計(jì)階段工作真正起到指導(dǎo)性作用，規(guī)避需求開發(fā)過程存在的問題，成功的軟件項(xiàng)目指日可待。