軟件工程課件：第4章 需求工程

1、1第4章 需求工程 2第4章 需求工程 需求工程：確定系統(tǒng)需要的服務(wù)以及運(yùn)行與開發(fā)中所受約束的過程。對需求的收集、分析、定義和驗(yàn)證的過程被稱之為需求工程 3成功來之不易（補(bǔ)充）4軟件項(xiàng)目失敗的原因（補(bǔ)充）5糾正需求錯誤的成本（補(bǔ)充）64.1 軟件需求IEEE給出了如下關(guān)于軟件需求的定義： 用戶解決問題或達(dá)到目標(biāo)所需的條件或能力； 系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其他正式規(guī)定文檔所需具有的條件或能力； 一種反映或所描述的條件或能力的說明。對定義的理解軟件需求的概念涵蓋了用戶角度（系統(tǒng)的外部行為）和開發(fā)人員角度（系統(tǒng)的內(nèi)部特性）兩個方面，其中的關(guān)鍵在于需求一定要文檔化。7軟件需求的重要性軟件

2、需求是決定軟件開發(fā)是否成功的一個關(guān)鍵因素需求分析可以幫助開發(fā)人員真正理解業(yè)務(wù)問題需求分析是估算成本和進(jìn)度的基礎(chǔ)需求分析可以避免建造錯誤的系統(tǒng)，從而減少不必要的浪費(fèi)軟件規(guī)格說明有助于開發(fā)人員與客戶在“系統(tǒng)應(yīng)該做什么”問題上達(dá)成正式契約需求分析形成了軟件開發(fā)的基線，有助于管理軟件的演化和 變更軟件需求是軟件質(zhì)量的基礎(chǔ)，為系統(tǒng)驗(yàn)收測試提供了標(biāo)準(zhǔn)8不同層次的軟件需求業(yè)務(wù)需求：確定軟件產(chǎn)品的發(fā)展方 向、功能范圍、目標(biāo)客戶和價值來源用戶需求：反映了用戶使用該系統(tǒng)要完成什么任務(wù) 系統(tǒng)需求：面向開發(fā)人員，一般用模型（對象模型、數(shù)據(jù)模型和狀態(tài)模型等）描述系統(tǒng)應(yīng)該做什么功能需求：描述系統(tǒng)應(yīng)該提供的功能和服務(wù)，一般

3、不考慮系統(tǒng)的實(shí)現(xiàn)細(xì)節(jié)非功能需求：描述對系統(tǒng)的約束和限制9業(yè)務(wù)需求（補(bǔ)充）（P61）業(yè)務(wù)需求是組織或客戶對于系統(tǒng)的高層次目標(biāo)要求， 定義了項(xiàng)目的遠(yuǎn)景和范圍，即確定軟件產(chǎn)品的發(fā)展方向、功能范圍、目標(biāo)客戶和價值來源。業(yè)務(wù)需求的內(nèi)容業(yè)務(wù)：產(chǎn)品屬于哪類業(yè)務(wù)范疇？應(yīng)該完成什么功能？需要為 什么服務(wù)？客戶：產(chǎn)品為誰服務(wù)？目標(biāo)客戶是誰？特性：產(chǎn)品區(qū)別于其他競爭產(chǎn)品的特性是什么？價值：產(chǎn)品的價值體現(xiàn)在什么方面？優(yōu)先級：產(chǎn)品功能特性的優(yōu)先級次序是什么？ 10業(yè)務(wù)需求：MiniLibrary業(yè)務(wù)要求各種圖書資料的借閱、查詢和管理；（項(xiàng)目范圍）使用計(jì)算機(jī)實(shí)現(xiàn)圖書資料的日常管理，提高工作效率和服務(wù)質(zhì)量；（完成功能）用戶

4、通過網(wǎng)絡(luò)查詢和瀏覽電子資料，改變原有的借閱模式；（完成功能）由于版權(quán)的限制，某些電子資料只能讓用戶瀏覽和打印而不 能下載。（完成功能）客戶與用戶學(xué)院的高層管理者圖書管理員借閱者：教師、學(xué)生參考網(wǎng)上資料：業(yè)務(wù)需求文檔的參考模板114.1.1 用戶需求和系統(tǒng)需求用戶需求是從用戶角度描述的系統(tǒng)功能需求和非功能需求，通常只涉及系統(tǒng)的外部行為，而不涉及系統(tǒng)的內(nèi)部特性。用戶需求的描述原則：應(yīng)該易于用戶的理解。一般不采用技術(shù)性很強(qiáng)的語言，而是采用自然語言和直觀圖形相結(jié)合的方式進(jìn)行描述。問題：自然語言表達(dá)容易含糊和不準(zhǔn)確。124.1.1 用戶需求：MiniLibrary舉例：用戶可以通過 Internet 隨

