需求工程是指應(yīng)用已證實(shí)有效的技術(shù)、方法進(jìn)行需求分析，確定客戶需求，幫助分析人員理解問題并定義目標(biāo)系統(tǒng)的所有外部特征的一門學(xué)科。需求工程通過合適的工具和記號系統(tǒng)地描述待開發(fā)系統(tǒng)及其行為特征和相關(guān)約束，形成需求文檔，并對用戶不斷變化的需求演進(jìn)給予支持。

需求工程是隨著計(jì)算機(jī)的發(fā)展而發(fā)展的，在計(jì)算機(jī)發(fā)展的初期，軟件規(guī)模不大，軟件開發(fā)所關(guān)注的是代碼編寫，需求分析很少受到重視。后來軟件開發(fā)引入了生命周期的概念，需求分析成為其第一階段。隨著軟件系統(tǒng)規(guī)模的擴(kuò)大，需求分析與定義在整個軟件開發(fā)與維護(hù)過程中越來越重要，直接關(guān)系到軟件的成功與否。人們逐漸認(rèn)識到需求分析活動不再僅限于軟件開發(fā)的最初階段，它貫穿于系統(tǒng)開發(fā)的整個生命周期。80年代中期，形成了軟件工程的子領(lǐng)域——需求工程(requirement engineering,RE)。進(jìn)入90年代以來，需求工程成為研究的熱點(diǎn)之一。從1993年起每兩年舉辦一次需求工程國際研討會(ISRE)，自1994年起每兩年舉辦一次需求工程國際會議(ICRE)，在1996年Springer-Verlag發(fā)行了一新的刊物——《Requirements Engineering》。一些關(guān)于需求工程的工作小組也相繼成立，如歐洲的RENOIR(Requirements Engineering Network of International Cooperating Research Groups)，并開始開展工作。

需求分析是介于系統(tǒng)分析和軟件設(shè)計(jì)階段之間的橋梁。一方面，需求分析以系統(tǒng)規(guī)格說明和項(xiàng)目規(guī)劃作為分析活動的基本出發(fā)點(diǎn)，并從軟件角度對它們進(jìn)行檢查與調(diào)整；另一方面，需求規(guī)格說明又是軟件設(shè)計(jì)、實(shí)現(xiàn)、測試直至維護(hù)的主要基礎(chǔ)。良好的分析活動有助于避免或盡早剔除早期錯誤，從而提高軟件生產(chǎn)率，降低開發(fā)成本，改進(jìn)軟件質(zhì)量。

需求工程(RE)可分為

1.系統(tǒng)需求工程（如果是針對由軟硬件共同組成的整個系統(tǒng)）

2.軟件需求工程（如果僅是專門針對純軟件部分）。

軟件需求工程是一門分析并記錄軟件需求的學(xué)科，它把系統(tǒng)需求分解成一些主要的子系統(tǒng)和任務(wù)，把這些子系統(tǒng)或任務(wù)分配給軟件，并通過一系列重復(fù)的分析、設(shè)計(jì)、比較研究、原型開發(fā)過程把這些系統(tǒng)需求轉(zhuǎn)換成軟件的需求描述和一些性能參數(shù)。

需求工程是一個不斷反復(fù)的需求定義、文檔記錄、需求演進(jìn)的過程，并最終在驗(yàn)證的基礎(chǔ)上凍結(jié)需求。80年代，HerbKrasner定義了需求工程的五階段生命周期：需求定義和分析、需求決策、形成需求規(guī)格、需求實(shí)現(xiàn)與驗(yàn)證、需求演進(jìn)管理。近來，MatthiasJarke和KlausPohl提出了三階段周期的說法：獲取、表示和驗(yàn)證。

綜合了幾種觀點(diǎn)，可以把需求工程的活動劃分為以下5個獨(dú)立的階段：

（1）需求獲?。和ㄟ^與用戶的交流，對現(xiàn)有系統(tǒng)的觀察及對任務(wù)進(jìn)行分析，從而開發(fā)、捕獲和修訂用戶的需求；

（2）需求建模：為最終用戶所看到的系統(tǒng)建立一個概念模型，作為對需求的抽象描述，并盡可能多的捕獲現(xiàn)實(shí)世界的語義；

