第2章需求工程

第2章需求工程領(lǐng)域分析需求獲取需求分析與建模需求規(guī)約與驗(yàn)證需求管理1西安交通大學(xué)劉海巖2.1領(lǐng)域分析1、領(lǐng)域分析的概念軟件工程要處理兩類工程：（1）面向用戶的業(yè)務(wù)過程工程（2）面向市場的產(chǎn)品工程（見下圖）領(lǐng)域(domain)，就是指解決問題的范圍，從最高層的角度（業(yè)務(wù)域）描述系統(tǒng)。系統(tǒng)分析可以發(fā)生在許多不同的抽象層次：在業(yè)務(wù)或企業(yè)級(jí)層次，可定義描述模擬整個(gè)業(yè)務(wù)的功能、結(jié)構(gòu)和行為的模型；在應(yīng)用層次，建模著重于特定的用戶需求。2西安交通大學(xué)劉海巖企業(yè)業(yè)務(wù)域業(yè)務(wù)域信息系統(tǒng)過程需求信息戰(zhàn)略計(jì)劃（全局視圖）業(yè)務(wù)域分析（領(lǐng)域視圖）系統(tǒng)分析與設(shè)計(jì)建模構(gòu)造與集成業(yè)務(wù)過程工程層次3西安交通大學(xué)劉海巖完整產(chǎn)品軟件能力功能過程需求產(chǎn)品需求（全局視圖）構(gòu)件工程（領(lǐng)域視圖）分析與設(shè)計(jì)建模構(gòu)造與集成產(chǎn)品工程層次數(shù)據(jù)行為硬件4西安交通大學(xué)劉海巖

Firesmith對(duì)軟件領(lǐng)域分析的定義是：領(lǐng)域分析指特定應(yīng)用領(lǐng)域中公共需求的標(biāo)識(shí)、分析和規(guī)約，即發(fā)現(xiàn)或創(chuàng)建那些可廣泛應(yīng)用的對(duì)象，其目的使它們在應(yīng)用域中多個(gè)項(xiàng)目間能被復(fù)用。領(lǐng)域分析的角色是設(shè)計(jì)和建造可復(fù)用構(gòu)件（類似于制造環(huán)境中工具制造者的角色），它們被很多相似但不一定是相同的應(yīng)用開發(fā)的人所使用。Lethbridge的定義是：領(lǐng)域分析是軟件工程師了解背景信息的過程。為了理解問題并在需求分析和軟件工程過程的其他階段作出合理的決策，軟件工程師必須了解使用該類軟件的一般性商業(yè)和技術(shù)領(lǐng)域中足夠的信息。5西安交通大學(xué)劉海巖

2、領(lǐng)域分析過程的活動(dòng)（1）定義被調(diào)查的領(lǐng)域中感興趣的項(xiàng)從業(yè)務(wù)域、系統(tǒng)類型或產(chǎn)品范疇中分離出感興趣的“項(xiàng)”。感興趣的項(xiàng)包括：現(xiàn)存的應(yīng)用軟件的規(guī)約、設(shè)計(jì)和代碼，支持軟件（如GUI或數(shù)據(jù)庫訪問構(gòu)件）以及和領(lǐng)域相關(guān)的構(gòu)件庫以及測試案例。（2）對(duì)從領(lǐng)域中抽取出來的項(xiàng)進(jìn)行分類并建立分類層次。6西安交通大學(xué)劉海巖

（3）收集領(lǐng)域中應(yīng)用系統(tǒng)的代表性樣本。

（4）分析樣本中的每個(gè)應(yīng)用?

標(biāo)識(shí)候選的每個(gè)可復(fù)用對(duì)象。

?

指明對(duì)象被標(biāo)識(shí)為可復(fù)用的理由。?定義對(duì)象的適應(yīng)性。?估算在領(lǐng)域中復(fù)用這些對(duì)象的應(yīng)用的百分率。

?使用配置管理技術(shù)控制這些對(duì)象。

（5）為對(duì)象開發(fā)分析模型。7西安交通大學(xué)劉海巖

3、領(lǐng)域分析的價(jià)值

領(lǐng)域分析除了為軟件復(fù)用奠定基礎(chǔ)外，還為較低抽象層次的一般的系統(tǒng)分析帶來如下好處：