5、時查詢圖書信息和個人借閱情況，并可以快捷地查找和瀏覽所需要的電子資料。分析：上述需求描述包含了三個不同的需求用戶可以通過 Internet 隨時查詢圖書信息。用戶可以通過 Internet 隨時查詢個人借閱情況。用戶可以通過 Internet 快捷地查找和瀏覽所需要的電子資料。問題：“隨時”和“快捷”是對系統(tǒng)功能的約束，十分模糊。13提問4-1請說明用戶需求的定義，用戶需求描述存在的問題144.1.1 用戶需求和系統(tǒng)需求系統(tǒng)需求是更加詳細(xì)地描述系統(tǒng)應(yīng)該做什么，通常包括許多不同的分析模型，諸如對象模型、數(shù)據(jù)模型、 狀態(tài)模型等。系統(tǒng)需求模型的描述結(jié)構(gòu)化英語（ PDL ）：一種介于自然語言和形式化語

6、言之間的半形式語言可視化模型：圖形化符號加文本注釋定義系統(tǒng)模型，如數(shù)據(jù)流圖，UML語言，實(shí)體關(guān)系圖等形式化方法：用數(shù)學(xué)概念描述的系統(tǒng)模型系統(tǒng)需求主要是面向開發(fā)人員進(jìn)行描述，是開發(fā)人員進(jìn)行軟件設(shè)計(jì)的基礎(chǔ)。154.1.1 用戶需求和系統(tǒng)需求164.1.2 功能性需求和非功能性需求功能需求描述系統(tǒng)應(yīng)該提供的功能或服務(wù)，通常涉及用戶或外部系統(tǒng) 與該系統(tǒng)之間的交互，一般不考慮系統(tǒng)的實(shí)現(xiàn)細(xì)節(jié)。舉例：MiniLibrary用戶可以從圖書資料庫中查詢或者選擇其中的一個子集。系統(tǒng)可以提供適當(dāng)?shù)臑g覽器供用戶閱讀電子文獻(xiàn)。用戶每次借閱圖書應(yīng)該對應(yīng)一個唯一的標(biāo)識號，它被記錄到 用戶的帳戶上。174.1.2 非功能需求

7、非功能需求從各個角度對系統(tǒng)的約束和限制，反映了應(yīng)用對軟件系統(tǒng)質(zhì)量和特性的額外要求，例如響應(yīng)時間、數(shù)據(jù)精度、可靠性、 開發(fā)過程的標(biāo)準(zhǔn)等。舉例：MiniLibrary系統(tǒng)應(yīng)在 20 秒之內(nèi)響應(yīng)所有的請求。系統(tǒng)每周 7 天、每天 24 小時都可以使用。對于一個沒有經(jīng)驗(yàn)的用戶而言，經(jīng)過兩個小時的培訓(xùn)就可以使用系統(tǒng)的所有功能。18非功能需求（表4.3）19非功能需求（表4.4，驗(yàn)證表4.3）204.2 需求工程過程需求工程過程活動是對需求的收集、分析、定義和驗(yàn)證的過程 214.3 可行性研究目的：降低系統(tǒng)開發(fā)風(fēng)險。方法：從時間、資金、軟硬件、技術(shù)、人員等資源角度出發(fā)，進(jìn)行可行性研究，形成的可行性研究報告

8、用于決定是否要開展進(jìn)一步的需求工程和系統(tǒng)開發(fā)過程?？尚行匝芯恐饕性诮?jīng)濟(jì)可行性、技術(shù)可行性、法律可行性和方案決策幾個部分。224.3 可行性研究經(jīng)濟(jì)可行性研究：進(jìn)行開發(fā)成本的估算及可能取得效益的評估估算開發(fā)的成本是否會超過項(xiàng)目預(yù)期的利潤分析項(xiàng)目對其他產(chǎn)品或利潤的影響以確定待開發(fā)的系統(tǒng)是否值得投資開發(fā)234.3 可行性研究技術(shù)可行性：對待開發(fā)的系統(tǒng)進(jìn)行功能、性能和限制條件的分析確定在現(xiàn)有的資源（硬件、軟件、技術(shù)人員等）條件下，技術(shù)風(fēng)險有多大，系統(tǒng)是否能實(shí)現(xiàn)主要要考慮開發(fā)的風(fēng)險、資源的有效性和技術(shù)支持等因素。對于開發(fā)的風(fēng)險，主要考慮在給出的限制范圍內(nèi)，能否設(shè)計(jì)出系統(tǒng)，并實(shí)現(xiàn)必需的功能和性能；資源

