李 超，謝坤武

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

軟件需求分析方法研究進展

李 超1,2，謝坤武1*

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

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

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

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

1 需求獲取方法

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

無論是特定系統(tǒng)還是軟件包的開發(fā),都離不開需求獲取.需求獲取是一個取得用戶對目標軟件需求的過程,是一項困難的工作,它要求開發(fā)人員應具備相應的領域知識，用戶提供相應的材料及信息,最終結果能解決用戶面臨的問題.本節(jié)先對常用的需求獲取方法作簡要的介紹.

1)訪談與會議

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

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

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

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

3)分析程序和其他文檔

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

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

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

5)問卷調查

問卷調查又稱調查表或詢問表,是以問題形式系統(tǒng)地記載調查內容的一種文件.設計問卷是詢問調查的關鍵.問卷可以是表格式、卡片式或簿記式.問卷須具備兩個功能,即能將問題傳達給被問的人和使被問者樂于回答.

6)敏捷方法

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

7)基于知識的方法

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

2 需求分析及建模方法

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

1)面向對象需求分析

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

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

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

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

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

3)面向Agent需求分析

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

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

4)用例驅動需求分析

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

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

5)場景驅動需求分析

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

6)基于多視點(觀點)需求分析

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

7)面向方面需求分析

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

8)目標驅動需求分析

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

9)用戶主導、市場驅動、產(chǎn)品線需求分析

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

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

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

10)形式化方法需求分析

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

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

11)需求建模工具的比較

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

3 軟件需求管理與控制

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

1)需求質量度量與控制

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

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

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

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

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

4)需求依賴性分析

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

5)需求風險評估

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

6)需求缺陷分析與管理

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

7)需求管理工具的比較

限于篇幅僅對需求管理工具Telelogic DOORS，Ratioanl RequisitePro 和Borland CaliberRM作一個簡單的對比分析.

表1 需求管理工具的比較

4 需求的評審

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

5 軟件需求研究的趨勢

近年來軟件需求分析技術獲得了長足的發(fā)展.軟件需求獲取方法、分析及建模技術以及面向對象的工具平臺比較成熟，但在需求優(yōu)先級的確定，基于需求的軟件規(guī)模度量，需求的質量度量方法及度量工具的開發(fā)，需求描述工具，需求到設計再到軟件的實現(xiàn)平臺的研究，需求的重用特別是特定領域需求的重用，需求粒度，需求協(xié)同分析等許多方面將有許多工作要做.

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

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

[2] 龔曉慶,張遠軍,陳峰,等. 面向對象系統(tǒng)分析與設計[M].北京：清華大學出版社,2008.

[3] 劉偉琴,劉洪濤.軟件需求[M].北京：清華大學出版社,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] 金芝. 基于本體的需求自動獲取[J].計算機學報,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] 劉慶海，周國新，唐旭，等.城鎮(zhèn)宗地地介評估信息系統(tǒng)的研究與實現(xiàn)[J].湖北民族學院學報：自然科學版，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] 梁正平,毋國慶,王志強.一種基于問題框架的視點表示模型[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] 江敏,毋國慶.多視點間不一致性的認知推理[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] 牟克典,金芝,陸汝鈐.視點合成中重疊需求的不一致優(yōu)先級處理[J].計算機學報,2004,27(10):1379-1387.

[34] 梁正平,明仲,毋國慶. 多視點需求工程中視點集成過程的研究[J].計算機科學,2009,36(8):138-144.

[35] 方義秋,冉華鋒,葛君偉.基于用例的面向方面需求建模[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] 李勇華,王鋒,毋國慶.一種謂詞驅動的目標求精方法[J].計算機工程,2007，33(2l):58-60.

[40] 舒風笛,趙玉柱.個性化領域知識支持的用戶主導需求獲取方法[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)品線的需求分析研究[J].計算機工程與設計，2007,28(8):1778-1780.

[45] 崔巍,曾廣周.面向組件的軟件需求協(xié)同分析研究[J].山東師范大學學報，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] 孫未來,白雪峰.Z和VDM規(guī)格說明的差異比較,計算機科學,1997,24(4)：74-79.

[49] 吳偉敏,UML建模工具的比較- ROSE,Visio和PowerDesigner[J].現(xiàn)代計算機,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及其質量模糊度量方法的研究[J].計算機科學,2003,30(4):131-133.

[53] 黃蒙,舒風笛,李明.一種風險驅動的迭代開發(fā)需求優(yōu)先級排序方法報[J].軟件學，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 的軟件需求分析風險評估模型[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] 嚴玉清,李師賢,梅曉勇.缺陷需求分析與管理模型[J].計算機科學，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.

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

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

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

TP311.5

A

1008-8423(2013)02-0204-08