（3）形成需求規(guī)格：生成需求模型構(gòu)件的精確的形式化的描述，作為用戶和開發(fā)者之間的一個協(xié)約；

（4）需求驗(yàn)證：以需求規(guī)格說明為輸入，通過符號執(zhí)行、模擬或快速原型等途徑，分析需求規(guī)格的正確性和可行性；

（5）需求管理：支持系統(tǒng)的需求演進(jìn)，如需求變化和可跟蹤性問題。

需求工程無疑是當(dāng)前軟件工程中的關(guān)鍵問題，從美國于1995年開始的一項(xiàng)調(diào)查結(jié)果就足以看出這一點(diǎn)。在這項(xiàng)調(diào)查中，他們對全國范圍內(nèi)的8000個軟件項(xiàng)目進(jìn)行跟蹤調(diào)查，結(jié)果表明，有1/3的項(xiàng)目沒能完成，而在完成的2/3的項(xiàng)目中，又有1/2的項(xiàng)目沒有成功實(shí)施。他們仔細(xì)分析失敗的原因后發(fā)現(xiàn)，與需求過程相關(guān)的原因占了45%，而其中缺乏最終用戶的參與以及不完整的需求又是兩大首要原因，各占13%和12%。

需求工程又是軟件工程中最復(fù)雜的過程之一，其復(fù)雜性來自于客觀和主觀兩個方面。從客觀意義上說，需求工程面對的問題幾乎是沒有范圍的。由于應(yīng)用領(lǐng)域的廣泛性，它的實(shí)施無疑與各個應(yīng)用行業(yè)的特征密切相關(guān)。其客觀上的難度還體現(xiàn)在非功能性需求及其與功能性需求的錯綜復(fù)雜的聯(lián)系上，當(dāng)前對非功能性需求分析建模技術(shù)的缺乏大大增加了需求工程的復(fù)雜性。從主觀意義上說，需求工程需要方方面面人員的參與（如領(lǐng)域?qū)＜?、領(lǐng)域用戶、系統(tǒng)投資人、系統(tǒng)分析員、需求分析員等等），各方面人員有不同的著眼點(diǎn)和不同的知識背景，溝通上的困難給需求工程的實(shí)施增加了人為的難度。

最初，需求工程僅僅是軟件工程的一個組成部分，是軟件生命周期的第一個階段。雖然大家也都知道需求工程對軟件整個生命周期的重要性，但對它的研究遠(yuǎn)遠(yuǎn)沒有對軟件工程的其他部分的研究那么深入。

在傳統(tǒng)軟件工程生命周期中，涉及需求的階段稱作需求分析。一般來說，需求分析的作用是：

• 系統(tǒng)工程師說明軟件的功能和性能，指明軟件和其他系統(tǒng)成分的接口，并定義軟件必須滿足的約束；

• 軟件工程師求精軟件的配置，建立數(shù)據(jù)模型、功能模型和行為模型；

• 為軟件設(shè)計(jì)者提供可用于轉(zhuǎn)換為數(shù)據(jù)設(shè)計(jì)、體系結(jié)構(gòu)設(shè)計(jì)、界面設(shè)計(jì)和過程設(shè)計(jì)的模型；

• 提供開發(fā)人員和客戶需求規(guī)格說明，用于作為評估軟件質(zhì)量的依據(jù)。

但從當(dāng)前的研究現(xiàn)狀來看，需求工程的內(nèi)容遠(yuǎn)不止這些。需求工程是系統(tǒng)工程和軟件工程的一個交叉分支，涉及到軟件系統(tǒng)的目標(biāo)、軟件系統(tǒng)提供的服務(wù)、軟件系統(tǒng)的約束和軟件系統(tǒng)運(yùn)行的環(huán)境。它還涉及這些因素和系統(tǒng)的精確規(guī)格說明以及系統(tǒng)進(jìn)化之間的關(guān)系。它也提供現(xiàn)實(shí)需要和軟件能力之間的橋梁。

需求工程的基本活動包括：

• 抽取需求；

• 模擬和分析需求；

• 傳遞需求；

• 認(rèn)可需求；

• 進(jìn)化需求。

每個活動都有它基本的動機(jī)、任務(wù)和結(jié)果，也有各自的困難所在。