9、的有效性方面主要關(guān)注可用于開發(fā)系統(tǒng)元素的人員是否存在問題，以及可用于建立系統(tǒng)的其他資源是否具備等問題；技術(shù)支持方面考察相關(guān)的技術(shù)發(fā)展水平是否能支持這個系統(tǒng)。244.3 可行性研究法律可行性：確認(rèn)待開發(fā)系統(tǒng)可能會涉及的任何法律問題，包括軟件過程中可能涉及的各種合同、侵權(quán)、責(zé)任等。方案決策：對系統(tǒng)的不同方案進(jìn)行評估并選擇可行的方案，在此過程中，成本、時間等問題也應(yīng)考慮在內(nèi)。254.3 可行性研究可行性研究階段工作的開展主要是相關(guān)信息的收集、評價和可行性報告的撰寫。信息主要來源于使用系統(tǒng)的管理者、熟悉系統(tǒng)類型的軟件工程師、技術(shù)專家和最終用戶?？尚行匝芯侩A段最終應(yīng)形成可行性研究報告，并提交給項(xiàng)目管理部

10、門進(jìn)行評審。 264.4 需求獲取和分析需求獲取主要涉及到聆聽用戶的需求，分析和整理所獲取的信息，形成文檔化的描述。需求獲取的困難用戶通常并不真正知道自己希望計(jì)算機(jī)系統(tǒng)做什么用戶通常使用業(yè)務(wù)語言表達(dá)需求，開發(fā)人員缺乏相關(guān)的領(lǐng)域知識和經(jīng)驗(yàn)，難以準(zhǔn)確理解這些需求不同的用戶提出不同的需求，可能存在矛盾和沖突管理者可能出于增加影響力的原因而提出特別的需求由于經(jīng)濟(jì)和業(yè)務(wù)環(huán)境的動態(tài)性，需求經(jīng)常發(fā)生變更274.4 需求獲取和分析（P63)284.4 需求獲取和分析需求獲取技術(shù)需求獲取的關(guān)鍵在于通過與用戶的溝通和交流，收集 和理解用戶的各項(xiàng)要求。常見的需求獲取技術(shù)用戶交流（4.4.1）基于用例的方法（4.4.

11、2）原型化方法（4.4.3）294.4.1用戶交流主要包括用戶訪談（面談）、問卷調(diào)查、聯(lián)合會議、用戶業(yè)務(wù)觀察、定期的交流等活動。面談過程需要認(rèn)真的計(jì)劃和準(zhǔn)備面談之前確立面談目的確定要包括的相關(guān)用戶確定參加會議的項(xiàng)目小組成員建立要討論的問題和要點(diǎn)列表復(fù)查有關(guān)文檔和資料確立時間和地點(diǎn)通知所有參加者有關(guān)會議的目的、時間和地點(diǎn)304.4.1用戶交流面談過程需要認(rèn)真的計(jì)劃和準(zhǔn)備（續(xù)）進(jìn)行面談衣著得體，準(zhǔn)時到達(dá)尋找異常和錯誤情況深入調(diào)查細(xì)節(jié)詳細(xì)記錄指出和記錄下未回答條目和未解決問題面談之后復(fù)查筆記的準(zhǔn)確性、完整性和可理解性把所收集的信息轉(zhuǎn)化為適當(dāng)?shù)哪Ｐ秃臀臋n確定需要進(jìn)一步澄清的問題域適當(dāng)?shù)臅r候向參加會議的

12、每一個人發(fā)一封感謝信314.4.2基于用例的需求獲取 基于用例的需求獲取方法主要包括確定參與者（Actor）、確定用例、建立用例模型和描述用例等活動。324.4.2基于用例的需求獲取確定參與者：參與者是與系統(tǒng)交互的外部實(shí)體，它既可以是人員也 可以是外部系統(tǒng)或硬件設(shè)備。確定參與者的方法：誰使用系統(tǒng)的主要功能？誰需要系統(tǒng)的支持以完成日常工作任務(wù)？誰從系統(tǒng)獲取信息？誰負(fù)責(zé)維護(hù)和管理系統(tǒng)以保證其正常運(yùn)行？系統(tǒng)需要應(yīng)付（處理）哪些外部硬件設(shè)備？系統(tǒng)需要和哪些外部系統(tǒng)交互？33MiniLibrary：參與者344.4.2基于用例的需求獲取2、確定用例用例是從用戶角度描述系統(tǒng)的行為，它將系統(tǒng)的一個功能描述成

