《軟件工程-理論、方法與實(shí)踐》課件第4章

第4章需求工程4.1軟件需求4.2需求工程過(guò)程4.3可行性研究4.4需求獲取和分析4.5需求定義4.6需求驗(yàn)證4.7案例本章小結(jié)習(xí)題

4.1軟件需求

IEEE給出了如下關(guān)于軟件需求的定義：

(1)用戶解決問(wèn)題或達(dá)到目標(biāo)所需的條件或能力。

(2)系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其他正式規(guī)定文檔所需具有的條件或能力。

(3)一種反映(1)或(2)所描述的條件或能力的說(shuō)明。一般來(lái)說(shuō)，站在不同的角度對(duì)需求的理解會(huì)有一定的偏差，客戶方和開(kāi)發(fā)者對(duì)需求概念的范圍和定義的要求也會(huì)有所不同，IanSommerville根據(jù)需求文檔服務(wù)的對(duì)象將需求分成兩類：用戶需求和系統(tǒng)需求。如果從系統(tǒng)應(yīng)解決的問(wèn)題和達(dá)到的目標(biāo)來(lái)分，軟件需求又可分為功能性需求、非功能性需求和業(yè)務(wù)需求。4.1.1用戶需求和系統(tǒng)需求

軟件開(kāi)發(fā)過(guò)程中，需求需要以文檔的形式被描述出來(lái)，文檔化的需求既是開(kāi)發(fā)者與用戶之間溝通和達(dá)成協(xié)議的需要，也是開(kāi)發(fā)人員進(jìn)行后期軟件設(shè)計(jì)、驗(yàn)證活動(dòng)的基礎(chǔ)。由于用戶和開(kāi)發(fā)者角色、知識(shí)背景以及期望目標(biāo)的差別，僅一種需求描述形式難以兼顧各方的需要。因此可以將需求文檔分為用戶需求(UserRequirements)和系統(tǒng)需求(SystemRequirements)。

表4.1是一個(gè)示例，反映了用戶需求和系統(tǒng)需求的區(qū)別。

4.1.2功能性需求和非功能性需求

從軟件需求的定義就可以看出，任何軟件系統(tǒng)都應(yīng)具備一定的功能和服務(wù)，在提供服務(wù)的同時(shí)也需要遵守一定的限制，這就是功能性需求和非功能性需求的本質(zhì)。

功能性需求反映了系統(tǒng)應(yīng)該提供的功能(服務(wù))，包括系統(tǒng)對(duì)特定輸入行為的響應(yīng)、系統(tǒng)的輸出、異常處理等。表4.2是一個(gè)采用自然語(yǔ)言描述的銀行ATM系統(tǒng)的功能性需求的示例，從該需求描述中，可以看出目標(biāo)軟件系統(tǒng)應(yīng)具有的功能和行為。軟件需求定義除了要建立軟件系統(tǒng)應(yīng)提供的功能外還應(yīng)對(duì)系統(tǒng)的內(nèi)在質(zhì)量、特性、性能等方面作出明確的要求，非功能性需求即是關(guān)注軟件系統(tǒng)這方面的需求。

非功能性需求是定義系統(tǒng)提供功能時(shí)所受到的約束和限制，例如響應(yīng)時(shí)間的限制、開(kāi)發(fā)過(guò)程的規(guī)范、法律法規(guī)的約束等。表4.3列出了非功能性需求的類型，主要分為三類：產(chǎn)品需求、過(guò)程需求和外部需求。從表4.3可以看出，軟件的非功能性需求可理解，但驗(yàn)證卻不容易，究竟怎樣才是可用性好？效率高？直接度量這些非功能性需求往往較為困難，這會(huì)導(dǎo)致系統(tǒng)交付時(shí)難以驗(yàn)證，所以通常使用一些度量指標(biāo)間接描述，以便系統(tǒng)開(kāi)發(fā)和交付時(shí)確認(rèn)系統(tǒng)是否符合相關(guān)的要求。表4.4列出了一些非功能性需求的度量指標(biāo)。