?快速開發(fā)。有助于集中精力關(guān)注最重要的問題，更有效地與相關(guān)人員進(jìn)行交流，可以更快的確定需求。?優(yōu)化系統(tǒng)。了解領(lǐng)域的細(xì)節(jié)有助于保證所采納的解決方案更有效地解決用戶的問題。會(huì)少犯錯(cuò)誤，知道應(yīng)該遵循那些規(guī)程和標(biāo)準(zhǔn)。領(lǐng)域分析給出一個(gè)應(yīng)用領(lǐng)域的總體視圖，會(huì)引導(dǎo)出更好的抽象從而改進(jìn)設(shè)計(jì)。?有了領(lǐng)域知識(shí)，就可以洞察新興趨勢及進(jìn)一步開發(fā)的機(jī)會(huì)，有助于創(chuàng)建適應(yīng)性更強(qiáng)的系統(tǒng)。

?了解通用性和特殊性，有助于創(chuàng)建出具有更好的可重用性和更寬的銷售市場的軟件。8西安交通大學(xué)劉海巖

專家提出，沒有堅(jiān)實(shí)的領(lǐng)域分析，任何重大的軟件項(xiàng)目都不應(yīng)該進(jìn)行。對(duì)應(yīng)用領(lǐng)域的深入理解能極大的提高成功的幾率。許多非常成功的軟件產(chǎn)品的開發(fā)人員以前都在業(yè)務(wù)領(lǐng)域工作過－段時(shí)間，對(duì)實(shí)際需要有著深切的感受。一旦對(duì)領(lǐng)域有了真正的理解，就可進(jìn)行某一個(gè)項(xiàng)目（或產(chǎn)品）的需求分析，包括定義待解決的問題以及開發(fā)什么軟件來解決它。然而，領(lǐng)域分析永遠(yuǎn)也不應(yīng)該結(jié)束：開發(fā)人員有責(zé)任在開發(fā)過程中不斷增進(jìn)他們的理解，后續(xù)版本的系統(tǒng)擴(kuò)充通常需要對(duì)子領(lǐng)域進(jìn)行進(jìn)一步的領(lǐng)域分析。9西安交通大學(xué)劉海巖2.2

需求獲取1、需求（requirements）的概念（1）需求的定義Jones定義為用戶所需要的軟件必須達(dá)到的目標(biāo)和能力。Lethbridge定義為需求是關(guān)于系統(tǒng)將要完成什么工作的一段描述，它們必須經(jīng)過所有相關(guān)人員的認(rèn)可，其目的是徹底的解決用戶的問題。

?需求是一段…描述：意思是每個(gè)需求是相對(duì)短小簡明的一段信息，表現(xiàn)為一個(gè)事實(shí)。它可以是一段話或用各種圖表示。一組需求的集合成為需求文檔。

?…關(guān)于系統(tǒng)將要完成什么工作…：需求描述了系統(tǒng)應(yīng)當(dāng)完成的任務(wù)，不描述系統(tǒng)將如何實(shí)現(xiàn)。

?…必須經(jīng)過所有相關(guān)人員的認(rèn)可…：意指需求必須經(jīng)過評(píng)審，才能成為正式的需求。

?…其目的是徹底的解決用戶的問題。有助于解決用戶的問題，該需求才有存在的價(jià)值。10西安交通大學(xué)劉海巖業(yè)務(wù)需求項(xiàng)目范圍文檔用戶需求用例文檔功能需求質(zhì)量屬性其他非功能需求設(shè)計(jì)約束需求規(guī)約非功能需求系統(tǒng)需求需求組成的全景圖（2）需求的組成對(duì)系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求。用戶使用產(chǎn)品必須要完成的任務(wù)11西安交通大學(xué)劉海巖

其中：

?

業(yè)務(wù)需求：反映組織機(jī)構(gòu)和客戶對(duì)系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求。

?用戶需求：從用戶使用的角度給出需求的描述。

如一個(gè)小型超市需要一個(gè)商品的查詢系統(tǒng)。業(yè)務(wù)需求：進(jìn)貨人員需要查詢商品庫存以便保證及時(shí)進(jìn)貨；收款員需要查詢商品的銷售價(jià)格以便結(jié)賬；經(jīng)理需要查詢商品的銷售及盈利情況。用戶需求:這三類用戶怎樣去查詢系統(tǒng)，查詢哪些信息，還需要哪些操作。12西安交通大學(xué)劉海巖?系統(tǒng)需求：從系統(tǒng)或技術(shù)的角度描述為實(shí)現(xiàn)業(yè)務(wù)需求和用戶需求而提供的服務(wù)以及所受到的約束。?

