軟件需求分析方法研究進(jìn)展

李 超，謝坤武

(1.湖北民族學(xué)院 科技學(xué)院,湖北 恩施 445000； 2.湖北民族學(xué)院 信息工程學(xué)院,湖北 恩施 445000)

軟件需求分析方法研究進(jìn)展

李 超1,2，謝坤武1*

(1.湖北民族學(xué)院 科技學(xué)院,湖北 恩施 445000； 2.湖北民族學(xué)院 信息工程學(xué)院,湖北 恩施 445000)

近年來(lái)軟件需求分析技術(shù)獲得了長(zhǎng)足的發(fā)展.需求分析是軟件定義期的最后階段,軟件系統(tǒng)的成功構(gòu)造極大地依賴(lài)軟件需求分析的質(zhì)量.不同的需求獲取技術(shù)、需求分析與建模方法和需求管理與控制手段,對(duì)于軟件的開(kāi)發(fā)與維護(hù)、軟件質(zhì)量和復(fù)用影響很大.對(duì)軟件需求的研究,具有重要的意義.本文系統(tǒng)地分析和總結(jié)了軟件需求的獲取方法、需求分析及建模技術(shù)、需求管理等內(nèi)容,指出了軟件需求研究發(fā)展的方向.

軟件工程；需求管理；需求分析

近年來(lái)軟件需求分析技術(shù)獲得了長(zhǎng)足的發(fā)展.需求分析是軟件定義期的最后階段,軟件系統(tǒng)的成功構(gòu)造極大地依賴(lài)于需求分析.軟件需求階段分為需求獲取、分析與建模、確認(rèn)等步驟,涉及權(quán)衡分析、質(zhì)量度量、風(fēng)險(xiǎn)評(píng)估、可行性評(píng)估、變更控制、缺陷分析及需求分析工具構(gòu)建等內(nèi)容.不同的需求獲取技術(shù)、分析與建模方法和需求管理與控制手段，對(duì)于軟件的開(kāi)發(fā)和維護(hù)以及軟件質(zhì)量、復(fù)用影響很大.對(duì)軟件需求的研究,具有重要的意義.本文系統(tǒng)地分析和總結(jié)了軟件需求的獲取方法、需求分析及建模技術(shù)、需求管理、需求的評(píng)審等內(nèi)容,最后指出了軟件需求研究發(fā)展的方向.

1 需求獲取方法

軟件需求[1-3]是指用戶(hù)對(duì)目標(biāo)軟件系統(tǒng)在功能、行為、性能、設(shè)計(jì)約束等方面的期望.需求分析是軟件定義期的最后階段,側(cè)重于系統(tǒng)必須做什么,涉及對(duì)應(yīng)用問(wèn)題及環(huán)境的理解與分析,為問(wèn)題所涉及的信息、功能、系統(tǒng)行為建模,將用戶(hù)需求精確化、完全化等一系列活動(dòng),最終形成需求規(guī)格說(shuō)明.

無(wú)論是特定系統(tǒng)還是軟件包的開(kāi)發(fā),都離不開(kāi)需求獲取.需求獲取是一個(gè)取得用戶(hù)對(duì)目標(biāo)軟件需求的過(guò)程,是一項(xiàng)困難的工作,它要求開(kāi)發(fā)人員應(yīng)具備相應(yīng)的領(lǐng)域知識(shí)，用戶(hù)提供相應(yīng)的材料及信息,最終結(jié)果能解決用戶(hù)面臨的問(wèn)題.本節(jié)先對(duì)常用的需求獲取方法作簡(jiǎn)要的介紹.

1)訪(fǎng)談與會(huì)議

分析人員一般以個(gè)別訪(fǎng)談或小組會(huì)議的形式與用戶(hù)進(jìn)行初步溝通.在訪(fǎng)談和會(huì)議前，分析人員精心準(zhǔn)備一系列問(wèn)題,通過(guò)用戶(hù)對(duì)問(wèn)題的回答獲取有關(guān)問(wèn)題及環(huán)境的知識(shí),逐步理解用戶(hù)的要求.訪(fǎng)談與會(huì)議過(guò)程中，所提問(wèn)題應(yīng)該循序漸進(jìn)，不限制用戶(hù)在回答過(guò)程中進(jìn)行發(fā)揮，組織問(wèn)題時(shí)應(yīng)客觀(guān)公正，提出的問(wèn)題匯總后應(yīng)能反映應(yīng)用問(wèn)題全貌,覆蓋用戶(hù)的要求.

2)觀(guān)察用戶(hù)工作流程、與用戶(hù)組成聯(lián)合小組

觀(guān)察用戶(hù)工作流程,可以獲得用戶(hù)與組織系統(tǒng)交互的第一手資料,對(duì)用戶(hù)所做事情及過(guò)程有一個(gè)準(zhǔn)確客觀(guān)的評(píng)價(jià).在其過(guò)程中，要將最好的經(jīng)濟(jì)效益、最快的處理速度、最合理的操作流程和最友好的用戶(hù)界面等作為軟件目標(biāo).分析人員要結(jié)合自己軟件開(kāi)發(fā)和應(yīng)用經(jīng)驗(yàn),主動(dòng)地指出不合理的用戶(hù)需求,從軟件角度改進(jìn)操作流程和規(guī)范,提出新的潛在的用戶(hù)需求.

分析人員和用戶(hù)以問(wèn)答和文檔方式進(jìn)行溝通，抑制了用戶(hù)在分析過(guò)程中的主動(dòng)精神,阻礙了協(xié)同工作,易導(dǎo)致誤解和遺漏.以“聯(lián)合小組”方式進(jìn)行需求，用戶(hù)也是需求分析人員,對(duì)分析工作負(fù)有與軟件開(kāi)發(fā)方相同的責(zé)任.20世紀(jì)70年代末出現(xiàn)的聯(lián)合應(yīng)用程序設(shè)計(jì)(JAD)方法,它實(shí)質(zhì)是對(duì)“聯(lián)合小組”方法的擴(kuò)展.主要思想是讓所用關(guān)鍵人員在同一時(shí)間處于同一地點(diǎn)以會(huì)議方式進(jìn)行,需求分析人員可以看到一致和有沖突的領(lǐng)域，從而從系統(tǒng)的主要用戶(hù)那兒同時(shí)收集系統(tǒng)需求,是一個(gè)緊張而且高度組織化但又非常有效的過(guò)程.

3)分析程序和其他文檔