13、一系列動作序列，這些動作最終對參與者產(chǎn)生有價值的可觀測結(jié)果。確定用例參與者需要從系統(tǒng)中獲得什么功能？參與者需要做什么？參與者讀取、產(chǎn)生、刪除、修改或存儲系統(tǒng)的某些信息嗎？系統(tǒng)中發(fā)生事件需要通知參與者嗎？參與者需要通知系統(tǒng)某件事情嗎？系統(tǒng)的輸入/輸出信息是什么？這些信息從哪兒來到哪兒去？采用什么實(shí)現(xiàn)方法滿足某些特殊要求？35確定用例可觀測用例止于系統(tǒng)邊界，描述交互而不是內(nèi)在系統(tǒng)活動。結(jié)果值用例是目標(biāo)導(dǎo)向的，參與者有一些需要使用它來滿足的目標(biāo)。系統(tǒng)執(zhí)行結(jié)果值由系統(tǒng)生成由角色觀測業(yè)務(wù)語言（圖書），而非技術(shù)語言（數(shù)據(jù)庫表）用戶觀點(diǎn)（預(yù)訂圖書），而非系統(tǒng)觀點(diǎn)（處理預(yù)訂圖書）用例粒度粒度過細(xì)，陷入功能分解

14、。過細(xì)的粒度，一般都會導(dǎo)致技術(shù)語言的描述，而不再是業(yè)務(wù)語言。36MiniLibrary：用例與“圖書管理員”有關(guān)的用例管理讀者：在系統(tǒng)中維護(hù)普通讀者的注冊信息。管理圖書資料：在系統(tǒng)中增加、修改和刪除圖書資料信息。管理書目：在系統(tǒng)中增加、修改和刪除書目信息。登記借書：在系統(tǒng)中登記普通讀者的借書記錄。登記還書：在系統(tǒng)中登記普通讀者的還書記錄。與“普通讀者”有關(guān)的用例預(yù)訂圖書：在系統(tǒng)中預(yù)訂借書。取消預(yù)訂：在系統(tǒng)中取消已有的預(yù)訂。其他登錄：使用此系統(tǒng)的人員需要進(jìn)行登錄，以驗(yàn)證其身份和權(quán)限。瀏覽查詢：用戶可以檢索圖書資料、讀者信息和借還書記錄等。37確定用例的常見問題38確定用例的常見問題用戶觀點(diǎn)還是系

15、統(tǒng)觀點(diǎn)？394.4.2基于用例的需求獲取3、構(gòu)建用例模型將參與者和用例之間的交互關(guān)系在用例圖上標(biāo)識出來，并可進(jìn)一步標(biāo)識這些元素之間的結(jié)構(gòu)關(guān)系，如泛化關(guān)系等，則構(gòu)建了需求的用例模型。 40MiniLibrary：用例圖414.4.2基于用例的需求獲取4、用例描述用例模型對功能和服務(wù)的描述是簡要的，因此通常需要詳細(xì)展開用例，即對用例進(jìn)行描述用例的描述可以以腳本的形式也可采用協(xié)作圖的形式。用例描述主要的內(nèi)容有：用例的最終任務(wù)和結(jié)果用例的啟動不同條件下的用例事件流用例終止條件及其他。42MiniLibrary：登記借書用例：登記借書1.目標(biāo)本用例允許圖書管理員登記普通讀者的借書記錄。2.事件流2.1

16、基本流程當(dāng)普通讀者希望借書，圖書管理員準(zhǔn)備登記有關(guān)的借書記錄時，本用例 開始執(zhí)行。（1）系統(tǒng)請求圖書管理員輸入讀者的注冊號和所借圖書的書目；（2）圖書管理員輸入有關(guān)信息后，系統(tǒng)產(chǎn)生一個唯一的借書記錄號；（3）系統(tǒng)顯示新生成的借書記錄；（4）圖書管理員確認(rèn)后，系統(tǒng)增加一個新的借書記錄。43MiniLibrary：登記借書2.2 可選流程（1）讀者沒有注冊 在主流程中，如果系統(tǒng)中沒有讀者的注冊信息，系統(tǒng)將顯示錯誤信息，用例結(jié)束。（2）所借圖書書目不存在 在主流程中，如果所借圖書已被借出或者系統(tǒng)中沒有該圖書的書目，系統(tǒng)將顯示錯誤信息，用例結(jié)束。3.特殊需求無。4.前提條件用例開始之前，圖書管理員必須