功能性需求：描述系統(tǒng)應(yīng)該做什么，即為用戶和其它系統(tǒng)完成的功能。?

非功能性需求：產(chǎn)品必須具備的屬性或品質(zhì)。?設(shè)計(jì)約束：設(shè)計(jì)與實(shí)現(xiàn)必須遵循的標(biāo)準(zhǔn)、約束條件。如運(yùn)行平臺(tái)、協(xié)議、選擇的技術(shù)、編程語言和工具等。（3）需求的描述

?自然語言、結(jié)構(gòu)化語言、PDL

?圖形化表示（使用RationalRose、MicrosoftVisio、EnterpriseArchitect等工具）

?數(shù)學(xué)描述（形式化語言描述）13西安交通大學(xué)劉海巖2、需求工程過程需求工程是一個(gè)包括創(chuàng)建和維持系統(tǒng)需求文檔所必需的一切活動(dòng)的過程。它包含了如下活動(dòng)：系統(tǒng)可行性研究、需求獲取和分析、需求描述和文檔編寫、需求有效性驗(yàn)證、需求管理（管理需求工程的變更）。可行性研究需求獲取和分析需求描述需求有效性驗(yàn)證可行性研究報(bào)告系統(tǒng)模型用戶需求和系統(tǒng)需求需求規(guī)約需求工程過程需求管理14西安交通大學(xué)劉海巖可行性研究是需求工程過程的開始。在較短的時(shí)間內(nèi)作出結(jié)論。集中回答以下問題：

（1）系統(tǒng)是否符合組織機(jī)構(gòu)的總體目標(biāo)。系統(tǒng)不支持這些目標(biāo)，就沒有價(jià)值。

（2）系統(tǒng)是否可能在現(xiàn)有的技術(shù)條件、預(yù)算和時(shí)間限制內(nèi)完成。

（3）系統(tǒng)能否與已經(jīng)存在的系統(tǒng)集成。該活動(dòng)要廣泛收集信息并評(píng)估，回答一些有關(guān)的問題，寫出研究報(bào)告，得出結(jié)論：系統(tǒng)是否值得開發(fā)？給出具體的意見和建議。可能對(duì)系統(tǒng)高層需求、功能范圍、預(yù)算和時(shí)間安排提出修改意見。寫出可行性研究報(bào)告，該文檔可作為項(xiàng)目建議書、投標(biāo)書的基礎(chǔ)

15西安交通大學(xué)劉海巖計(jì)算機(jī)軟件文檔編制規(guī)范（GB/T8567-2006）

《可行性分析（研究）報(bào)告》模版1引言1.1標(biāo)識(shí)（標(biāo)題、版本號(hào)）1.2背景

1.3項(xiàng)目概述（用途、特性、用戶、運(yùn)行環(huán)境等）1.4文檔概述（用途、內(nèi)容、保密性等）2引用文件3可行性分析的前提3.1項(xiàng)目的要求3.2項(xiàng)目的目標(biāo)3.3項(xiàng)目的環(huán)境、條件、假定和限制3.4進(jìn)行可行性分析的方法16西安交通大學(xué)劉海巖4可選的方案4.1原有方案的優(yōu)缺點(diǎn)、局限性和存在的問題4.2可重用的系統(tǒng)與要求之間的差距4.3可選的系統(tǒng)方案1…4.x選擇最終方案的準(zhǔn)則5所建議的系統(tǒng)5.1系統(tǒng)的說明5.2數(shù)據(jù)流程或處理流程5.3與原系統(tǒng)的比較5.4影響或要求（設(shè)備、軟件、運(yùn)行、開發(fā)、環(huán)境、經(jīng)費(fèi)）

5.5局限性17西安交通大學(xué)劉海巖6經(jīng)濟(jì)可行性（成本-效益分析）6.1投資（成本）6.2預(yù)期的經(jīng)濟(jì)效益

（一次性/非一次性收益，不可定量的收益，收益/投資比，投資回收周期）

6.3市場預(yù)測7技術(shù)可行性（技術(shù)風(fēng)險(xiǎn)評(píng)價(jià)）8法律可行性9用戶使用可行性10其他與項(xiàng)目有關(guān)的問題（如未來的變化）11注釋12附錄18西安交通大學(xué)劉海巖需求獲取與需求分析的區(qū)別