由于訪(fǎng)談和觀(guān)察具有局限性,可以通過(guò)分析系統(tǒng)和組織的文檔來(lái)加強(qiáng),發(fā)現(xiàn)當(dāng)前系統(tǒng)及其支持組織的更多詳情.通過(guò)對(duì)組織任務(wù)聲明、業(yè)務(wù)規(guī)劃、業(yè)務(wù)表單、報(bào)表、組織結(jié)構(gòu)圖、經(jīng)營(yíng)方針指南、作業(yè)描述、內(nèi)部與外部函件和來(lái)自之前組織研究報(bào)告等文檔,可以獲取構(gòu)建新系統(tǒng)所關(guān)注的一些信息.

4)原型法、Demo版系統(tǒng)法

原型法是一個(gè)反復(fù)的過(guò)程,分析員和用戶(hù)根據(jù)用戶(hù)反饋構(gòu)建一個(gè)信息系統(tǒng)的初步版本.要為原型開(kāi)發(fā)確立需求,分析員仍然不得不訪(fǎng)問(wèn)用戶(hù)和收集文檔,原型開(kāi)發(fā)允許分析員很快地將基本需求轉(zhuǎn)換成所期望的信息系統(tǒng)的一個(gè)可運(yùn)行版本,之后檢查和測(cè)試這個(gè)原型，通過(guò)不斷地豐富逐漸實(shí)現(xiàn)目標(biāo)系統(tǒng).與原型法的不同，Demo版系統(tǒng)法是在已有項(xiàng)目基礎(chǔ)上進(jìn)行修改得出可運(yùn)行系統(tǒng),通過(guò)“可運(yùn)行原型系統(tǒng)”達(dá)到徹底挖掘項(xiàng)目需求.原型法需要構(gòu)造原型,而Demo版系統(tǒng)法已有相似的可運(yùn)行的系統(tǒng)基礎(chǔ).

5)問(wèn)卷調(diào)查

問(wèn)卷調(diào)查又稱(chēng)調(diào)查表或詢(xún)問(wèn)表,是以問(wèn)題形式系統(tǒng)地記載調(diào)查內(nèi)容的一種文件.設(shè)計(jì)問(wèn)卷是詢(xún)問(wèn)調(diào)查的關(guān)鍵.問(wèn)卷可以是表格式、卡片式或簿記式.問(wèn)卷須具備兩個(gè)功能,即能將問(wèn)題傳達(dá)給被問(wèn)的人和使被問(wèn)者樂(lè)于回答.

6)敏捷方法

敏捷方法強(qiáng)調(diào)對(duì)變化的快速響應(yīng),通過(guò)引入迭代式的開(kāi)發(fā)手段,較好的解決變化問(wèn)題. 敏捷方法的兩大主要特征便是對(duì)“適應(yīng)性”的強(qiáng)調(diào)與對(duì)“人”的關(guān)注.它將整個(gè)軟件生命周期分解為若干個(gè)小的迭代周期,通過(guò)在每個(gè)迭代周期結(jié)束時(shí)交付階段性成果來(lái)獲取切實(shí)有效的客戶(hù)反饋.其目的是希望通過(guò)建立及時(shí)的反饋機(jī)制,對(duì)需求變更做出調(diào)整,增強(qiáng)對(duì)軟件項(xiàng)目的控制能力.

7)基于知識(shí)的方法

基于知識(shí)的需求分析方法用軟件開(kāi)發(fā)者積累的經(jīng)驗(yàn)或領(lǐng)域分析的結(jié)果,來(lái)幫助軟件開(kāi)發(fā)者理解應(yīng)用和定義需求.比較典型如工作[4-6].它們都以企業(yè)信息系統(tǒng)為研究背景,試圖以企業(yè)本體和領(lǐng)域本體作為需求獲取過(guò)程的基本線(xiàn)索,引導(dǎo)領(lǐng)域用戶(hù)全面描述現(xiàn)實(shí)系統(tǒng),并通過(guò)重用領(lǐng)域模型來(lái)構(gòu)造應(yīng)用軟件的需求模型.該方法特點(diǎn)是通過(guò)深化領(lǐng)域知識(shí)使得需求獲取過(guò)程更系統(tǒng)更有效.目前還沒(méi)有系統(tǒng)性的研究成果出現(xiàn).

2 需求分析及建模方法

因需求分析對(duì)象的抽象粒度、關(guān)注點(diǎn)等因素不同而呈現(xiàn)出了如面向?qū)ο?、面向?shù)據(jù)、面向數(shù)據(jù)流、面向agent、用例驅(qū)動(dòng)、場(chǎng)景驅(qū)動(dòng)、基于多視點(diǎn)、面向方面、用戶(hù)驅(qū)動(dòng)、市場(chǎng)驅(qū)動(dòng)、基于本體等需求分析方法.它們各有利弊，下面分別進(jìn)行闡述.

1)面向?qū)ο笮枨蠓治?/p>

面向?qū)ο蠓椒ㄊ且环N運(yùn)用對(duì)象、類(lèi)、維承、封裝、聚合、消息傳遞、多態(tài)性等概念來(lái)構(gòu)造系統(tǒng)的軟件開(kāi)發(fā)方法.20世紀(jì)80年代,面向?qū)ο笏枷腴_(kāi)始滲透到軟件工程的前期階段,即在系統(tǒng)分析和設(shè)計(jì)階段就運(yùn)用面向?qū)ο笏枷?90年代,圖形化建模語(yǔ)言UML的出現(xiàn),被認(rèn)為是最重要的具有劃時(shí)代意義的重大成果之一.OOSD在一定程度上提高了開(kāi)發(fā)者的效率和控制復(fù)雜系統(tǒng)能力.OO方法強(qiáng)調(diào)從系統(tǒng)中抽象類(lèi)與對(duì)象,標(biāo)識(shí)它們之間的關(guān)系,即用自底向上方法構(gòu)造系統(tǒng)，但它沒(méi)有充分地描述這些類(lèi)與對(duì)象如何協(xié)作完成系統(tǒng)功能,難以從全局把握系統(tǒng).它強(qiáng)調(diào)對(duì)現(xiàn)實(shí)世界的客觀(guān)認(rèn)識(shí),力求與客觀(guān)一致,但缺乏主動(dòng)性,用此方法開(kāi)發(fā)出來(lái)的系統(tǒng)沒(méi)有自動(dòng)適應(yīng)現(xiàn)實(shí)世界的能力.

2)面向數(shù)據(jù)及面向數(shù)據(jù)流需求分析