4.2需求工程過(guò)程

需求工程過(guò)程活動(dòng)是對(duì)需求的收集、分析、定義和驗(yàn)證的過(guò)程，主要包括可行性研究、需求獲取和分析、需求定義和需求驗(yàn)證等，見(jiàn)圖4.1。需求工程活動(dòng)將產(chǎn)生有效的需求模型和需求文檔，為以后的設(shè)計(jì)、測(cè)試、交付和維護(hù)提供支持。圖4.1需求工程過(guò)程可行性研究活動(dòng)將評(píng)估軟件項(xiàng)目的風(fēng)險(xiǎn)，決策其是否可行，最終形成可行性報(bào)告；需求獲取和分析則是收集、整理需求并建立需求模型的活動(dòng)；需求定義則要形成正式的用戶需求和系統(tǒng)需求文檔；需求驗(yàn)證活動(dòng)對(duì)形成需求文檔進(jìn)行評(píng)審，通過(guò)評(píng)審的文檔正式成為需求定義文檔。

IanSommerville則將需求工程過(guò)程劃分成由三個(gè)階段構(gòu)成的迭代過(guò)程，即需求獲取和分析、需求定義和需求驗(yàn)證。過(guò)程的早期，主要進(jìn)行理解高層業(yè)務(wù)、非功能性需求和用戶需求，后期活動(dòng)則聚焦于系統(tǒng)需求和系統(tǒng)模型的定義。

結(jié)構(gòu)化分析方法(SA)和面向?qū)ο蟮姆治龇椒?OOA)是需求工程中常用的需求分析方法，它們各自擁有一套分析系統(tǒng)、構(gòu)建圖形化分析模型的方法和規(guī)則，用于描述系統(tǒng)的功能、行為及其他相關(guān)特性，如結(jié)構(gòu)化方法中的數(shù)據(jù)流圖、面向?qū)ο蟮腢se-case模型和協(xié)作圖等。本書(shū)將在面向?qū)ο蟮姆治鲆徽轮性敿?xì)討論面向?qū)ο蟮姆治龊徒７椒ā?/p>

4.3可?行?性?研?究

可行性研究是每個(gè)需求工程過(guò)程最先開(kāi)始的活動(dòng)。一般來(lái)說(shuō)，軟件開(kāi)發(fā)過(guò)程會(huì)受到時(shí)間、資金、軟硬件、技術(shù)、人員等資源的一定限制，因此項(xiàng)目開(kāi)始前需進(jìn)行可行性研究，以降低項(xiàng)目的風(fēng)險(xiǎn)，最終將形成的可行性研究報(bào)告用于決定是否要開(kāi)展進(jìn)一步的需求工程和系統(tǒng)開(kāi)發(fā)過(guò)程?？尚行匝芯恐饕性诮?jīng)濟(jì)可行性、技術(shù)可行性、法律可行性和方案決策幾個(gè)部分?？尚行匝芯侩A段最終應(yīng)形成可行性研究報(bào)告，并提交給項(xiàng)目管理部門(mén)進(jìn)行評(píng)審。報(bào)告的主要內(nèi)容包括：

(1)項(xiàng)目背景：?jiǎn)栴}描述、實(shí)現(xiàn)環(huán)境、限制條件等。

(2)管理說(shuō)明與建議：重要的研究結(jié)果、說(shuō)明、建議和影響。

(3)候選方案：候選系統(tǒng)的配置、選擇最終方案的原則。

(4)系統(tǒng)描述：簡(jiǎn)略的范圍描述、分配元素的可行性。

(5)經(jīng)濟(jì)可行性：成本-效益分析、經(jīng)費(fèi)概算、預(yù)期的經(jīng)濟(jì)效益。

(6)技術(shù)可行性：技術(shù)實(shí)力、已有工作基礎(chǔ)、設(shè)備條件。

(7)法律可行性：系統(tǒng)開(kāi)發(fā)可能導(dǎo)致的侵權(quán)、責(zé)任問(wèn)題。