首先，開始一個項(xiàng)目是因?yàn)橐獙ΜF(xiàn)行系統(tǒng)進(jìn)行改造。要改造一個系統(tǒng)是因?yàn)楝F(xiàn)行系統(tǒng)存在需要解決的問題。如：現(xiàn)行系統(tǒng)與當(dāng)前情況不符合、出現(xiàn)新的商機(jī)或者可能節(jié)省時(shí)間、資金和資源等，這就是抽取需求的動機(jī)。在這個階段，需求工程師的任務(wù)是認(rèn)識問題之所在，獲取足夠多的知識，最后成為問題領(lǐng)域的專家。需求工程師常采用W6H方法去認(rèn)識問題領(lǐng)域，即6個以W打頭的問題，一個以H打頭的問題，如表1所示。

需求抽取是非常困難的，其主要原因有：

• 缺乏領(lǐng)域知識，應(yīng)用領(lǐng)域的問題常常是模糊的、不精確的；

• 存在默認(rèn)的知識，即難以描述的日常知識（常識問題）；

• 存在多個知識源，而且多知識源之間可能有沖突；

• 面對的客戶可能有偏見，如不能提供你需要了解什么或不想告知你需要了解的事情。

需求抽取的方法一般有問卷法、面談法、數(shù)據(jù)采集法、用況法、情景實(shí)例法、組織會議法以及基于目標(biāo)的方法等，還有知識工程方法，如：場記分析法、卡片分類法、分類表格技術(shù)和基于模型的知識獲取等。

需求工程的第二個階段是模擬和分析需求，目前有許多工作都以此為目標(biāo)進(jìn)行。需求分析和模擬的出發(fā)點(diǎn)在于：

• 指導(dǎo)抽??；

• 幫助需求工程師了解進(jìn)展；

• 幫助發(fā)現(xiàn)問題；

• 幫助檢查對問題的理解。

需求分析和模擬又包含三個層次的工作。首先是需求建模。需求模型的表現(xiàn)形式有自然語言、半形式化（如圖、表、結(jié)構(gòu)化英語等）和形式化表示等三種。自然語言形式具有表達(dá)能力強(qiáng)的特點(diǎn)，但它不利于捕獲模型的語義，一般只用于需求抽取或標(biāo)記模型。半形式化表示可以捕獲結(jié)構(gòu)和一定的語義，也可以實(shí)施一定的推理和一致性檢查。形式化表示具有精確的語義和推理能力，但要構(gòu)造一個完整的形式化模型，需要較長時(shí)間和對問題領(lǐng)域的深層次理解。對需求概念模型的要求包括：

• 實(shí)現(xiàn)的獨(dú)立性:不模擬數(shù)據(jù)的表示和內(nèi)部組織等；

• 足夠抽象：只抽取關(guān)于問題的本質(zhì)方面；

• 足夠形式化：語法無二義性，并具有豐富的語義；

• 可構(gòu)造性：簡單的模型塊，能應(yīng)付不同復(fù)雜程度和規(guī)模的描述；

• 利于分析：能支持二義性、不完整性和不一致性分析；

• 可追蹤性:支持橫向交叉索引并能與設(shè)計(jì)或?qū)崿F(xiàn)等建立關(guān)聯(lián)；

• 可執(zhí)行性：可以動態(tài)模擬，利于與現(xiàn)實(shí)相比較；

• 最小性：沒有冗余的概念。

需求模擬技術(shù)又分為企業(yè)模擬、功能需求模擬和非功能需求模擬等。

企業(yè)模擬是一種軟系統(tǒng)方法，涉及整個組織，從各個不同的視點(diǎn)分析問題，包括目標(biāo)、組織結(jié)構(gòu)、活動、過程等。有的企業(yè)模擬還建立可執(zhí)行的領(lǐng)域模型。采用企業(yè)模擬方法產(chǎn)生的不僅僅是規(guī)格說明，還可以得到許多關(guān)于企業(yè)運(yùn)作的狀況分析。目前代表性的工作包括：信息模擬、組織模擬和目標(biāo)模擬等。