以面向數(shù)據(jù)結(jié)構(gòu)的系統(tǒng)開(kāi)發(fā)方法(DSSD)和Jackson系統(tǒng)開(kāi)發(fā)方法為代表的面向數(shù)據(jù)的需求分析方法,以信息對(duì)象及其操作為核心,對(duì)復(fù)合信息對(duì)象按照層次結(jié)構(gòu)進(jìn)行分解并映射為程序結(jié)構(gòu). Warnier提出的DSSD方法利用順序、選擇和循環(huán)結(jié)構(gòu)表示信息的層次分解,利用信息層次結(jié)構(gòu)推導(dǎo)出程序結(jié)構(gòu).后來(lái),Ken Orr對(duì)他的工作進(jìn)行了擴(kuò)充,引入了數(shù)據(jù)流和處理功能,從而發(fā)展成為一種需求分析方法.20世紀(jì)80年代,Jackson提出了軟件工程領(lǐng)域中著名的Jackson方法,最初只用于設(shè)計(jì),后來(lái)不斷進(jìn)行擴(kuò)充和完善,成為了一種需求分析方法.

面向數(shù)據(jù)流的分析方法屬于結(jié)構(gòu)化分析方法,具有鮮明的結(jié)構(gòu)化特征.1979年DeMarco將結(jié)構(gòu)化分析方法作為一種需求分析方法正式提出,此后它得到了迅速發(fā)展和廣泛的應(yīng)用.后來(lái)Ward&Mellor和Hatley&Pirbhai在結(jié)構(gòu)化分析中引入了實(shí)時(shí)系統(tǒng)分析機(jī)制,Harel研制了面向復(fù)雜實(shí)時(shí)反應(yīng)式系統(tǒng)的開(kāi)發(fā)環(huán)境STATEMATE[7]等,這些是對(duì)傳統(tǒng)結(jié)構(gòu)化分析方法的擴(kuò)充.

結(jié)構(gòu)化方法的思想基礎(chǔ)是認(rèn)為任何系統(tǒng)在建立之前都能被充分理解,開(kāi)發(fā)人員和用戶(hù)在系統(tǒng)開(kāi)發(fā)初期對(duì)系統(tǒng)功能有全面的認(rèn)識(shí),并制定出詳細(xì)計(jì)劃和說(shuō)明書(shū)規(guī)范后期各項(xiàng)工作.它著眼于處理方法和過(guò)程，分離數(shù)據(jù)結(jié)構(gòu)和處理方式,用過(guò)程抽象方式來(lái)應(yīng)付系統(tǒng)的要求.系統(tǒng)其結(jié)構(gòu)具有穩(wěn)定性,行為具有易變性,而結(jié)構(gòu)化方法把基點(diǎn)放在功能行為上,難以適應(yīng)系統(tǒng)的變化.結(jié)構(gòu)化方法主要由數(shù)據(jù)流程圖及控制結(jié)構(gòu)圖等圖表工具來(lái)描述,一般只能表達(dá)順序流程和平面結(jié)構(gòu),且不精確,無(wú)法全面描述信息系統(tǒng)模型.從某種意義上來(lái)說(shuō),結(jié)構(gòu)化方法是強(qiáng)調(diào)從開(kāi)發(fā)人員而不是用戶(hù)的角度來(lái)思考要實(shí)現(xiàn)的信息系統(tǒng).

3)面向Agent需求分析

傳統(tǒng)的軟件需求分析與設(shè)計(jì),著重對(duì)系統(tǒng)功能的理解、表達(dá)及具體實(shí)現(xiàn),無(wú)法把握系統(tǒng)的總體結(jié)構(gòu)和實(shí)體組成.隨著Agent技術(shù)的發(fā)展,面向Agent軟件工程(AOSE)已經(jīng)成為Agent技術(shù)研究中一個(gè)非?；钴S的領(lǐng)域.因智能Agent具有反應(yīng)性、自主性、合作性和知識(shí)級(jí)的通信能力,軟件開(kāi)發(fā)者可利用Agent更自然地去開(kāi)發(fā)復(fù)雜系統(tǒng),從而實(shí)現(xiàn)實(shí)體抽象.基于Agent的需求分析建模是面向?qū)嶓w的,能從根本上隔離需求分析和實(shí)際的軟件實(shí)現(xiàn),在脫離軟件具體實(shí)現(xiàn)約束的情況下得到更全面更抽象的需求域信息處理模型,從而綜合體現(xiàn)系統(tǒng)結(jié)構(gòu)、實(shí)體行為和系統(tǒng)功能.這樣的模型更接近實(shí)際組織，易于理解,同時(shí)具有很強(qiáng)的適應(yīng)性,當(dāng)實(shí)際的操作流程改動(dòng)時(shí)能方便快速地對(duì)模型進(jìn)行修改.

隨著對(duì)Agent技術(shù)研究的不斷深入,各種基于Agent的需求分析方法及建模工具逐漸涌現(xiàn)出來(lái),如純Gaia[8]方法、AUML[9]、KAOS[10]等，在多個(gè)大型項(xiàng)目中應(yīng)用并取得了良好的效果.

4)用例驅(qū)動(dòng)需求分析

用例驅(qū)動(dòng)[11-13]的需求分析方法目前得到了廣泛的應(yīng)用.用例圖被認(rèn)為是獲取、描述需求較好的策略[14]，捕獲需求一個(gè)比較流行的方法是基于用例[15].用例和用例驅(qū)動(dòng)的開(kāi)發(fā)一經(jīng)Jacobson首次提出，就被成功應(yīng)用到許多項(xiàng)目里面，已成為捕獲關(guān)注點(diǎn)的一個(gè)標(biāo)準(zhǔn)方法[16].在UML中,Use Case圖用來(lái)表示參與者、用例、用例與用例、用例與參與者間關(guān)系的圖.參與者(Actor)定義了與系統(tǒng)進(jìn)行交互的實(shí)體角色的抽象.參與者可以是人,也可以是應(yīng)用系統(tǒng),它與系統(tǒng)中特定的角色進(jìn)行關(guān)聯(lián).用例表示系統(tǒng)某些功能,用例間關(guān)系涉及關(guān)聯(lián)、泛化、擴(kuò)展、集合和組合等.用例驅(qū)動(dòng)的分析，是從行為者的角度出發(fā)建立用例，在復(fù)雜的需求分析中起到了巨大的作用[11]，使軟件的開(kāi)發(fā)從以代碼為中心轉(zhuǎn)為以用例為中心.

對(duì)用例進(jìn)行描述可以使用自然語(yǔ)言、結(jié)構(gòu)化以及形式化技術(shù).使用自然語(yǔ)言進(jìn)行描述,分析人員和領(lǐng)域?qū)＜冶阌谶M(jìn)行溝通,但也增加了模糊性、不一致性和不完整性[17].為此如Leite等[18]用表來(lái)描述用例,Hsia[19]和Glinz[20]等用到了語(yǔ)法和狀態(tài)圖等形式化(形式化方法優(yōu)缺點(diǎn)具體見(jiàn)后面小節(jié))來(lái)描述用例.但采用用例方法也存在很多問(wèn)題，如不能從更深層次來(lái)理解要開(kāi)發(fā)的系統(tǒng)在功能和非功能外的特征,如依賴(lài)性、并發(fā)性和反應(yīng)時(shí)間等.