?需求獲取是開發(fā)人員與客戶或用戶一起對(duì)應(yīng)用領(lǐng)域進(jìn)行調(diào)查研究，收集系統(tǒng)需求的過程。

?需求分析是將獲取到的需求準(zhǔn)確的理解、求精，并將其轉(zhuǎn)化為完整的需求定義（包括建模），進(jìn)而生成需求規(guī)約的過程。需求獲取和分析的難度

?項(xiàng)目相關(guān)人員通常并不真正知道希望計(jì)算機(jī)做什么，讓他們清晰的表達(dá)出需要系統(tǒng)做什么是件困難的事，他們或許提出不切實(shí)際的要求。

19西安交通大學(xué)劉海巖

?項(xiàng)目相關(guān)人員用自己的語言表達(dá)需求，這些語言包含很多工作中的專業(yè)術(shù)語和專業(yè)知識(shí)。系統(tǒng)分析員沒有這些知識(shí)和經(jīng)驗(yàn)，而他們又必須了解這些需求。?不同的項(xiàng)目相關(guān)人員有不同的需求，可能以不同的方式表達(dá)，分析人員必須發(fā)現(xiàn)所有潛在的需求資源，而且能發(fā)現(xiàn)這些需求的相容或沖突之處。?經(jīng)濟(jì)和業(yè)務(wù)環(huán)境決定了分析是動(dòng)態(tài)的，需求在分析過程中會(huì)發(fā)生變更。個(gè)別需求的重要程度會(huì)改變，新的需求會(huì)從新的項(xiàng)目相關(guān)人員那里得到。

20西安交通大學(xué)劉海巖需求獲取技術(shù)

?建立由客戶（用戶）、系統(tǒng)分析員、領(lǐng)域?qū)＜覅⒓拥穆?lián)合小組。

?需求獲取的方法：個(gè)別訪談、召集會(huì)議、文檔研究、問卷調(diào)查、觀察用戶工作流程、建立原型。

?獲取的需求的表達(dá)方式：（1）需求列表需求與系統(tǒng)的特殊視角或環(huán)境的關(guān)系

（2）業(yè)務(wù)流程圖（狀態(tài)/活動(dòng)圖）

（3）用例（Use-Case）/場景（Scenario）/用戶故事（userstory)

（4）數(shù)據(jù)流圖

（5）實(shí)體關(guān)系圖

（6）用例圖、類圖、活動(dòng)圖、時(shí)序圖、狀態(tài)圖等。

21西安交通大學(xué)劉海巖用例

Jacobson說“用例幫助定義系統(tǒng)之外存在什么（參與者）以及系統(tǒng)應(yīng)該完成什么”。把系統(tǒng)分成一組邏輯的、互相聯(lián)系較少的部分，每一部分都描述了系統(tǒng)與外部角色交互所提供的服務(wù)，即用例的集合代表了所有將會(huì)在系統(tǒng)需求中出現(xiàn)的交互。因此容易從使用的角度理解系統(tǒng)應(yīng)達(dá)到的功能。而“用戶故事”是某種形式的簡化版用例。場景

場景是用例的具體描述。一個(gè)用例封裝了一組場景，每個(gè)場景就是一個(gè)單個(gè)線程。22西安交通大學(xué)劉海巖例1：列出圖書館系統(tǒng)與以下參與者（角色）交互的最小用例集：借閱者、借書員、圖書管理員、會(huì)計(jì)系統(tǒng)。借閱者：

?按題目查詢書籍

?按作者查詢書籍

?按主題查詢書籍?預(yù)定已被其他人借出的書籍?查詢借閱者的個(gè)人信息并列出借閱的書籍23西安交通大學(xué)劉海巖借書員：

所有借閱者的用例，再加上

?為借閱者查找某一書籍

?登記已歸還的書籍

?續(xù)借一本書

?登記繳納的罰款

?添加新的借閱者

?更新借閱者的個(gè)人信息（地址、電話號(hào)碼等）

圖書管理員：

所有借閱者和借書員的用例，再加上

?添加藏書

?刪除藏書

?改變系統(tǒng)中對(duì)已有書籍的記錄信息

會(huì)計(jì)系統(tǒng)（獨(dú)立運(yùn)行）

?獲得借閱者支付的超期罰款24西安交通大學(xué)劉海巖例2：一個(gè)SafeHome系統(tǒng)，系統(tǒng)激活的基本用例用自然語言陳述如下：（參考教材1)