功能需求模擬從不同視點(diǎn)為模擬軟件提供服務(wù)，包括結(jié)構(gòu)視點(diǎn)和行為視點(diǎn)等，主要方法有：結(jié)構(gòu)化分析、面向?qū)ο蠓治龊托问交椒ā＝Y(jié)構(gòu)化分析是一種面向數(shù)據(jù)的方法，以數(shù)據(jù)流為中心。其核心概念包括：進(jìn)程、數(shù)據(jù)流、數(shù)據(jù)存儲、外部實(shí)體、數(shù)據(jù)組和數(shù)據(jù)元素。有代表性的模擬工具有：數(shù)據(jù)流圖、數(shù)據(jù)字典、原始進(jìn)程規(guī)格說明。面向?qū)ο蠓治鲆詫ο蠹捌浞?wù)作為建模標(biāo)準(zhǔn)，比較自然，對象也具有相對的穩(wěn)定性。主要模擬的元素有：對象、類、屬性、關(guān)系、方法、消息傳遞、UseCases等。其主要原理包括分類繼承層次、信息隱藏、匯集關(guān)系等。形式化方法從廣義上說，是應(yīng)用離散數(shù)學(xué)的手段來設(shè)計(jì)、模擬和分析，得到像數(shù)學(xué)公式那樣精確的表示。從狹義上說，就是使用一種形式語言進(jìn)行語言公式的形式推理，用于檢查語法的良構(gòu)性并證明某些屬性。形式化方法一般用于一致性檢查、類型檢查、有效性驗(yàn)證、行為預(yù)測以及設(shè)計(jì)求精驗(yàn)證。引入形式化機(jī)制的目的是：

• 減少二義性，提高精確性；

• 為驗(yàn)證打下基礎(chǔ)；

• 允許對需求進(jìn)行推理；

• 允許執(zhí)行需求。

但是人們常常不用形式化手段，因?yàn)椋?

• 形式化涉及太多細(xì)節(jié)，分析的級別較低；

• 形式化的核心問題是一致性和完整性，而不是獲取需求；

• 沒有合適的工具；

• 要求更多的代價(jià)。

傳遞需求的主要任務(wù)是書寫軟件需求規(guī)格說明，其目的是：

• 傳達(dá)對需求的理解；

• 作為軟件開發(fā)項(xiàng)目的一份契約；

• 作為評價(jià)后續(xù)工作的基線；

• 作為控制需求進(jìn)化的基線。

對需求規(guī)格說明感興趣的群體包括：用戶、客戶；系統(tǒng)分析員、需求分析員；軟件開發(fā)者、程序員；測試員；項(xiàng)目管理者。

認(rèn)可需求就是讓上述人員對需求規(guī)格說明達(dá)成一致，其主要任務(wù)是沖突求解，包括定義沖突和沖突求解兩方面。常用的沖突求解方法有：協(xié)商、競爭、仲裁、強(qiáng)制、教育等，其中有些只能用人的因素去控制。

進(jìn)化需求的必要性是明顯的，因?yàn)榭蛻舻男枰偸遣粩啵ㄟB續(xù)）增長的，但是一般的軟件開發(fā)又總是落后于客戶需求的增長，如何管理需求的進(jìn)化（變化）就成為軟件進(jìn)化的首要問題。對傳統(tǒng)的變化管理過程來說，其基本成分包括軟件配置、軟件基線和變化審查小組。當(dāng)前的發(fā)展是軟件家族法，即產(chǎn)品線方法。多視點(diǎn)方法也是管理需求變化的一種新方法，它可以用于管理不一致性并進(jìn)行關(guān)于變化的推理。

需求工程包括需求開發(fā)和管理，而需求開發(fā)又包括這幾個過程：需求獲取，需求分析，需求規(guī)格說明和需求驗(yàn)證。在需求開發(fā)之前，還需要有一個知識培訓(xùn)的過程，需求工程也是一個項(xiàng)目工程，因此也包括了項(xiàng)目的管理。對于這些過程，有以下方法可以采用。

1.知識培訓(xùn)

需求分析員培訓(xùn)：需求分析員應(yīng)該具有良好的交流溝通能力，同時(shí)理解產(chǎn)品，并掌握了需求工程的技能。

用戶培訓(xùn)：用戶也應(yīng)該接受需求工程知識的培訓(xùn)，讓他們理解需求的重要性，知道如何準(zhǔn)確的描述需求，需求的風(fēng)險(xiǎn)性等。