5)場(chǎng)景驅(qū)動(dòng)需求分析

為了彌補(bǔ)基于用例方法在非功能描述方面的不足，出現(xiàn)了基于場(chǎng)景的需求分析.如Saiedian等[21]基于場(chǎng)景模型來(lái)分析實(shí)時(shí)軟件系統(tǒng)及關(guān)鍵的系統(tǒng)需求，很好地反映了系統(tǒng)依賴(lài)性、并發(fā)性、反應(yīng)時(shí)間等特征.由于情景實(shí)例的采集是隨機(jī)的,不能保證某組情景實(shí)例能覆蓋整個(gè)現(xiàn)實(shí)系統(tǒng)和產(chǎn)生完全的需求.

6)基于多視點(diǎn)(觀(guān)點(diǎn))需求分析

大型復(fù)雜軟件系統(tǒng)的開(kāi)發(fā),往往涉及到眾多的來(lái)自不同背景、具有不同知識(shí)和職責(zé)的項(xiàng)目人員,他們對(duì)待系統(tǒng)的看法和要求不盡相同.為了在系統(tǒng)開(kāi)發(fā)的早期全面獲取項(xiàng)目相關(guān)人員的需求信息,確保開(kāi)發(fā)要求的全面性,上世紀(jì)90年代,提出了面向多視點(diǎn)的需求工程方法[22-23].采用視點(diǎn)的形式分散、獨(dú)立地獲取和表示項(xiàng)目相關(guān)人員的需求，最終將與各視點(diǎn)對(duì)應(yīng)部分的規(guī)格說(shuō)明集成為一個(gè)統(tǒng)一整體,生成完整的規(guī)格說(shuō)明書(shū).目前,在視點(diǎn)定義及抽取[24-25]、視點(diǎn)表示[26-27]、視點(diǎn)一致性[28-29]、視點(diǎn)間沖突處理[30-31]、視點(diǎn)集成[32-34]等方面已有較廣泛和深入的研究.

7)面向方面需求分析

由于需求變化性及軟件本身性能要求等因素,面向?qū)ο蟪绦蛟O(shè)計(jì)不能很好地解決橫切關(guān)注點(diǎn)的有效分離,造成代碼分散、混亂和難以維護(hù)[35].面向方面程序設(shè)計(jì)使用Aspect的概念解決了橫切關(guān)注點(diǎn)的有效分離和局部化,提供了一系列方法來(lái)系統(tǒng)性地界定、分離、實(shí)現(xiàn)、組合橫切關(guān)注點(diǎn),更好地處理橫切關(guān)注點(diǎn).在需求分析階段即采用面向方面方法,更早地分離捕捉到橫切關(guān)注點(diǎn),以降低需求分析到設(shè)計(jì)直接映射的難度,從而建立更好的模塊結(jié)構(gòu),降低后期重構(gòu)升級(jí)維護(hù)成本.

8)目標(biāo)驅(qū)動(dòng)需求分析

許多需求分析方法把需求看成是過(guò)程、數(shù)據(jù)或?qū)嶓w,系統(tǒng)和環(huán)境的關(guān)系用活動(dòng)和實(shí)體來(lái)表達(dá)，在澄清需求,處理需求變更與需求驗(yàn)證,跟蹤需求背后的決策依據(jù)等方面都存在許多不足. KAOS方法[36]認(rèn)為,分析用戶(hù)需求的最有效的方法應(yīng)該從整個(gè)系統(tǒng)的實(shí)現(xiàn)目標(biāo)開(kāi)始,逐步分解目標(biāo)直到其責(zé)任能夠被分配到構(gòu)成系統(tǒng)的基本組件單元中,最終完成設(shè)計(jì)目標(biāo).基于目標(biāo)的分析方法,是把需求與組織和業(yè)務(wù)環(huán)境聯(lián)系起來(lái),方便沖突處理,驅(qū)動(dòng)后續(xù)設(shè)計(jì)過(guò)程,實(shí)現(xiàn)需求復(fù)用.在目標(biāo)驅(qū)動(dòng)的需求分析過(guò)程中涉及目標(biāo)求精問(wèn)題.目標(biāo)求精是通過(guò)目標(biāo)求精樹(shù)中的部分目標(biāo)推導(dǎo)完整的目標(biāo)求精樹(shù)的過(guò)程,目前目標(biāo)求精主要涉及形式化[37]和非形式化方法[38].如李勇華[39]等提出了謂詞驅(qū)動(dòng)的目標(biāo)求精方法,通過(guò)對(duì)目標(biāo)謂詞描述的分類(lèi)來(lái)指導(dǎo)整個(gè)求精過(guò)程的進(jìn)行.同傳統(tǒng)的求精方法相比,該方法具有對(duì)需求分析員的依賴(lài)較小、自動(dòng)化程度高等優(yōu)點(diǎn).

9)用戶(hù)主導(dǎo)、市場(chǎng)驅(qū)動(dòng)、產(chǎn)品線(xiàn)需求分析

受知識(shí)背景、資源和經(jīng)驗(yàn)等方面因素的限制,軟件開(kāi)發(fā)人員往往難以充分理解用戶(hù)的問(wèn)題空間,交流困難[40].用戶(hù)通常對(duì)問(wèn)題僅具有模糊、局部的認(rèn)識(shí)和理解,難以系統(tǒng)、全面地表達(dá)出自己需求,并且通常對(duì)于軟件開(kāi)發(fā)領(lǐng)域知之甚少，按照傳統(tǒng)的軟件工程方法和技術(shù)難以從用戶(hù)處獲得正確的需求.對(duì)于涉及領(lǐng)域知識(shí)性強(qiáng)、角色多且結(jié)構(gòu)復(fù)雜的系統(tǒng),讓用戶(hù)在需求過(guò)程中發(fā)揮主導(dǎo)作用是解決該問(wèn)題的一個(gè)很直接的辦法[41].事實(shí)上,用戶(hù)的參與程度對(duì)于項(xiàng)目成敗的重要影響已得到公認(rèn)[42-43].