(8)用戶使用可行性：用戶單位的行政管理、工作制度、用戶素質(zhì)問(wèn)題。

(9)其他與項(xiàng)目有關(guān)的問(wèn)題：其他方案介紹、未來(lái)可能的變化。

4.4需求獲取和分析

需求獲取和分析活動(dòng)要求軟件開(kāi)發(fā)人員和客戶及最終用戶共同找出應(yīng)用域問(wèn)題，包括系統(tǒng)應(yīng)提供的服務(wù)、系統(tǒng)需要的性能、硬件和軟件的限制等。軟件開(kāi)發(fā)機(jī)構(gòu)的需求分析人員必須具有一定需求獲取、需求建模、問(wèn)題抽象與分解技術(shù)，這樣方可有效地完成本階段的任務(wù)。一般來(lái)說(shuō)主要包含以下一些活動(dòng)：

(1)應(yīng)用問(wèn)題理解：分析人員必須對(duì)系統(tǒng)應(yīng)用領(lǐng)域進(jìn)行充分理解。

(2)需求收集：與相關(guān)人員充分交流以發(fā)現(xiàn)需求。

(3)分類：對(duì)收集到的需求信息進(jìn)行整理和歸類。

(4)沖突避免：原始的需求信息之間不可避免地會(huì)存在沖突問(wèn)題，活動(dòng)致力于發(fā)現(xiàn)和解決沖突。

(5)優(yōu)先級(jí)確立：分清需求的層次和重要性，據(jù)此確定需求的優(yōu)先級(jí)。

(6)需求檢驗(yàn)：對(duì)需求的完整性、一致性以及是否反映用戶的真實(shí)期望進(jìn)行檢驗(yàn)。需求獲取時(shí)可以將需求分成三種類型：

(1)必須滿足的需求。

(2)期望有的需求但不是必須的。

(3)可能需要但可以去除的需求。

圖4.2示意出需求可能的來(lái)源，可以以多種方式獲得。圖4.2需求來(lái)源需求獲取的目的是通過(guò)一系列與用戶的交流充分挖掘需求，獲取用戶對(duì)軟件系統(tǒng)要求的第一手資料，并理解這些需求，得到什么是用戶想要的。與系統(tǒng)需求有直接或間接關(guān)系的最終用戶、事務(wù)管理人員、應(yīng)用領(lǐng)域?qū)＜?、系統(tǒng)開(kāi)發(fā)人員都應(yīng)參與需求獲取和分析工作。需求獲取可以通過(guò)評(píng)審當(dāng)前的工作模式、與用戶共同討論、理解問(wèn)題、通過(guò)已有的相關(guān)文檔挖掘、制作系統(tǒng)工作的視頻、觀察相似系統(tǒng)、制作原型系統(tǒng)等方式展開(kāi)。4.4.1用戶交流

需求獲取的主要途徑是與用戶充分地交流以獲取需求相關(guān)信息，主要包括用戶訪談、問(wèn)卷調(diào)查、聯(lián)合會(huì)議、用戶業(yè)務(wù)觀察、定期交流等活動(dòng)。

用戶訪談是需求獲取不可缺少的活動(dòng)，需求分析人員一般應(yīng)預(yù)先準(zhǔn)備一些問(wèn)題，記錄并整理用戶對(duì)問(wèn)題的回答，獲取用戶對(duì)目標(biāo)軟件的需求。表4.5列出了訪談應(yīng)關(guān)注的問(wèn)題和關(guān)鍵部分。4.4.2基于用例的需求獲取

1．確定參與者

與ATM系統(tǒng)存在交互的參與者包括銀行客戶、ATM管理者、銀行數(shù)據(jù)庫(kù)系統(tǒng)。銀行客戶與ATM之間存在著服務(wù)請(qǐng)求和服務(wù)結(jié)果的反饋；ATM管理者需要借助與ATM的交互完成相應(yīng)的管理活動(dòng)，如加入現(xiàn)金、診斷系統(tǒng)等；ATM則在處理與用戶的交易時(shí)與銀行的數(shù)據(jù)庫(kù)系統(tǒng)產(chǎn)生交互，包括驗(yàn)證用戶、記錄交易信息等。確定參與者還應(yīng)區(qū)分主要的和次要的參與者。