①房主觀察控制面板以確定是否系統(tǒng)已準(zhǔn)備好接收輸入。如果系統(tǒng)未準(zhǔn)備好，房主必須物理地關(guān)閉門/窗戶，以便使“準(zhǔn)備好”指示燈亮。②房主使用鍵盤輸入4位密碼，系統(tǒng)將密碼與存儲(chǔ)在配置庫中的有效密碼比較，如果密碼不正確，控制面板鳴叫一次并復(fù)位等待再次輸入。如果密碼正確，控制面板等待進(jìn)一步的動(dòng)作。③房主選擇鍵入“stay”（僅激活外部的傳感器）或“away”（激活所有的傳感器）以啟動(dòng)系統(tǒng)。④當(dāng)激活時(shí)，房主可觀察到一個(gè)紅色指示燈。25西安交通大學(xué)劉海巖用例：房主激活監(jiān)測場景：1、房主：觀察控制面板。2、房主：輸入密碼。3、房主：選擇“stay”或“away”。4、房主：觀察紅色指示燈顯示系統(tǒng)已被打開。異常：1、控制面板未就緒。2、密碼不正確。3、密碼不識(shí)別。未解決的問題：1、是否有不使用密碼激活系統(tǒng)的方式。2、控制面板是否還應(yīng)顯示附加的文字信息。3、房主輸入密碼的時(shí)間有無約束。4、在系統(tǒng)真正激活之前有無辦法關(guān)閉系統(tǒng)。26西安交通大學(xué)劉海巖2.3

需求分析與建模需求分析是發(fā)現(xiàn)、規(guī)約和求精的過程，指開發(fā)人員準(zhǔn)確的理解用戶的需求，通過分析，將不規(guī)范的需求陳述轉(zhuǎn)化為完整的需求定義，并產(chǎn)生需求規(guī)格化說明的過程。

獲取的需求可能有模糊的、冗余的、有沖突的或不易理解的地方，需要用文字和圖形描述不同視圖以揭示更深的、易混淆的問題，確保與所有風(fēng)險(xiǎn)承擔(dān)者達(dá)成共識(shí)。

27西安交通大學(xué)劉海巖需求分析活動(dòng)具有以下任務(wù)：（1）分析需求的可行性：允許的成本、性能；與其他需求的沖突；外界因素的依賴和技術(shù)障礙等。（2）對(duì)于漸增式開發(fā)要確定需求的優(yōu)先級(jí)別，以便確立產(chǎn)品版本。（3）建模：模型能突出或強(qiáng)調(diào)某些關(guān)鍵的系統(tǒng)特征。使用文本和圖表形式的組合，以相對(duì)容易理解和能直接評(píng)審正確性、完整性和一致性的方式來描述數(shù)據(jù)（信息）、功能和行為的需求。圖形化的表示分析模型可以增強(qiáng)對(duì)軟件需求的理解，也為軟件設(shè)計(jì)奠定了基礎(chǔ)。（4）生成需求規(guī)格說明。28西安交通大學(xué)劉海巖在過去的數(shù)年中，人們提出了許多種分析建模的方法，其中兩種在分析建模領(lǐng)域占有主導(dǎo)地位：第一種是結(jié)構(gòu)化分析(StructuredAnalysis，SA)，70年代末由DeMarco等人提出，這是傳統(tǒng)的建模方法。該方法不是被所有的使用者一致地使用的單一方法，眾多科學(xué)家對(duì)其進(jìn)行了擴(kuò)充，因此它是發(fā)展了超過30年的一個(gè)混合物。另一種方法是面向?qū)ο蟮姆治觯?/p>

如Coad-Yourdon方法、Booch方法、Rumbaugh方法、Jacobson方法等。具體的建模方法有:

29西安交通大學(xué)劉海巖上下文模型（ERD、包圖）面向流的建模：數(shù)據(jù)流圖（DFD/CFD）數(shù)據(jù)建模：實(shí)體關(guān)系圖（ERD）基于場景的建模：用例圖、順序圖、活動(dòng)圖基于類的建模：類圖、包基于行為的建模：Petri網(wǎng)、狀態(tài)圖、順序圖、協(xié)作圖、活動(dòng)圖……30西安交通大學(xué)劉海巖Sommerville認(rèn)為模型可以從以下角度去描述：1、從外部看，它是對(duì)系統(tǒng)上下文或系統(tǒng)環(huán)境建模。（見下頁圖）2、從行為上看，它是對(duì)系統(tǒng)運(yùn)行行為建模。3、從結(jié)構(gòu)上看，它是對(duì)系統(tǒng)體系結(jié)構(gòu)和系統(tǒng)數(shù)據(jù)的結(jié)構(gòu)建模。有如下系統(tǒng)模型的實(shí)例（ppt30）：31西安交通大學(xué)劉海巖上下文模型（定義了系統(tǒng)的邊界）32西安交通大學(xué)劉海巖