市場(chǎng)驅(qū)動(dòng)的需求分析主要是為了在軟件包的基礎(chǔ)上,孕育發(fā)展新的需求以確保其產(chǎn)品的競(jìng)爭(zhēng)力,它強(qiáng)調(diào)需求的連續(xù)性、重要性以及專(zhuān)家對(duì)開(kāi)銷(xiāo)的評(píng)估,在此基礎(chǔ)上實(shí)現(xiàn)軟件發(fā)布計(jì)劃.軟件包通常也就是集成的構(gòu)件.常見(jiàn)的特定軟件不同,項(xiàng)目用戶(hù)定義明確,開(kāi)發(fā)方和客戶(hù)間的需求以需求規(guī)格說(shuō)明的方式形成合同, 而軟件包的開(kāi)發(fā)面向市場(chǎng),要求能夠預(yù)見(jiàn)終端用戶(hù)的需求,在其基礎(chǔ)上選擇特定的需求集,實(shí)現(xiàn)具有競(jìng)爭(zhēng)力的軟件產(chǎn)品.

軟件產(chǎn)品線(xiàn)方法[44]是軟件體系結(jié)構(gòu)和軟件復(fù)用技術(shù)發(fā)展的結(jié)果,集中體現(xiàn)了一種大規(guī)模、大粒度的軟件復(fù)用實(shí)踐.在軟件產(chǎn)品線(xiàn)的開(kāi)發(fā)過(guò)程中,軟件產(chǎn)品線(xiàn)的需求分析占據(jù)重要的作用.產(chǎn)品線(xiàn)的需求分析是分析整個(gè)產(chǎn)品線(xiàn)的需求,其中包括共性需求和變化需求，需求分析過(guò)程涉及領(lǐng)域需求分析和特定產(chǎn)品的需求. 領(lǐng)域需求分析是對(duì)領(lǐng)域內(nèi)需求進(jìn)行獲取、分類(lèi)以及分析的過(guò)程,反映的是領(lǐng)域中多數(shù)用戶(hù)對(duì)各系統(tǒng)的需求.產(chǎn)品線(xiàn)需求定義了產(chǎn)品線(xiàn)中的產(chǎn)品及其特性,涵蓋了整個(gè)系列的共同特性,是產(chǎn)品線(xiàn)重要的核心資產(chǎn).根據(jù)STARTS[45]軟件產(chǎn)品線(xiàn)的雙生命周期模型,產(chǎn)品線(xiàn)需求分析過(guò)程也分為領(lǐng)域工程中的領(lǐng)域需求分析和應(yīng)用工程中的產(chǎn)品需求分析兩個(gè)過(guò)程.

10)形式化方法需求分析

形式化方法是一種用于規(guī)范、設(shè)計(jì)和驗(yàn)證計(jì)算機(jī)系統(tǒng)的基于數(shù)學(xué)的方法,它包括各種語(yǔ)言、技術(shù)和工具等. 形式化方法有助于發(fā)現(xiàn)需求中隱含的不一致性、二義性和不完整性,能對(duì)其進(jìn)行更深入精確的理解和規(guī)范化管理,并為軟件生產(chǎn)自動(dòng)化奠定基礎(chǔ),能對(duì)目標(biāo)系統(tǒng)和規(guī)格說(shuō)明等價(jià)性進(jìn)行有效證明.當(dāng)前用于需求分析的形式化方法及語(yǔ)言主要有B方法[46]、Z語(yǔ)言[47]、VDM以及Petri網(wǎng)[48]等.

除了上面所給出的需求分析方法外，還存在許多需求分析方法，如基于本體、領(lǐng)域本體的需求分析方法等.

11)需求建模工具的比較

當(dāng)前常用的需求分析及建模工具有Rational Rose、Microsoft Visio、Sybase Power Designer，Sparx Systems Enterprise Architect，Borland Together等.關(guān)于這幾個(gè)工具在繪圖功能、數(shù)據(jù)集成、文檔自動(dòng)化、雙向工程、穩(wěn)定性、效率、易用性及價(jià)格方面的特點(diǎn)可以參考文獻(xiàn)[49]及各公司發(fā)布的相應(yīng)信息.

3 軟件需求管理與控制

軟件需求不斷地變更是軟件開(kāi)發(fā)困難的根源之一，需求的管理貫穿于整個(gè)軟件開(kāi)發(fā)周期中.軟件的需求管理與控制涉及質(zhì)量度量與控制、復(fù)雜性度量、有效性度量、優(yōu)先級(jí)劃分、風(fēng)險(xiǎn)性分析、依賴(lài)性分析、需求缺陷管理及管理工具.

1)需求質(zhì)量度量與控制

軟件系統(tǒng)的成功極大地依賴(lài)軟件需求分析的質(zhì)量.軟件需求的質(zhì)量度量主要是針對(duì)軟件需求規(guī)格說(shuō)明(SRS)的度量.文獻(xiàn)[50-51]給出了質(zhì)量度量指標(biāo),甘早斌等[52]基于此借助于模糊數(shù)學(xué)的基本理論，在分析SRS及其質(zhì)量特性的基礎(chǔ)上，提出了軟件需求的質(zhì)量度量指標(biāo)體系，并討論了有關(guān)數(shù)據(jù)的獲取以及模糊綜合評(píng)價(jià)方法.

2)需求復(fù)雜度性及有效性度量

軟件需求(空間)的復(fù)雜度直接決定著軟件的復(fù)雜度.需求的復(fù)雜度與需求條目多少、需求的領(lǐng)域性、需求的獲取及表示環(huán)境、工具緊密相關(guān)以及相關(guān)人員的知識(shí)背景相關(guān).由于軟件需求具有模糊性、不確定性、變化性和主觀(guān)性，軟件需求復(fù)雜性和有效性的度量當(dāng)前比較困難，相應(yīng)成果較少.

3)需求優(yōu)先級(jí)劃分

需求優(yōu)先級(jí)的確定對(duì)于項(xiàng)目進(jìn)度甚至成功與否的影響很大，需求優(yōu)先級(jí)排序需要考慮多種因素,如用戶(hù)核心業(yè)務(wù)的價(jià)值、需求之間的依賴(lài)關(guān)系、開(kāi)發(fā)團(tuán)隊(duì)可用資源、開(kāi)發(fā)者和用戶(hù)對(duì)系統(tǒng)目標(biāo)和限制的理解程度、環(huán)境的演化等諸多因素都會(huì)影響到需求優(yōu)先級(jí)的劃分，這使得在迭代開(kāi)發(fā)過(guò)程中需求優(yōu)先級(jí)排序變得非常復(fù)雜.黃[53]等提出了一種風(fēng)險(xiǎn)驅(qū)動(dòng)的需求優(yōu)先級(jí)自適應(yīng)排序方法，將自適應(yīng)計(jì)劃方法學(xué)與風(fēng)險(xiǎn)驅(qū)動(dòng)相結(jié)合,將風(fēng)險(xiǎn)作為排序決策的依據(jù),以自適應(yīng)的過(guò)程為迭代開(kāi)發(fā)排序需求優(yōu)先級(jí)，增強(qiáng)了迭代開(kāi)發(fā)中對(duì)需求的控制,降低了項(xiàng)目失敗可能性.