開發(fā)人員培訓(xùn)：開發(fā)人員應(yīng)該對用戶的應(yīng)用領(lǐng)域有一個基礎(chǔ)的了解，明白客戶的業(yè)務(wù)活動，術(shù)語，產(chǎn)品目標(biāo)等

2.需求獲取

需求包括業(yè)務(wù)需求，用戶需求和功能需求以及非功能需求，在需求開發(fā)之前，我們需要先定義好需求開發(fā)的過程，形成文檔，內(nèi)容包括：需求開發(fā)的步驟，每一個步驟如何實(shí)現(xiàn)，如何處理意外情況，如何規(guī)劃開發(fā)資源等

需求獲取包括以下方法和技能：

項(xiàng)目范圍確定：開需求開發(fā)前期，我們應(yīng)該獲取用戶的業(yè)務(wù)需求，定義好項(xiàng)目的范圍，使得所有的涉眾對項(xiàng)目有一個共同的理解。

用戶確定：確定用戶群和分類，對用戶組進(jìn)行詳細(xì)描述，包括使用產(chǎn)品頻率，所使用的功能，優(yōu)先級別，熟練程度等等。對每一個用戶組確定用戶的代言人。對于大型項(xiàng)目，我們需要先確定中心客戶組，中心客戶組的需求具有高級別的優(yōu)先級，需要先實(shí)現(xiàn)的核心功能。

用例確定：與用戶代表溝通，了解他們需要完成的任務(wù)，得到用例模型。同時(shí)根據(jù)用例導(dǎo)出功能需求。用例描述應(yīng)該采用標(biāo)準(zhǔn)模板。

系統(tǒng)事件和響應(yīng)：業(yè)務(wù)事件可能觸發(fā)用例，系統(tǒng)事件包括系統(tǒng)內(nèi)部的事件以及從外部接受到信息，數(shù)據(jù)等等，或者一個突發(fā)的任務(wù)。

獲取方法：召開需求討論會議，觀察用戶的工作過程，采用問答式對話，采用誘發(fā)式需求誘導(dǎo)等等。檢查完善：問題報(bào)告和補(bǔ)充需求建議

3.需求分析

需求分析是對用戶的需求獲取之后的一個粗加工過程，需要對需求進(jìn)行推敲和潤色以使所有涉眾都能準(zhǔn)確理解需求。分析過程首先需要對需求進(jìn)行檢查，以保證需求的正確性和完備性，然后將高層需求分解成具體的細(xì)節(jié)，創(chuàng)建開發(fā)原型，完成需求從需求獲取人員到開發(fā)人員的過渡。

繪制關(guān)聯(lián)圖：關(guān)聯(lián)圖確定系統(tǒng)和外部的交互。劃分了系統(tǒng)的范圍和界限，構(gòu)建了系統(tǒng)對外的接口。

原型開發(fā)：對于敏捷方法，推薦完成一個界面的原型，一個初步的系統(tǒng)實(shí)現(xiàn)，通過原型，讓所有涉眾對開發(fā)的項(xiàng)目有了一個初步的映像，同時(shí)可以提供對需求的檢驗(yàn)。

需求優(yōu)先級別：采用分析的方法確定產(chǎn)品的功能，用例和單項(xiàng)需求的優(yōu)先級別，以優(yōu)先級為基礎(chǔ)，確定各項(xiàng)功能和需求都包括在哪個版本中，在項(xiàng)目開發(fā)過程中，需求的優(yōu)先級別根據(jù)實(shí)際情況進(jìn)行調(diào)整。

需求建模：圖形分析模型對需求描述更加抽象。主要可以采用UML的建模分析。

數(shù)據(jù)字典創(chuàng)建：建立系統(tǒng)中所用到的數(shù)據(jù)項(xiàng)和結(jié)構(gòu)的定義，數(shù)據(jù)字典可以使參與項(xiàng)目開發(fā)的每一個人都使用統(tǒng)一的定義。

子系統(tǒng)：建立系統(tǒng)的結(jié)構(gòu)，同時(shí)將需求分配到各個子系統(tǒng)和模塊中。

4.規(guī)格說明