1、數(shù)據(jù)處理模型如數(shù)據(jù)流圖，說明系統(tǒng)的不同階段數(shù)據(jù)如何被處理。2、組成模型實(shí)體關(guān)系圖，說明一個(gè)實(shí)體與另外實(shí)體間的關(guān)系或如何由其他實(shí)體組成。3、體系結(jié)構(gòu)模型說明構(gòu)成整個(gè)系統(tǒng)的那些主要的子系統(tǒng)。4、分類模型如對(duì)象模型，說明對(duì)象間怎樣具有共同特性。5、激勵(lì)-響應(yīng)模型說明系統(tǒng)對(duì)來自內(nèi)部和外部的事件的響應(yīng)。具體分析建模的方法請(qǐng)見第3章。33西安交通大學(xué)劉海巖2.4

需求規(guī)約與驗(yàn)證1、軟件需求規(guī)約（Software

RequirementsSpecification，SRS）

SRS是需求分析階段的產(chǎn)品，是所有其他開發(fā)和管理活動(dòng)的基礎(chǔ)。對(duì)系統(tǒng)開發(fā)過程中其他活動(dòng)的影響：?項(xiàng)目經(jīng)理根據(jù)它制定或修改開發(fā)計(jì)劃。?設(shè)計(jì)人員根據(jù)它進(jìn)行系統(tǒng)設(shè)計(jì)。?測試人員根據(jù)它編寫測試計(jì)劃，設(shè)計(jì)測試用例。?產(chǎn)品發(fā)布人員根據(jù)它編寫產(chǎn)品介紹和用戶文檔。?培訓(xùn)人員根據(jù)它編寫培訓(xùn)教程。34西安交通大學(xué)劉海巖需求規(guī)約的結(jié)構(gòu)：

1998年的IEEE標(biāo)準(zhǔn)為需求規(guī)約提出了以下結(jié)構(gòu)，組織機(jī)構(gòu)內(nèi)部可以基于此標(biāo)準(zhǔn)擴(kuò)展：（1）引言需求文檔的目的、產(chǎn)品范圍、文檔約定（縮寫詞與縮略語）、參考文獻(xiàn)、文檔的其余部分概覽（2）綜合描述產(chǎn)品前景、

產(chǎn)品功能與優(yōu)先級(jí)、用戶特征、運(yùn)行環(huán)境、設(shè)計(jì)與實(shí)現(xiàn)上的約束、假設(shè)和依賴性35西安交通大學(xué)劉海巖

（3）需求描述a.功能需求b.數(shù)據(jù)需求：與功能有關(guān)的數(shù)據(jù)定義和數(shù)據(jù)關(guān)系c.性能需求：響應(yīng)時(shí)間、容量要求、用戶數(shù)等d.外部接口：用戶界面、軟硬件接口、通信接口e.設(shè)計(jì)約束：軟件支持環(huán)境、報(bào)表、數(shù)據(jù)命名等f.軟件質(zhì)量屬性（可維護(hù)性、可靠性、可移植性、可用性、安全性等等）g.其他需求這一節(jié)是文檔中最實(shí)質(zhì)性的部分，由于在機(jī)構(gòu)組織的實(shí)踐中存在極大的變數(shù)，對(duì)這一節(jié)定義的標(biāo)準(zhǔn)結(jié)構(gòu)可以進(jìn)行增刪。（4）附錄（詞匯表、硬件與數(shù)據(jù)庫的描述、模型、待定問題列表等）（5）索引36西安交通大學(xué)劉海巖計(jì)算機(jī)軟件文檔編制規(guī)范（GB/T8567-2006）

《需求規(guī)格說明》模版1.引言

1.1標(biāo)識(shí)文件狀態(tài)（草稿/正式發(fā)布/正在修改）；文件標(biāo)識(shí)；當(dāng)前版本；