4)需求依賴(lài)性分析

依賴(lài)性對(duì)于系統(tǒng)的最終實(shí)現(xiàn)起著非常重要的作用，需求之間往往存在著各種類(lèi)型的關(guān)聯(lián)和依賴(lài).Robinson[54]和Van Lamsweerde等[55]針對(duì)需求分析階段消除消極依賴(lài)性工作方面做了大量研究, Carlshamre等[56]對(duì)依靠需求依賴(lài)性來(lái)制定軟件產(chǎn)品的發(fā)布計(jì)劃作了一個(gè)工業(yè)調(diào)查.Giesen和Volker[57]深究了需求的依賴(lài)性如何能幫忙滿(mǎn)足風(fēng)險(xiǎn)投資者個(gè)人偏好的問(wèn)題.Von Knethen等[58-59]展示了基于需求依賴(lài)性來(lái)實(shí)現(xiàn)需求復(fù)用和改變需求的方法.Wei Zhang等[60]在部分基于觀(guān)察特征運(yùn)轉(zhuǎn)和責(zé)任分配基礎(chǔ)上,提出了特征間多種依賴(lài)類(lèi)型.

5)需求風(fēng)險(xiǎn)評(píng)估

軟件開(kāi)發(fā)存在著多種風(fēng)險(xiǎn),其中需求分析風(fēng)險(xiǎn)(RAR)是最重要的,如果不加以足夠的重視就可能達(dá)不到預(yù)期要求,甚至導(dǎo)致項(xiàng)目開(kāi)發(fā)失敗[61].因此,對(duì)于項(xiàng)目開(kāi)發(fā)中的RAR必須作出合理評(píng)估.傳統(tǒng)評(píng)估方法如層次分析法、領(lǐng)域?qū)＜掖蚍址?、模糊?shù)學(xué)法等都是針對(duì)整個(gè)項(xiàng)目進(jìn)行風(fēng)險(xiǎn)評(píng)估,主要靠專(zhuān)家根據(jù)經(jīng)驗(yàn)和歷史數(shù)據(jù)來(lái)分析識(shí)別,主觀(guān)因素較大，數(shù)據(jù)需要人工整理,容易出錯(cuò)，不適合RAR的客觀(guān)分析.針對(duì)此問(wèn)題文獻(xiàn)[61]提出基于支持向量機(jī)(SVM)的需求分析風(fēng)險(xiǎn)評(píng)估模型,定義了13種風(fēng)險(xiǎn)指標(biāo),然后對(duì)各個(gè)風(fēng)險(xiǎn)指標(biāo)采用多位專(zhuān)家按量化標(biāo)準(zhǔn)打分再統(tǒng)計(jì)分析方法,并把這些指標(biāo)轉(zhuǎn)換為向量作為SVM訓(xùn)練樣本,以建立RAR評(píng)估模型,并對(duì)RAR進(jìn)行了科學(xué)預(yù)測(cè).作者通過(guò)模擬試驗(yàn)論證了其方法的可行性.

6)需求缺陷分析與管理

Kamata[62]指出,40%-60%的軟件缺陷都由需求缺陷引起.缺陷修正越早,付出的代價(jià)就越小，在軟件開(kāi)發(fā)后期才修正缺陷比起在需求階段修正,代價(jià)可能要高上百倍[63].文獻(xiàn)[64]從社會(huì)因素和技術(shù)因素兩大方面分析了需求工程階段缺陷產(chǎn)生的原因,對(duì)缺陷進(jìn)行了分類(lèi).建立了需求(模型)缺陷列表、缺陷需求分析模型和基于需求缺陷管理的需求過(guò)程模型.

7)需求管理工具的比較

限于篇幅僅對(duì)需求管理工具Telelogic DOORS，Ratioanl RequisitePro 和Borland CaliberRM作一個(gè)簡(jiǎn)單的對(duì)比分析.

表1 需求管理工具的比較

4 需求的評(píng)審

需求分析以系統(tǒng)規(guī)格說(shuō)明和項(xiàng)目規(guī)劃作為分析活動(dòng)的基本出發(fā)點(diǎn),需求規(guī)格說(shuō)明是軟件設(shè)計(jì)、實(shí)現(xiàn)、測(cè)試直至維護(hù)的主要基礎(chǔ).良好的分析活動(dòng)有助于避免或盡早剔除早期錯(cuò)誤,從而提高軟件生產(chǎn)率、降低開(kāi)發(fā)成本、改進(jìn)軟件質(zhì)量.目前，需求的評(píng)審及驗(yàn)證除了人工方法外，往往借助一定的工具實(shí)現(xiàn).具有代表性的工具如QuARS[65]、ARMm[66]和Sytwo[67]等.

5 軟件需求研究的趨勢(shì)

近年來(lái)軟件需求分析技術(shù)獲得了長(zhǎng)足的發(fā)展.軟件需求獲取方法、分析及建模技術(shù)以及面向?qū)ο蟮墓ぞ咂脚_(tái)比較成熟，但在需求優(yōu)先級(jí)的確定，基于需求的軟件規(guī)模度量，需求的質(zhì)量度量方法及度量工具的開(kāi)發(fā)，需求描述工具，需求到設(shè)計(jì)再到軟件的實(shí)現(xiàn)平臺(tái)的研究，需求的重用特別是特定領(lǐng)域需求的重用，需求粒度，需求協(xié)同分析等許多方面將有許多工作要做.

總結(jié)語(yǔ) 不同的需求獲取技術(shù)、分析與建模方法和需求需要管理與控制,對(duì)于軟件的開(kāi)發(fā)、維護(hù)以及軟件質(zhì)量、復(fù)用影響很大.對(duì)軟件需求的研究,具有重要的意義.本文系統(tǒng)地分析和總結(jié)了軟件需求的獲取方法、需求分析及建模技術(shù)、需求管理與控制等內(nèi)容,同時(shí)指出了軟件需求分析方面要作的工作.

[1] 齊治昌,譚慶平,寧洪,等.軟件工程[M].北京：機(jī)械工業(yè)出版社,2004.

[2] 龔曉慶,張遠(yuǎn)軍,陳峰,等. 面向?qū)ο笙到y(tǒng)分析與設(shè)計(jì)[M].北京：清華大學(xué)出版社,2008.

[3] 劉偉琴,劉洪濤.軟件需求[M].北京：清華大學(xué)出版社,2009.