17、在系統(tǒng)登錄成功。5.后置條件如果用例執(zhí)行成功，該讀者的借書記錄被更新，否則系統(tǒng)狀態(tài)不變。444.4.3原型化方法原型化方法一個軟件原型是所提出的新產(chǎn)品的部分實(shí)現(xiàn)，幫助開發(fā)人 員、用戶以及客戶更好地理解系統(tǒng)的需求，它比開發(fā)人員常 用的技術(shù)術(shù)語更易于理解。建立原型的原因解決在產(chǎn)品開發(fā)的早期階段需求不確定的問題，用戶、經(jīng)理 和其他非技術(shù)項(xiàng)目風(fēng)險承擔(dān)者發(fā)現(xiàn)在確定和開發(fā)產(chǎn)品時，原 型可以使他們的想象更具體化?；?WEB 的應(yīng)用系統(tǒng)原型使用 HTML 進(jìn)行界面設(shè)計(jì)454.4.4需求分析需求分析是對收集到的需求進(jìn)行提煉、分析和認(rèn)真審查，以確保所有的項(xiàng)目相關(guān)人員都明白其含義，并找出其中的錯誤、遺漏或其它不足

18、的地方，形成完整的分析模型。需求分析的核心在于建立分析模型模型是現(xiàn)實(shí)世界某些重要方面的表示，是一項(xiàng)經(jīng)過驗(yàn)證且被廣為接受的工程技術(shù)。分析模型詳細(xì)定義了系統(tǒng)需求而沒有局限于具體技術(shù)。事件列表、數(shù)據(jù)流圖、實(shí)體關(guān)系圖、數(shù)據(jù)流定義、數(shù)據(jù)字典、 結(jié)構(gòu)化英語、狀態(tài)轉(zhuǎn)換圖、 用例圖、時序圖、協(xié)作圖、類圖、狀態(tài)圖、 464.4 需求獲取和分析需求分析的過程(補(bǔ)充）定義系統(tǒng)的邊界建立系統(tǒng)與其外部實(shí)體間的界限，明確接口處的信息流。分析需求可行性分析每一個需求實(shí)現(xiàn)的可行性，確定與實(shí)現(xiàn)相關(guān)的開發(fā)風(fēng)險。確定需求優(yōu)先級需求優(yōu)先級有助于開發(fā)組織和版本規(guī)劃。建立需求分析模型通過建立需求的多種視圖，揭示出需求的不正確、不一致、遺

19、漏 和冗余等更深的問題。創(chuàng)建數(shù)據(jù)字典確?？蛻艉烷_發(fā)人員使用一致的定義和術(shù)語。474.5 需求定義需求定義階段的工作就是以分析模型為基礎(chǔ)，形成完整的需求定義文檔即需求規(guī)格說明為設(shè)計(jì)提供基礎(chǔ)，也為軟件測試和確認(rèn)及維護(hù)提供依據(jù)。484.5.1 需求描述方式需求應(yīng)該描述系統(tǒng)的所有部分，包括系統(tǒng)的邊界、系統(tǒng)中的元素及其它們的屬性、元素之間的關(guān)系、可能發(fā)生的事件及其對事件的響應(yīng)。需求描述主要關(guān)注系統(tǒng)的靜態(tài)和動態(tài)屬性。靜態(tài)描述列出系統(tǒng)實(shí)體或?qū)ο蟆?shí)體的屬性、它們能完成的功能和接受的功能、實(shí)體間的關(guān)系。動態(tài)描述是對系統(tǒng)跨越時間的狀態(tài)變化及事件響應(yīng)進(jìn)行的描述。494.5.1 需求描述方式自然語言結(jié)構(gòu)化語言可視化