2．確定用例

Jacobson建議通過(guò)提出如下的問(wèn)題確定用例：

(1)參與者的目標(biāo)是什么？

(2)系統(tǒng)事件開(kāi)始前有什么前提條件？

(3)參與者完成的主要工作或功能是什么？

(4)還需要考慮什么異常？

(5)參與者的交互中有什么可能的變化？

(6)參與者將獲得、產(chǎn)生或改變哪些系統(tǒng)信息？

(7)參與者必須通知系統(tǒng)外部環(huán)境的改變嗎？

(8)參與者希望從系統(tǒng)獲取什么信息？

(9)參與者希望得知意料之外的變更嗎？

3．構(gòu)建用例模型

將參與者和用例之間的交互關(guān)系在用例圖上標(biāo)識(shí)出來(lái)，并可進(jìn)一步標(biāo)識(shí)這些元素之間的結(jié)構(gòu)關(guān)系，如泛化關(guān)系等。圖4.3是ATM機(jī)的用例模型圖。圖4.3ATM機(jī)的用例模型圖

4．用例描述

一種采用腳本形式的ATM取款用例描述：

●用例任務(wù)：允許銀行客戶通過(guò)ATM系統(tǒng)取款；

●用例啟動(dòng)：當(dāng)合法銀行用戶對(duì)ATM機(jī)發(fā)出取款請(qǐng)求后，用例啟動(dòng)；

●基本事件流：系統(tǒng)請(qǐng)求用戶輸入取款金額，系統(tǒng)驗(yàn)證金額是否符合一次可存取限額，系統(tǒng)驗(yàn)證用戶賬戶余額是否足夠支取，滿足支取條件，控制ATM吐出現(xiàn)金，打印交易單，提示進(jìn)一步取款或退出的操作信息；●不滿足支取條件事件流：系統(tǒng)顯示提示不能支取的信息和退出取款流程的信息；

●結(jié)束用例：用戶發(fā)出取消的請(qǐng)求。

基于用例的需求獲取方法是建立在UML的基礎(chǔ)上的，因此它為面向?qū)ο蟮姆治雠c設(shè)計(jì)提供了良好的基礎(chǔ)，在后面的章節(jié)中，我們將介紹基于用例模型的對(duì)象分析和設(shè)計(jì)。4.4.3原型化方法

在前面已介紹過(guò)演化式開(kāi)發(fā)模式，我們也可以將快速原型的的思想用于需求的發(fā)現(xiàn)。原型方法的核心思想是：根據(jù)用戶對(duì)需求的概要性描述，快速建立一個(gè)目標(biāo)系統(tǒng)原型，讓用戶可以盡早接觸到軟件系統(tǒng)的面貌，對(duì)其進(jìn)行評(píng)價(jià)，引導(dǎo)用戶挖掘更多的需求，通過(guò)對(duì)用戶意見(jiàn)的修改，確定最后的需求目標(biāo)。例如對(duì)于一個(gè)有著眾多人機(jī)交互的辦公系統(tǒng)，用戶無(wú)使用相似系統(tǒng)的經(jīng)驗(yàn)，項(xiàng)目之初對(duì)人機(jī)交互的方式并不能提出具體的要求，則可以通過(guò)原型化方法，幫助挖掘出令用戶滿意的需求。

原型方法的關(guān)鍵是借助系統(tǒng)原型啟發(fā)用戶發(fā)現(xiàn)需求，是一種重要的需求獲取手段。4.4.4需求分析