作者1.2系統(tǒng)概述（名稱、功能、性能、上下文關(guān)系、用戶、開發(fā)者）1.3文檔概述（用途、內(nèi)容、保密性）1.4基線2.引用文件3.需求3.1所需的狀態(tài)和方式3.2需求概述（系統(tǒng)目標(biāo)、運(yùn)行環(huán)境、用戶特點(diǎn)、關(guān)鍵點(diǎn)、約束條件）

37西安交通大學(xué)劉海巖3.3需求規(guī)格3.3.1軟件系統(tǒng)總體功能/對(duì)象結(jié)構(gòu)3.3.2軟件子系統(tǒng)功能/對(duì)象結(jié)構(gòu)3.3.3描述約定3.4能力需求3.4.1能力（功能、性能、主題、目標(biāo)；對(duì)每一個(gè)功能寫出輸入、處理、輸出的需求）…3.5外部接口需求（用戶、硬件、軟件、通信等接口需求）3.6內(nèi)部接口需求3.7內(nèi)部數(shù)據(jù)需求（數(shù)據(jù)庫和數(shù)據(jù)文件的需求）38西安交通大學(xué)劉海巖

3.8~3.12適應(yīng)性、保密性、環(huán)境、資源、通信等需求3.13軟件質(zhì)量因素（可靠性、可用性、可維護(hù)性等）3.14設(shè)計(jì)與實(shí)現(xiàn)的約束…（故障處理、其他需求，需求的優(yōu)先級(jí)等等）4合格性規(guī)定（驗(yàn)證方法）5需求可追蹤性6尚未解決的問題7注釋、附錄39西安交通大學(xué)劉海巖

2、需求驗(yàn)證

需求驗(yàn)證的重要性：如果在后續(xù)的開發(fā)或當(dāng)系統(tǒng)投入使用時(shí)才發(fā)現(xiàn)需求規(guī)約中的錯(cuò)誤，就會(huì)導(dǎo)致更大代價(jià)的返工。由需求問題而對(duì)系統(tǒng)做變更的成本比修改設(shè)計(jì)或代碼錯(cuò)誤的成本要大的多。假設(shè)需求階段引入1個(gè)錯(cuò)誤的需求，設(shè)計(jì)時(shí)對(duì)這個(gè)需求需要5~10條設(shè)計(jì)實(shí)現(xiàn)，1條設(shè)計(jì)需要5~10條程序，1條程序需要3~5種測試組合測試。

原始需求正確的規(guī)格說明

錯(cuò)誤的規(guī)格說明正確的設(shè)計(jì)

錯(cuò)誤的設(shè)計(jì)

對(duì)錯(cuò)誤需求的設(shè)計(jì)正確的編碼

錯(cuò)誤的編碼

對(duì)錯(cuò)誤設(shè)計(jì)的編碼

對(duì)錯(cuò)誤需求的編碼正確功能

測試到的錯(cuò)誤沒有測試到的錯(cuò)誤

一個(gè)錯(cuò)誤的需求，糾正成本100元×10糾正成本1000元×10×540西安交通大學(xué)劉海巖對(duì)需求規(guī)約需執(zhí)行以下類型的檢查：（1）有效性檢查檢查不同用戶使用不同功能的有效性。（2）一致性檢查在文檔中，需求不應(yīng)該沖突。（3）完備性檢查需求文檔應(yīng)該包括所有用戶想要的功能和約束。（4）現(xiàn)實(shí)性檢查檢查保證能利用現(xiàn)有技術(shù)實(shí)現(xiàn)需求。41西安交通大學(xué)劉海巖驗(yàn)證技術(shù)：

（1）需求評(píng)審：評(píng)審需求的一致性完備性可檢驗(yàn)性（是否可實(shí)際測試）可理解性可跟蹤性（需求出處是否清晰）適應(yīng)性（需求是否可調(diào)節(jié)）由分析員、設(shè)計(jì)員、測試員、用戶參與的正式或非正式的會(huì)議評(píng)審。正式會(huì)議要有嚴(yán)格的評(píng)審程序，要有會(huì)議記錄，開發(fā)組根據(jù)缺陷建議修改需求說明并重審。

42西安交通大學(xué)劉海巖