SRS應(yīng)該是一個作為涉眾對系統(tǒng)的統(tǒng)一理解。

采用SRS模板：定義一種標(biāo)準(zhǔn)模板。

1.過程能力評估

通過比較現(xiàn)有需求工程過程與過程參考模型之間的差別，可以評估現(xiàn)有過程的能力水平。具體而言，首先以調(diào)查表、面談等方式收集組織中需求相關(guān)實(shí)踐的執(zhí)行情況；然后，與過程參考模型中的實(shí)踐進(jìn)行映射和比較，統(tǒng)計(jì)各能力等級下實(shí)踐的執(zhí)行情況；根據(jù)統(tǒng)計(jì)結(jié)果判定當(dāng)前所處的能力等級。

需求工程過程參考模型，當(dāng)“已執(zhí)行級”的基礎(chǔ)實(shí)踐被全部規(guī)范執(zhí)行時(shí)，需求工程過程達(dá)到“已執(zhí)行”能力等級，否則，需求過程處在“不完整”能力等級；當(dāng)執(zhí)行了全部的“已管理級”實(shí)踐時(shí)，需求工程過程達(dá)到“已管理”能力等級；當(dāng)執(zhí)行了全部的“已定義級”實(shí)踐時(shí)，需求開發(fā)工程達(dá)到“已定義”能力等級。

2.過程改進(jìn)策略

確定了組織需求過程所處的能力水平后，可以通過引入新實(shí)踐或提高已有實(shí)踐的性能，實(shí)現(xiàn)過程的改進(jìn)。首先要明確過程改進(jìn)的目標(biāo)；然后分析組織的資源條件，確定過程改進(jìn)的主要內(nèi)容和手段。要遵循漸進(jìn)的過程改進(jìn)策略。一般來說，按照“由低到高”、“先規(guī)范后引入”的順序逐提高過程能力，即先改進(jìn)低能力等級的實(shí)踐再改進(jìn)高能力等級的，先規(guī)范已有實(shí)踐再引入新實(shí)踐，這樣可以降低組織進(jìn)行需求工程過程改進(jìn)的風(fēng)險(xiǎn)。

需求分析階段的工作結(jié)果是開發(fā)軟件系統(tǒng)的重要基礎(chǔ)，大量統(tǒng)計(jì)數(shù)字表明，軟件系統(tǒng)中15%的錯誤起源與錯誤的需求。因此，軟件需求規(guī)格說明書完成以后，需要認(rèn)真進(jìn)行技術(shù)評審和修改。作為需求分析階段工作的復(fù)查手段，在需求分析的最后一步，應(yīng)該對功能的正確性、完整性和清晰性，以及其他需求給予評價(jià)，可按以下準(zhǔn)則評價(jià)和驗(yàn)證。

1.正確性：正確性是最基本的要求之一，一般是指雜需求規(guī)格說明書中對于待開發(fā)系統(tǒng)的功能、行為、性能的描述必須與用戶對目標(biāo)軟件產(chǎn)品的期望相吻合，正確性是相對與用戶的應(yīng)用需求而言的，由于具體應(yīng)用的千差萬別，需求規(guī)格說明書的正確性的判斷標(biāo)準(zhǔn)也應(yīng)各不相同。正確性檢查屬于技術(shù)問題，它并不能說明需求模型是否完全表達(dá)了用戶需求。評價(jià)正確性時(shí)，可以按照建模規(guī)則去檢查，或使用軟件工具(如CASE)自動檢查。當(dāng)然，也可以請其他不參與該項(xiàng)目的同行校對，發(fā)現(xiàn)錯誤及時(shí)更正。