需求分析要對(duì)收集到的需求進(jìn)行提煉、分析和認(rèn)真審查，以確保所有的項(xiàng)目相關(guān)人員都明白其含義，并找出其中的錯(cuò)誤、遺漏或其他不足的地方，形成完整的分析模型。需求分析的核心在于建立分析模型。分析模型應(yīng)詳細(xì)、準(zhǔn)確地定義系統(tǒng)的需求，通常采用數(shù)據(jù)流圖、實(shí)體關(guān)系圖、狀態(tài)轉(zhuǎn)換圖、用例圖、順序圖、協(xié)作圖、類圖等來(lái)定義需求。

圖4.4是ATM系統(tǒng)用戶取款的順序圖。圖4.4ATM系統(tǒng)“取款”用例時(shí)序圖

4.5需求定義

需求定義階段的工作就是以分析模型為基礎(chǔ)，形成完整的需求定義文檔(即需求規(guī)格說(shuō)明)，為設(shè)計(jì)提供基礎(chǔ)，也為軟件測(cè)試和確認(rèn)及維護(hù)提供依據(jù)。4.5.1需求描述方式

1．自然語(yǔ)言

自然語(yǔ)言具有易理解的特點(diǎn)，但描述軟件需求一般不夠準(zhǔn)確，可能造成理解上的出入，這將給軟件開(kāi)發(fā)過(guò)程后期的活動(dòng)帶來(lái)麻煩，長(zhǎng)篇的文字也會(huì)導(dǎo)致結(jié)構(gòu)不清晰，可讀性差。一種良好的改善方法是采用需求定義模板，這種描述采用標(biāo)準(zhǔn)形式和模板表達(dá)需求，使得需求的描述更加清晰、可讀。

下面是一個(gè)無(wú)人值守氣象站向中心氣象站發(fā)送氣象數(shù)據(jù)的需求描述。表4.6列出了需求定義模板所描述的需求文檔。例4.1一個(gè)氣象站系統(tǒng)需要管理各類氣象數(shù)據(jù)檢測(cè)儀器，根據(jù)氣象中心的要求，通過(guò)遠(yuǎn)程通信設(shè)備Modem將數(shù)據(jù)匯總發(fā)送到氣象中心主機(jī)數(shù)據(jù)收集子系統(tǒng)，以形成報(bào)表和地圖。數(shù)據(jù)來(lái)自氣象監(jiān)測(cè)儀，每5分鐘監(jiān)測(cè)一次，包括氣溫、氣壓、風(fēng)力、風(fēng)速、雨量的最大值、最小值和平均值。數(shù)據(jù)的匯總和上傳每小時(shí)一次，但今后可以修改。

2．結(jié)構(gòu)化語(yǔ)言

結(jié)構(gòu)化語(yǔ)言用帶有抽象性質(zhì)的類程序設(shè)計(jì)語(yǔ)言描述需求，結(jié)合了自然語(yǔ)言的易理解性和程序設(shè)計(jì)語(yǔ)言的語(yǔ)法。例如：

Validation()

{

Inputcash_amountfrompanel

Ifaccount_balance>=cash_amount+10

{outputcash}

Else

{Display"Notenoughmoney"}

}

3．可視化模型語(yǔ)言

可視化模型通常用圖形直觀地描述需求，作為文本描述的補(bǔ)充工具，一般用于更好地理解需求。常見(jiàn)的可視化模型如數(shù)據(jù)流模型、實(shí)體關(guān)系模型、類圖等。目前主要采用UML來(lái)建立面向?qū)ο笙到y(tǒng)的需求模型。如圖4.5為ATM系統(tǒng)的狀態(tài)轉(zhuǎn)移模型。圖4.5ATM系統(tǒng)的狀態(tài)轉(zhuǎn)移模型

4．形式語(yǔ)言

形式語(yǔ)言是基于數(shù)學(xué)定義的方法，如有限狀態(tài)機(jī)、圖論等。這是一種不會(huì)引起歧義的定義方法，用于精確描述系統(tǒng)的屬性，常用的形式化描述方法有Petri網(wǎng)、Z語(yǔ)言等，將在以后的章節(jié)詳細(xì)討論。形式化描述方法具有精確、嚴(yán)謹(jǐn)?shù)奶攸c(diǎn)，但不易被理解，對(duì)軟件人員有較高的要求，通常在一些可靠性和安全性要求較高的系統(tǒng)中使用。4.5.2軟件需求規(guī)格說(shuō)明