20、模型語言形式化語言504.5.2 軟件需求規(guī)格說明需求規(guī)格說明（SRS, Software Requirement Specification）精確地闡述一個軟件系統(tǒng)必須提供的功能和性能以及它所要考慮的限制條件。是需求開發(fā)的結(jié)果作用成為用戶、設(shè)計(jì)人員和測試人員之間進(jìn)行理解和交流的手段支持系統(tǒng)測試活動用于規(guī)劃和控制系統(tǒng)的開發(fā)過程51需求規(guī)格說明應(yīng)該包括在 SRS 中的內(nèi)容功能：軟件應(yīng)該提供什么功能？外部接口：軟件如何與人、系統(tǒng)硬件和其他系統(tǒng)等進(jìn)行相互 作用？性能：軟件系統(tǒng)在運(yùn)行速度、可用性、響應(yīng)時間、恢復(fù)時間 等方面有什么要求？特性：軟件系統(tǒng)在可移植性、可維護(hù)性、安全性等方面有什么考慮？設(shè)計(jì)約束

21、：是否存在必要的標(biāo)準(zhǔn)、開發(fā)語言、數(shù)據(jù)庫、資源 限制、運(yùn)行環(huán)境等因素的影響和策略？52SRS 模板534.6需求驗(yàn)證需求驗(yàn)證是確保需求規(guī)格說明準(zhǔn)確、完整的表達(dá)必要的質(zhì)量特點(diǎn)。只對已文檔化的需求驗(yàn)證，未文檔化的不驗(yàn)證。需求驗(yàn)證的技術(shù)需求評審：由不同代表（如分析員、客戶、設(shè)計(jì)人員、測試 人員）組成的評審小組以會議形式對需求進(jìn)行系統(tǒng)性分析。原型評價：客戶和用戶在一個可運(yùn)行的系統(tǒng)模型上實(shí)際檢驗(yàn)系統(tǒng)是否符合他們的真正需要。測試用例生成：通過設(shè)計(jì)具體的測試方法，發(fā)現(xiàn)需求中的許多問題。需求驗(yàn)證主要圍繞需求規(guī)格說明的質(zhì)量特性展開。54需求規(guī)格說明的質(zhì)量特性正確性需求規(guī)格說明對系統(tǒng)功能、行為、性能等的描述必須與用

22、戶的期望相吻合，代表了用戶的真正需求。審查需求的正確性應(yīng)該考慮的問題用戶參與需求過程的程度如何？每一個需求描述是否準(zhǔn)確地反映了用戶的需要？系統(tǒng)用戶是否已經(jīng)認(rèn)真考慮了每一項(xiàng)描述？需求可以追溯到來源嗎？舉例：下面的需求描述正確嗎？在用戶每次存錢的時候系統(tǒng)將進(jìn)行信用檢查。55需求規(guī)格說明的質(zhì)量特性無二義性需求規(guī)格說明中的描述對于所有人都只能有一種明確統(tǒng)一的解釋。審查需求的無二義性應(yīng)該考慮的問題需求規(guī)格說明是否有術(shù)語詞匯表？具有多重含義或未知含義的術(shù)語是否已經(jīng)定義？需求描述是否可量化和可驗(yàn)證？每一項(xiàng)需求都有測試準(zhǔn)則嗎？舉例：下面的需求描述是無歧義的嗎？如果用戶試圖透支，系統(tǒng)將采取適當(dāng)?shù)男袆印?6需求規(guī)

23、格說明的質(zhì)量特性完整性需求規(guī)格說明應(yīng)該包括軟件要完成的全部任務(wù)，不能遺漏任 何必要的需求信息。審查需求的完整性應(yīng)該考慮的問題是否存在遺漏的功能或業(yè)務(wù)過程？在每個定義的功能之間是否有接口？是否有信息或消息在所定義的功能之間傳遞？是否定義了功能的使用者？是否已經(jīng)清楚地定義了用戶與功能之間的交互？是否定義了與外部過程和系統(tǒng)之間的接口？57需求規(guī)格說明的質(zhì)量特性審查需求的完整性應(yīng)該考慮的問題（續(xù)）所描述的功能是否可以映射到業(yè)務(wù)過程中？文檔中是否存在待確定的需求引用？文檔中是否存在未定義的術(shù)語和引用？文檔的各個部分都完整嗎？需求包括非功能屬性的說明嗎？是否考慮了軟件性能？是否考慮了安全性要求？是否考慮了可靠性？是否考慮了系統(tǒng)容量問題？58需求規(guī)格說明的質(zhì)量特性可驗(yàn)證性需求規(guī)格說明中描述的需求都可以運(yùn)用一些可行的手段對其進(jìn)行驗(yàn)證和確認(rèn)。審查需求的可驗(yàn)證性應(yīng)該考慮的問題在需求文檔中是否存在不可驗(yàn)證的陳述，諸如“用戶界面友好”、“容易”、“簡單”、“快速”、“健壯”、“最新技術(shù)”等？所有描述都