2.完整性：完整性是指需求模型中是否包含了用戶所需的所有功能，這是最基本的要求，若不能滿足，其它任何質(zhì)量問題都無從談起。因?yàn)樾枨蠓治龅牟煌耆?，即使后面的設(shè)計(jì)與實(shí)現(xiàn)再好，也不能滿足用戶的要求。并且，在系統(tǒng)開發(fā)后期增加或更改用戶需求，將會成倍地增加開發(fā)代價(jià)。因此，完整性評價(jià)是需求工程質(zhì)量的關(guān)鍵。改進(jìn)需求分析的完整性將有助于提高軟件開發(fā)的生產(chǎn)率，但評價(jià)完全性問題卻很難。因?yàn)橛脩粲袝r(shí)不能完全表達(dá)其所有需求，開發(fā)者又沒有預(yù)見，致使軟件完成后才發(fā)現(xiàn)，維護(hù)代價(jià)相當(dāng)大。為了及時(shí)發(fā)現(xiàn)問題，開發(fā)者最好跟班作業(yè)，對用戶的業(yè)務(wù)進(jìn)行深入地了解，從而對需求模型的完全性作出評價(jià)。具體評價(jià)方法可采用用戶審閱、樣例分析、業(yè)務(wù)規(guī)則驗(yàn)證、進(jìn)程映像等方法。

3.實(shí)現(xiàn)性：實(shí)現(xiàn)性是指需求模型可以在規(guī)定的時(shí)間、經(jīng)費(fèi)預(yù)算和項(xiàng)目的技術(shù)約束下完成整個軟件開發(fā)。這就要求我們在需求模型中不要出現(xiàn)這樣或那樣的假設(shè)，不要忽略各種實(shí)際因素，特別是技術(shù)和經(jīng)費(fèi)，以免到開發(fā)后期追悔莫及。評價(jià)可實(shí)現(xiàn)性主要應(yīng)用下面兩種方法:

（1）應(yīng)用開發(fā)人員審閱。他們會重點(diǎn)審查系統(tǒng)實(shí)現(xiàn)的一些潛在問題，從技術(shù)和經(jīng)濟(jì)角度分析系統(tǒng)實(shí)現(xiàn)的可行性，發(fā)現(xiàn)問題可及早修改。

（2）開發(fā)代價(jià)估計(jì)。這是對需求模型的實(shí)現(xiàn)性進(jìn)行定量測量的方法，通常質(zhì)量越好代價(jià)越大，降低代價(jià)就要犧牲質(zhì)量。只有權(quán)衡兩者的關(guān)系，才能使系統(tǒng)的可實(shí)現(xiàn)性達(dá)到最佳。

總之，實(shí)現(xiàn)性是需求工程質(zhì)量的最重要因素之一，實(shí)現(xiàn)可能性極小的需求模型，其它質(zhì)量因素再好也無用。

4.適應(yīng)性：適應(yīng)性可以看作需求模型與用戶的獨(dú)立性，即當(dāng)用戶需求發(fā)生變化時(shí)，需求模型可以不做修改或只進(jìn)行微小調(diào)整。

適應(yīng)性是需求工程質(zhì)量評價(jià)的最關(guān)鍵因素之一，但在實(shí)際系統(tǒng)開發(fā)中往往不被重視。很多需求分析人員就事論事，以完成系統(tǒng)的基本功能為目標(biāo)，而忽略了其功能擴(kuò)充或改變的可能性，這將會給系統(tǒng)維護(hù)造成困難。適應(yīng)性評價(jià)要分析哪些需求將來可能改變、它們出現(xiàn)的可能性及其對需求模型的影響。由于系統(tǒng)未來可能發(fā)生的變化很難預(yù)測，所以適應(yīng)性評價(jià)有一定困難。具體評價(jià)可采用如下方法:

（1）高層管理者評審。因?yàn)檫m應(yīng)性評價(jià)涉及組織發(fā)展的戰(zhàn)略目標(biāo)，一般的業(yè)務(wù)工作人員無能為力，只有高層決策者才能把握企業(yè)未來的發(fā)展方向。

（2）行業(yè)專家評審。這些行業(yè)專家應(yīng)該是業(yè)務(wù)咨詢或?qū)W術(shù)專家，他們能更好地把握企業(yè)的發(fā)展方向，能夠?qū)撛诘氖袌鲎兓捌淇赡苄宰鞒?a href="/wiki/%E9%A2%84%E6%B5%8B%E5%88%86%E6%9E%90" title="預(yù)測分析">預(yù)測分析。

（3）技術(shù)專家評審。有經(jīng)驗(yàn)的需求分析專家可以基于系統(tǒng)結(jié)構(gòu)對系統(tǒng)的適應(yīng)性作出評估，雖然他們并不一定熟悉企業(yè)的業(yè)務(wù)，但是可以從需求分析的技術(shù)角度評價(jià)系統(tǒng)的適應(yīng)性。