一般來(lái)說(shuō)，需求規(guī)格說(shuō)明應(yīng)該包括用戶需求和系統(tǒng)需求，某些情況下也可以合二為一。用戶需求采用用戶可理解的自然語(yǔ)言和圖來(lái)描述(requirementdefinition)，系統(tǒng)需求則是更為精確，詳細(xì)的需求規(guī)格說(shuō)明(requirementspecification)是開(kāi)發(fā)人員設(shè)計(jì)的基礎(chǔ)。軟件需求規(guī)格說(shuō)明應(yīng)包含功能性行為需求描述以及非功能性行為需求描述，Heninger(1980)提出軟件需求文檔應(yīng)滿足以下內(nèi)容：

●定義外部系統(tǒng)行為

●定義實(shí)現(xiàn)時(shí)的限制

●易于修改

●可以作為系統(tǒng)維護(hù)的參考

●提出對(duì)系統(tǒng)生存期的預(yù)想

●指明對(duì)不期望的事件可接受的響應(yīng)通常需求規(guī)格說(shuō)明要包含以下一些項(xiàng)目：

●物理環(huán)境：功能所需要的設(shè)備處于何處，是否只在一個(gè)位置，環(huán)境是否有限制，例如溫度、濕度等。

●接口：輸入是否來(lái)自一個(gè)或多個(gè)其他系統(tǒng)； 輸出是否到一個(gè)或多個(gè)系統(tǒng)；數(shù)據(jù)是否有規(guī)定的格式；數(shù)據(jù)是否要使用規(guī)定的介質(zhì)。

●用戶和人的因素：誰(shuí)使用系統(tǒng)；是否有多種類型的用戶；每一類用戶的技能水平；用戶需要什么樣的訓(xùn)練；對(duì)用戶來(lái)講理解和使用用戶的難易程度。●功能：系統(tǒng)應(yīng)該做什么？何時(shí)做？ 系統(tǒng)操作是否需要多種模式；系統(tǒng)怎樣可以改變或擴(kuò)展； 在執(zhí)行速度、響應(yīng)時(shí)間、吞吐量上有何要求。

●文檔：需要什么文檔？文檔的形式，在線閱讀、書(shū)的形式，還是兩者皆有；文檔的閱讀對(duì)象是誰(shuí)？

●數(shù)據(jù)：什么是數(shù)據(jù)的輸入和輸出的格式；發(fā)送或接收數(shù)據(jù)的頻率；數(shù)據(jù)的精確度；通過(guò)系統(tǒng)的數(shù)據(jù)流；數(shù)據(jù)保留的時(shí)間。

●資源：構(gòu)建、使用和維護(hù)系統(tǒng)需要的物資、人員和其他資源；開(kāi)發(fā)者必須具有的技能； 系統(tǒng)占有的物理空間；是否需要?jiǎng)恿?、空調(diào)和加熱設(shè)備；是否有開(kāi)發(fā)時(shí)間限制；是否有成本、軟硬件的限制?！癜踩裕菏欠癖仨毧刂茖?duì)系統(tǒng)和信息的訪問(wèn)；用戶之間的數(shù)據(jù)是否必須隔離；用戶程序是否必須與其他程序和操作系統(tǒng)隔離；系統(tǒng)備份的時(shí)間；是否需要在不同地點(diǎn)備份；是否需要考慮意外災(zāi)害，比如水、火災(zāi)等。