[4] Sutcliffe A,Maiden N.The domain theory for requirements engineering[J]. Software Engineering, IEEE Transactions on,1998,24(3):174-196.

[5] Dardenne A,Van Lamsweerde A,Fickas S.Goal-directed requirements acquisition[J]. Science of computer programming,1993,20(1):3-50.

[6] 金芝. 基于本體的需求自動(dòng)獲取[J].計(jì)算機(jī)學(xué)報(bào),2000,23(5):486-492.

[7] Harel D, Lachover H, Naamad A, et al. Statemate: A working environment for the development of complex reactive systems[J]. Software Engineering, IEEE Transactions on, 1990, 16(4): 403-414.

[8] Jennings N R. Agent-oriented software engineering[M].Multi-Agent System Engineering[J].Springer Berlin Heidelberg,1999:1-7.

[9] Parunak V, Bauer B, Bradshaw J M, et al. Suggested UML Extensions for Agents [J].Intellicorp OMG Document,1999,3(2):1-15.

[10] Letier E. Reasoning about agents in goal-oriented requirements engineering[D]. Université catholique de Louvain, 2001.

[11] Regnell B, Kimbler K, Wesslén A. Improving the use case driven approach to requirements engineering[C]//Requirements Engineering,1995,Proceedings of the Second IEEE International Symposium on. IEEE,1995:40-47.

[12] 劉慶海，周?chē)?guó)新，唐旭，等.城鎮(zhèn)宗地地介評(píng)估信息系統(tǒng)的研究與實(shí)現(xiàn)[J].湖北民族學(xué)院學(xué)報(bào)：自然科學(xué)版，2010，28(1)：98-104.

[13] Dano B, Briand H, Barbier F. A use case driven requirements engineering process[J]. Requirements Engineering, 1997, 2(2): 79-91.

[14] Cockburn A. Writing effective use cases[M]. Reading: Addison-Wesley, 2001.

[15] Regnell B, Kimbler K, Wesslén A. Improving the use case driven approach to requirements engineering[C]//Requirements Engineering,1995,Proceedings of the Second IEEE International Symposium on. IEEE,1995:40-47.

[16] Jacobson I, Ng P W. Aspect-Oriented Software Development with Use Cases (Addison-Wesley Object Technology Series)[M]. Addison-Wesley Professional, 2004.

[17] Kulak D, Guiney E. Use cases: requirements in context[M]. Addison-Wesley Professional, 2004.

[18] Leite J C S P, Rossi G, Balaguer F, et al. Enhancing a requirements baseline with scenarios[C]//Requirements Engineering,1997,Proceedings of the Third IEEE International Symposium on. IEEE,1997:44-53.

[19] Hsia P, Samuel J, Gao J, et al. Formal approach to scenario analysis[J]. Software, IEEE, 1994, 11(2): 33-41.

[20] Glinz M. An integrated formal model of scenarios based on statecharts[M]//Software Engineering—ESEC'95. Springer Berlin Heidelberg, 1995: 254-271.

[21] Saiedian H, Kumarakulasingam P, Anan M. Scenario-based requirements analysis techniques for real-time software systems: a comparative evaluation[J]. Requirements Engineering, 2005, 10(1): 22-33.

[22] Kotonya G, Sommerville I. Requirements engineering with viewpoints[J]. Software Engineering Journal,1996,11(1):5-18.

[23] Finkelstein A, Sommerville I. The viewpoints FAQ[J]. BCS/IEE Software Engineering Journal,1996,11(1):2-4.

[24] Kaiya H, Saeki M. Weaving multiple viewpoint specifications in goal oriented requirements analysis[C]//Software Engineering Conference, 2004. 11th Asia-Pacific. IEEE, 2004: 418-427.

[25] Aoyama K, Ugai T, Yamada S, et al. Extraction of viewpoints for eliciting customer's requirements based on analysis of specification change records[C]//Software Engineering Conference,2007.APSEC 2007. 14th Asia-Pacific,IEEE,2007:33-40.

[26] Silva A. Requirements, domain and specifications: a viewpoint-based approach to requirements engineering[C]//Proceedings of the 24th International Conference on Software Engineering. ACM, 2002: 94-104.

[27] 梁正平,毋國(guó)慶,王志強(qiáng).一種基于問(wèn)題框架的視點(diǎn)表示模型[J].計(jì)算機(jī)工程,2007,33(15):67-69

[28] Nentwich C, Emmerich W, Finkelstein A, et al. Flexible consistency checking[J]. ACM Transactions on Software Engineering and Methodology (TOSEM), 2003, 12(1): 28-63.

[29] Bernon C, Gleizes M P, Peyruqueou S, et al. Adelfe: A methodology for adaptive multi-agent systems engineering[M]//Engineering Societies in the Agents World III. Springer Berlin Heidelberg, 2003: 156-169.

[30] Nuseibeh B, Kramer J, Finkelstein A. ViewPoints: meaningful relationships are difficult![C]//Software Engineering, 2003. Proceedings. 25th International Conference on. IEEE, 2003: 676-681.

[31] 江敏,毋國(guó)慶.多視點(diǎn)間不一致性的認(rèn)知推理[J].小型微型計(jì)算機(jī)系統(tǒng),2007,28(2):322-327

[32] Sommerville I, Sawyer P. Requirements engineering: a good practice guide[M].John Wiley & Sons,Inc,1997.

[33] 牟克典,金芝,陸汝鈐.視點(diǎn)合成中重疊需求的不一致優(yōu)先級(jí)處理[J].計(jì)算機(jī)學(xué)報(bào),2004,27(10):1379-1387.

[34] 梁正平,明仲,毋國(guó)慶. 多視點(diǎn)需求工程中視點(diǎn)集成過(guò)程的研究[J].計(jì)算機(jī)科學(xué),2009,36(8):138-144.

[35] 方義秋,冉華鋒,葛君偉.基于用例的面向方面需求建模[J].計(jì)算機(jī)工程，2009,35(12)：44-46.

[36] Van Lamsweerde A, Willemet L. Inferring declarative requirements specifications from operational scenarios[J]. Software Engineering, IEEE Transactions on, 1998, 24(12): 1089-1114.

[37] Dardenne A, Van Lamsweerde A, Fickas S. Goal-directed requirements acquisition[J]. Science of computer programming, 1993, 20(1): 3-50.

[38] Sutcliffe A. Scenario-based requirements engineering[C]//Requirements engineering conference, 2003. Proceedings. 11th IEEE international. IEEE, 2003: 320-329.

[39] 李勇華,王鋒,毋國(guó)慶.一種謂詞驅(qū)動(dòng)的目標(biāo)求精方法[J].計(jì)算機(jī)工程,2007，33(2l):58-60.