（2）利用原型檢驗(yàn)系統(tǒng)是否符合用戶的真正需要。（3）對(duì)每個(gè)需求編寫概念性的測試用例。（4）編寫用戶手冊。用淺顯易懂的語言描述用戶可見的功能。（5）自動(dòng)的一致性分析?？捎肅ASE工具檢驗(yàn)需求模型的一致性。43西安交通大學(xué)劉海巖計(jì)算機(jī)軟件文檔編制規(guī)范（GB/T8567-2006）

《軟件用戶手冊》模版1引言

1.1標(biāo)識(shí)文件狀態(tài)（草稿/正式發(fā)布/正在修改）；文件標(biāo)識(shí)；當(dāng)前版本；

作者1.2系統(tǒng)概述（名稱、功能、性能、上下文關(guān)系、用戶、開發(fā)者）1.3文檔概述（用途、內(nèi)容、保密性）1.4基線2引用文件3軟件綜述3.1軟件用途

3.2軟件清單

3.3軟件安裝與運(yùn)行環(huán)境44西安交通大學(xué)劉海巖

3.4軟件組織和操作概述

（邏輯部件，其用途，操作；用戶期望的性能特性；該軟件執(zhí)行的功能和所接口的系統(tǒng)；為管理軟件采用的監(jiān)控措施等）

3.5意外事故及運(yùn)行的備用狀態(tài)和方式3.6保密性

3.7幫助和問題報(bào)告4訪問軟件

4.1首次用戶（熟悉設(shè)備；訪問控制；安裝和設(shè)置）4.2啟動(dòng)過程（步驟）4.3停止與掛起45西安交通大學(xué)劉海巖5使用軟件指南

5.1能力（簡述事物、菜單、功能和其他處理之間的關(guān)系）5.2約定（縮略語、命名、編碼規(guī)則等）

5.3處理過程

（解釋功能、菜單、屏幕的組織及完成過程的次序）5.4相關(guān)處理（脫機(jī)、后臺(tái)等不被用戶直接調(diào)用的處理）5.5數(shù)據(jù)備份5.6錯(cuò)誤、故障和緊急情況時(shí)的恢復(fù)5.7完成功能時(shí)發(fā)出的錯(cuò)誤消息、診斷消息和通知性消息5.8快速引用指南6注釋、附錄46西安交通大學(xué)劉海巖2.5需求管理需求管理是對(duì)系統(tǒng)需求控制的過程。完成需求規(guī)約并不代表需求工程過程的結(jié)束，不可避免的遇到需求的變更。原因是：

?大型系統(tǒng)擁有不同的用戶群體，就有不同的需求和優(yōu)先級(jí)?；ハ嘤袥_突或矛盾，需求規(guī)約所做出的某些平衡隨著經(jīng)驗(yàn)的積累可能要改變。

?客戶和最終用戶的需求可能不一致。

?業(yè)務(wù)和技術(shù)環(huán)境的變化引起需求的變化。

需求導(dǎo)出的同時(shí)啟動(dòng)了需求管理規(guī)劃，一旦形成了需求文檔的草稿，需求管理的活動(dòng)就開始了。47西安交通大學(xué)劉海巖1、需求管理規(guī)劃需求管理是標(biāo)識(shí)、控制和跟蹤需求的活動(dòng)。需要確定以下內(nèi)容：?需求標(biāo)識(shí)每個(gè)需求有一個(gè)唯一的標(biāo)識(shí)符，以便可被其他需求交叉索引。?變更管理對(duì)變更帶來的影響和成本進(jìn)行評(píng)估。?跟蹤策略定義需求之間的關(guān)系以及需求和設(shè)計(jì)之間的關(guān)系，并做出記錄以及維護(hù)方法。?CASE工具支持管理中對(duì)大量信息的加工，如需求存儲(chǔ)、變更管理、可跟蹤性管理等。。48西安交通大學(xué)劉海巖需求和需求之間、需求和設(shè)計(jì)之間有許多關(guān)系。在需求和引起該需求潛在的原因之間也有許多關(guān)系。當(dāng)變更發(fā)生時(shí)，必須追蹤這些變更對(duì)其他需求和系統(tǒng)設(shè)計(jì)的影響。需要維護(hù)的3類可跟蹤性信息是：?源可追蹤性信息連接到提出該需求的相關(guān)人員或基本原理。?需求可追蹤性信息連接文檔中彼此依賴的需求，用來評(píng)估一個(gè)變更會(huì)對(duì)多少需求產(chǎn)生影響以及引發(fā)的需求變更的范圍和程度。?設(shè)計(jì)可追蹤性