●質(zhì)量保證：可靠性、有效性、可維護(hù)性、安全性和其他質(zhì)量屬性的要求；故障間隔的要求；系統(tǒng)是否必須檢測(cè)和隔離錯(cuò)誤；系統(tǒng)失效后最大重啟時(shí)間；系統(tǒng)如何適應(yīng)設(shè)計(jì)的變化；維護(hù)僅需考慮糾正錯(cuò)誤還是需考慮改善系統(tǒng)；對(duì)資源使用和有效響應(yīng)、時(shí)間的度量；系統(tǒng)可移植性要求。以下是IEEE建議的需求文檔結(jié)構(gòu)。其中特定需求是文檔中最核心內(nèi)容，由于各個(gè)軟件組織的軟件活動(dòng)各有不同，因此很難定義標(biāo)準(zhǔn)的結(jié)構(gòu)。但系統(tǒng)的功能、性能、邏輯數(shù)據(jù)庫(kù)需求、設(shè)計(jì)限制、質(zhì)量特性以及應(yīng)急機(jī)制都應(yīng)包含其中。

4.6需求驗(yàn)證

需求驗(yàn)證也稱為需求評(píng)審，是檢驗(yàn)需求規(guī)格說(shuō)明是否滿足用戶實(shí)際需求的活動(dòng)。在將需求規(guī)格說(shuō)明書(shū)提交之前，必須進(jìn)行需求評(píng)審。若需求文檔中的錯(cuò)誤在后期的開(kāi)發(fā)中被發(fā)現(xiàn)，將會(huì)帶來(lái)額外的重新開(kāi)發(fā)的代價(jià)，除了會(huì)增加系統(tǒng)的成本，也會(huì)給軟件質(zhì)量和按時(shí)交付帶來(lái)壓力。正確性檢驗(yàn)。檢驗(yàn)需求規(guī)格說(shuō)明對(duì)系統(tǒng)功能、行為、性能及其他屬性的描述是否滿足用戶的期望。不同的用戶對(duì)需求有不同的要求，通過(guò)檢驗(yàn)可以和用戶達(dá)成共識(shí)，并有助于發(fā)現(xiàn)用戶的其他所需的功能。

●完整性檢驗(yàn)：需求規(guī)格說(shuō)明應(yīng)包含用戶所需的所有功能、行為和性能約束，不能有遺漏。

●一致性檢驗(yàn)：檢驗(yàn)系統(tǒng)各個(gè)需求的描述是否存在互相矛盾的地方，功能需求、非功能需求、行為特征、術(shù)語(yǔ)、時(shí)序定義都不應(yīng)存在沖突。●無(wú)歧義性：對(duì)于用戶和軟件人員而言，需求規(guī)格說(shuō)明中的任何表達(dá)只能有唯一的語(yǔ)義。確保無(wú)歧義性的有效方法是使用標(biāo)準(zhǔn)化術(shù)語(yǔ)和模型，并對(duì)它們有統(tǒng)一、明確的解釋。

●可理解性：對(duì)于用戶和軟件人員而言，需求規(guī)格說(shuō)明的表達(dá)易于理解。對(duì)于非專業(yè)的用戶來(lái)說(shuō)，不宜在用戶需求中使用過(guò)多的專業(yè)化術(shù)語(yǔ)。

●可修改性：需求規(guī)格說(shuō)明的格式和組織應(yīng)能易于后期需求變化時(shí)的修改，使修改后的說(shuō)明書(shū)可較好地保持原有特性。

●實(shí)現(xiàn)性檢驗(yàn)：確認(rèn)運(yùn)用已有的技術(shù)和知識(shí)是否能確保系統(tǒng)順利實(shí)現(xiàn)?！窨勺粉櫺裕盒枨笠?guī)格說(shuō)明中定義的每項(xiàng)需求都能與原始需求的來(lái)源有著清晰的關(guān)聯(lián)，便于追蹤。例如，ATM的診斷功能需求最初來(lái)自與銀行系統(tǒng)管理員的一次面談?dòng)涗洝?/p>

●可驗(yàn)證性：需求的定義應(yīng)是可驗(yàn)證的，并且可以避免客戶和開(kāi)發(fā)者之間產(chǎn)生爭(zhēng)議。應(yīng)該具有檢查手段來(lái)說(shuō)明交付的系統(tǒng)可以滿足用戶需求。評(píng)審可以圍繞以下問(wèn)題進(jìn)行展開(kāi)：