[40] 舒風(fēng)笛,趙玉柱.個(gè)性化領(lǐng)域知識(shí)支持的用戶(hù)主導(dǎo)需求獲取方法[J].計(jì)算機(jī)研究與發(fā)展，2007,44(6)：1044-1052.

[41] Ming-shu L. A new methodology for user-driven domain-specific application software development[J].Journal of Software, 2000, 11(7): 863-870.

[42] Johnson J, Boucher K D, Connors K, et al. Collaborating on project success[J]. Software Magazine,2001, 7(2): 15.

[43] Kujala S, Kauppinen M, Lehtola L, et al. The role of user involvement in requirements quality and project success[C]//Requirements Engineering, 2005. Proceedings. 13th IEEE International Conference on. IEEE, 2005: 75-84.

[44] 江瑜. 基于軟件產(chǎn)品線(xiàn)的需求分析研究[J].計(jì)算機(jī)工程與設(shè)計(jì)，2007,28(8):1778-1780.

[45] 崔巍,曾廣周.面向組件的軟件需求協(xié)同分析研究[J].山東師范大學(xué)學(xué)報(bào)，2002,17(3):19-22.

[46] Cansell D, Méry D. Foundations of the B method[J].Computing and informatics, 2012,22(3/4):221-256.

[47] Potter B, Till D, Sinclair J. An introduction to formal specification and Z[M].Prentice Hall PTR,1996.

[48] 孫未來(lái),白雪峰.Z和VDM規(guī)格說(shuō)明的差異比較,計(jì)算機(jī)科學(xué),1997,24(4)：74-79.

[49] 吳偉敏,UML建模工具的比較- ROSE,Visio和PowerDesigner[J].現(xiàn)代計(jì)算機(jī),2003(6):1-6.

[50] Leffingwell D, Widrig D. Managing software requirements: a unified approach[M].Addison-Wesley Professional,2000.

[51] Nuseibeh B, Easterbrook S. Requirements engineering: a roadmap[C]//Proceedings of the Conference on the Future of Software Engineering. ACM, 2000: 35-46.

[52] 甘早斌,陳正勇.SRS及其質(zhì)量模糊度量方法的研究[J].計(jì)算機(jī)科學(xué),2003,30(4):131-133.

[53] 黃蒙,舒風(fēng)笛,李明.一種風(fēng)險(xiǎn)驅(qū)動(dòng)的迭代開(kāi)發(fā)需求優(yōu)先級(jí)排序方法報(bào)[J].軟件學(xué)，2006,17(12):2450-2460

[54] Robinson W N, Pawlowski S D, Volkov V. Requirements interaction management[J]. ACM Computing Surveys (CSUR),2003,35(2):132-190.

[55] Van Lamsweerde A, Darimont R, Letier E. Managing conflicts in goal-driven requirements engineering[J].Software Engineering, IEEE Transactions on,1998,24(11): 908-926.

[56] Carlshamre P, Sandahl K, Lindvall M, et al. An industrial survey of requirements interdependencies in software product release planning[C]//Requirements Engineering, 2001，Proceedings. Fifth IEEE International Symposium on. IEEE, 2001: 84-91.

[57] Giesen J, Volker A. Requirements interdependencies and stakeholders preferences[C]//Requirements Engineering, 2002. Proceedings. IEEE Joint International Conference on. IEEE, 2002:206-209.

[58] Knethen A. A trace model for system requirements changes on embedded systems[C]//Proceedings of the 4th international workshop on Principles of Software Evolution. ACM, 2001: 17-26.

[59] von Knethen A, Paech B, Kiedaisch F, et al. Systematic requirements recycling through abstraction and traceability[C]//Requirements Engineering, 2002. Proceedings. IEEE Joint International Conference on. IEEE, 2002: 273-281.

[60] Zhang W, Mei H, Zhao H. Feature-driven requirement dependency analysis and high-level software design[J]. Requirements Engineering,2006,11(3):205-220.

[61] 藩梅森,熊齊. 基于SVM 的軟件需求分析風(fēng)險(xiǎn)評(píng)估模型[J].計(jì)算機(jī)工程，2007,33(12):78-81.

[62] Kamata M I, Tamai T. How Does Requirements Quality Relate to Project Success or Failure?[C]//Requirements Engineering Conference, 2007. RE'07.15th IEEE International. IEEE, 2007: 69-78.

[63] Leffingwell D. Calculating your return on investment from more effective requirements management[J]. Available from Rational, URL http://www. rational. com/media/whitepapers/ roi1. pdf, 1997.

[64] 嚴(yán)玉清,李師賢,梅曉勇.缺陷需求分析與管理模型[J].計(jì)算機(jī)科學(xué)，2009,36(4):140-144.

[65] Fabbrini F,Fusani M,Gnesi S,et al.An automatic quality evaluation for natural language requirements[C]//Proceedings of the Seventh International Workshop on Requirements Engineering: Foundation for Software Quality REFSQ，2001,1:4-5.

[66] Rosenberg L, Hammer T F, Huffman L L.Requirements, testing and metrics[C]//15th Annual Pacific Northwest Software Quality Conference，1998.

[67] Fantechi A, Gnesi S, Lami G, et al. Applications of linguistic techniques for use case analysis[J]. Requirements Engineering,2003,8(3):161-170.

ASurveyofSoftwareRequirementsAnalysis

LI Chao1,2,XIE Kun-wu1*

(1.Science and Technology College of Hubei University for Nationalities,Enshi 445000, China; 2.College of Information Engineering,Hubei University for Nationalities,Enshi 445000,China)

Software requirements analysis technologies have got considerable development. Requirements analysis is the final phase of software definition and the successful structuring of the software system greatly depends on its quality. Different requirements elicitation technology, requirements analysis and modeling methods, and management technology have a great influence on the software development, maintenance, quality and reuse. It is important for us to study the software requirements. We systematically analyzed and summarized the software requirements acquisition methods, requirements analysis and modeling techniques and requirements management,and predicted the future research issues.

software engineering;requirements management;requirements analysis

2013-03-14.

國(guó)家自然科學(xué)基金項(xiàng)目(61040006);湖北省自然科學(xué)基金項(xiàng)目(2009CDB069);湖北恩施州科技局項(xiàng)目(2011)；湖北民族學(xué)院科技學(xué)院項(xiàng)目(K201001).

李超(1979- )，男，講師，碩士，主要從事軟件工程等的研究;*

：謝坤武(1974- )，男，教授，主要從事軟件工程、數(shù)據(jù)挖掘等的研究.

TP311.5

A

1008-8423(2013)02-0204-08