5.集成性：在一個大的企業(yè)信息系統(tǒng)開發(fā)中，通常包括多個應(yīng)用子系統(tǒng)，這些子系統(tǒng)之間的數(shù)據(jù)一致性問題顯得格外重要。集成性就是指某個應(yīng)用子系統(tǒng)與企業(yè)信息系統(tǒng)中其它應(yīng)用系統(tǒng)之間的數(shù)據(jù)一致性，以減少應(yīng)用系統(tǒng)之間的數(shù)據(jù)沖突。由于在某些項(xiàng)目開發(fā)中，各應(yīng)用子系統(tǒng)的需求分析是相對獨(dú)立的，這就不可避免地造成數(shù)據(jù)重復(fù)、系統(tǒng)之間接口復(fù)雜等問題。要防止出現(xiàn)類似情況，應(yīng)盡可能地重復(fù)利用已有的數(shù)據(jù)資源或者進(jìn)行適當(dāng)?shù)臄U(kuò)充，以適應(yīng)新系統(tǒng)的要求。其次，對數(shù)據(jù)項(xiàng)的定義要保持命名和格式上的一致。

特別強(qiáng)調(diào)的是要用全局的觀點(diǎn)看待數(shù)據(jù)，使需求模型具有通用性。

集成性的評價(jià)可采用如下幾種方法:

（1）通過局部應(yīng)用與全局應(yīng)用模型的比較，發(fā)現(xiàn)數(shù)據(jù)沖突和結(jié)構(gòu)沖突。

（2）將數(shù)據(jù)項(xiàng)向已有的數(shù)據(jù)源做映像，查看是否存在數(shù)據(jù)共享和重用的可能。

（3）讓該應(yīng)用系統(tǒng)以外的其它業(yè)務(wù)部門審閱，檢查數(shù)據(jù)定義是否具有共性。

6.一致性：需求規(guī)格說明書的一致性要求：系統(tǒng)中不存在顯式的或隱含的矛盾，也就是說，需求規(guī)格說明書中各個需求的描述必須不能相互矛盾，矛盾主要為：術(shù)語使用方面的沖突，功能沖突，以及時(shí)序方面的前后不一致等。一致性的評價(jià)可采用如下幾種方法:

（1）同一意思要用相同的術(shù)語來表達(dá)。

（2）需求規(guī)格說明書中的各個部分的產(chǎn)品功能不得相互矛盾。

7.理解性：顧名思義，理解性是指需求模型的結(jié)構(gòu)和描述易于理解。只有通俗易懂，才能更好地同用戶交流。如果用戶很難理解需求分析結(jié)果，他們就不可能檢驗(yàn)需求模型是否完全準(zhǔn)確地表達(dá)了他們的需求內(nèi)容。另外，應(yīng)用開發(fā)人員對需求模型的理解也至關(guān)重要，因?yàn)樗麄冐?fù)責(zé)系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)，不充分理解系統(tǒng)的需求，會使軟件系統(tǒng)的實(shí)現(xiàn)結(jié)果同用戶要求出現(xiàn)偏差，造成軟件生產(chǎn)率下降。評價(jià)理解性常可采用以下方法:

（1）用戶審閱。這是最常用的一種方法，檢驗(yàn)需求模型的可理解性。但這種方法有一個缺點(diǎn)，用戶可能只關(guān)心他們所熟悉的業(yè)務(wù)操作，而沒有充分理解模型所表達(dá)的含義。

（2）樣例分析。更有效的方法是讓用戶去使用這個模型，分析一個業(yè)務(wù)樣例，來檢驗(yàn)他們對模型的理解程度。

（3）應(yīng)用開發(fā)人員審閱。雖然系統(tǒng)設(shè)計(jì)和編程人員不像需求分析人員那樣熟悉用戶的業(yè)務(wù)要求，但他們能有針對性地找出哪些地方描述得不清楚。同時(shí)，這一步也是應(yīng)用開發(fā)人員認(rèn)識需求模型的過程，有利于他們即將進(jìn)行的設(shè)計(jì)工作，保證整個系統(tǒng)開發(fā)階段的平穩(wěn)過渡。