(1)軟件說(shuō)明的目標(biāo)和對(duì)象與系統(tǒng)的目標(biāo)和對(duì)象是否一致?

(2)所有系統(tǒng)元素的重要接口是否已經(jīng)給出?

(3)信息流和信息結(jié)構(gòu)是否滿足所定義的問(wèn)題域?

(4)圖示是否清晰？如果每一個(gè)圖示沒(méi)有輔助說(shuō)明，能獨(dú)立使用嗎?

(5)每一個(gè)包含在工作域內(nèi)的主要功能描述是否充分?

(6)軟件的行為是否與其必須處理的信息和必須完成的功能相一致?

(7)設(shè)計(jì)限制是否實(shí)際？

(8)開(kāi)發(fā)的技術(shù)風(fēng)險(xiǎn)是什么?

(9)是否已經(jīng)考慮了另一個(gè)可供選擇的軟件需求?

(10)是否已經(jīng)詳細(xì)說(shuō)明了確認(rèn)準(zhǔn)則？它們能滿足一個(gè)成功的系統(tǒng)所要求的描述嗎?

(11)是否存在不一致性(inconsistencies)、遺漏(omissions)和冗余(redundancy)?

(12)是否完成了與用戶的溝通?

(13)用戶已經(jīng)評(píng)審了初步的用戶手冊(cè)嗎?

(14)對(duì)軟件項(xiàng)目計(jì)劃中所建立的各種估算有影響嗎?

4.7案例

本節(jié)將結(jié)合一個(gè)理財(cái)管理系統(tǒng)的實(shí)例，討論基于用例的需求獲取方法。這里采用以下步驟實(shí)現(xiàn)該系統(tǒng)的需求獲取和用例建模：

(1)確定系統(tǒng)的參與者。

(2)確定用例。

(3)構(gòu)建用例模型。

(4)用例描述。下面是關(guān)于“理財(cái)管理系統(tǒng)iricher”的問(wèn)題描述：

用戶在“理財(cái)管理系統(tǒng)iricher”注冊(cè)后，系統(tǒng)通過(guò)注冊(cè)的Email給用戶發(fā)送一個(gè)密碼。注冊(cè)用戶可以使用自己的用戶名和密碼登錄；登錄后可以使用此系統(tǒng)記錄日常的收支、管理自己的每個(gè)銀行卡賬戶信息、輸入理財(cái)預(yù)算、管理個(gè)人信息。該系統(tǒng)應(yīng)該在Internet環(huán)境下運(yùn)行，用戶通過(guò)瀏覽器瀏覽。要求用戶界面友好、響應(yīng)速度快，具有良好的可擴(kuò)展性。

(1)確定參與者。在“理財(cái)管理系統(tǒng)iricher”例子中，可以確定任何一個(gè)網(wǎng)絡(luò)“用戶”是該系統(tǒng)的主動(dòng)參與者，他使用系統(tǒng)的主要功能；另外用戶注冊(cè)后需要使用外部的“郵件系統(tǒng)”通知注冊(cè)用戶的密碼，如圖4.6所示。圖4.6iricher系統(tǒng)的參與者

(2)確定用例。如果基本系統(tǒng)的所有功能都提供給注冊(cè)用戶使用，那么與注冊(cè)用戶有關(guān)的用例是登錄、日常的收支、管理銀行賬戶、輸入理財(cái)預(yù)算、管理個(gè)人信息、管理家庭成員信息；與普通用戶有關(guān)的用例是注冊(cè)；與郵件系統(tǒng)有關(guān)的用例是注冊(cè)。

(3)構(gòu)建用例模型。確定iricher系統(tǒng)的用戶和用例之間的關(guān)系，如圖4.7所示。圖4.7iricher系統(tǒng)用例圖

(4)用例描述。此處我們給出采用腳本形式的iricher系統(tǒng)“記錄