軟件工程5-史濟(jì)民

1、湘 潭 大 學(xué)第第5 5章章 需求工程與需求分析需求工程與需求分析軟件需求過程需求分析與建模需求獲取的常用方法需求模型軟件需求描述需求管理需求建模示例5.1 5.1 軟件需求工程軟件需求工程 軟件需求的定義 一個軟件系統(tǒng)必須遵循的條件或具備的能力。 用戶解決問題或達(dá)到目標(biāo)所需的條件或能力，即系統(tǒng)的外部行為。 系統(tǒng)為滿足合同、規(guī)范等所需具備的條件或能力，即系統(tǒng)的內(nèi)部特性。 軟件需求三個層次 業(yè)務(wù)需求：從業(yè)務(wù)角度分析項(xiàng)目成功的預(yù)期效果。 用戶需求：從使用角度描述軟件產(chǎn)品必須完成的任務(wù)。 功能需求 ：定義必須實(shí)現(xiàn)的軟件功能。這些功能必須達(dá)到的非功能性要求、約束條件等。軟件需求的層次關(guān)系軟件需求的層次

2、關(guān)系業(yè)務(wù)需求項(xiàng)目愿景與范圍用戶需求質(zhì)量屬性用例模型文檔功能需求非功能需求和約束條件軟件需求規(guī)格說明軟件需求的特性軟件需求的特性 軟件需求包括以下6個特性： 功能性：分為普通功能和全局性功能。 可用性：泛指能使最終用戶方便使用軟件的相關(guān)需求。 可靠性：包括與系統(tǒng)可靠性相關(guān)的各種指標(biāo)。 性能：記錄與系統(tǒng)性能相關(guān)的各種指標(biāo)。 可支持性：定義所有與系統(tǒng)的可支持性或可維護(hù)性相關(guān)的需求。 設(shè)計(jì)約束：代表已經(jīng)批準(zhǔn)并必須遵循的設(shè)計(jì)決定。需求工程的由來需求工程的由來 代碼編寫-生存周期-需求工程 軟件需求工程 可以定義為應(yīng)用有效的技術(shù)和方法，合適的工具和符號，來確定、管理和描述目標(biāo)系統(tǒng)及其外部行為特征的學(xué)科。

3、5.2 5.2 需求分析與建模需求分析與建模 需求分析的步驟 需求分析是迭代過程需求獲取需求建模需求描述規(guī)格說明需求驗(yàn)證5.3 5.3 需求獲取的常用方法需求獲取的常用方法 常規(guī)的需求獲取方法 組成聯(lián)合分析小組 成員：用戶代表、領(lǐng)域?qū)＜液拖到y(tǒng)分析員 用戶訪談 充分準(zhǔn)備，尋找共同語言。 循循序漸進(jìn)、逐步逼近 。 問題分析與確認(rèn) 與用戶交流和問題分析需要多個來回。需求獲取的常用方法需求獲取的常用方法 用快速原型法獲取需求 快速原型法實(shí)施的步驟： 利用各種分析技術(shù)和方法，生成一個簡化的需求規(guī)格說明； 對需求規(guī)格說明進(jìn)行必要的檢查和修改后，確定原型的軟件結(jié)構(gòu)、用戶界面和數(shù)據(jù)結(jié)構(gòu)等； 在現(xiàn)有的工具和環(huán)境

4、的幫助下快速生成可運(yùn)行的軟件原型并進(jìn)行測試、改進(jìn)； 將原型提交給用戶評估并征求用戶的修改意見；1.重復(fù)上述過程，直到原型得到用戶的認(rèn)可。 5.4 5.4 需求模型需求模型 需求模型概述 結(jié)構(gòu)化需求模型 面向?qū)ο笮枨竽Ｐ?面向?qū)ο蟮男枨蠼?畫用例圖 寫用例規(guī)約 描述補(bǔ)充規(guī)約 編寫術(shù)語表結(jié)構(gòu)化需求模型結(jié)構(gòu)化需求模型數(shù)據(jù)字典數(shù)據(jù)流圖判定樹判定表PDL加工說明數(shù)據(jù)定義.E-R圖行為模型狀態(tài)轉(zhuǎn)換圖控制流圖和控制說明功能模型數(shù)據(jù)模型面向?qū)ο笮枨竽Ｐ兔嫦驅(qū)ο笮枨竽Ｐ陀美?guī)約參與者用例圖用例模型補(bǔ)充規(guī)約術(shù)語表全局性功能、非功能需求用例建模用例建模 確定參與者 存在于系統(tǒng)外部、與系統(tǒng)交互的人、硬件、其他系統(tǒng)

5、通過回答問題確定參與者 系統(tǒng)開發(fā)完成之后，有哪些人會使用這個系統(tǒng)？ 系統(tǒng)需要從哪些人或其他系統(tǒng)中獲得數(shù)據(jù)？ 系統(tǒng)會為哪些人或其他系統(tǒng)提供數(shù)據(jù)？ 系統(tǒng)會與哪些其他系統(tǒng)相關(guān)聯(lián)？ 系統(tǒng)是由誰來維護(hù)和管理的？ 確定用例 考察每個參與者與系統(tǒng)的交互和需要系統(tǒng)提供的服務(wù) 針對每一個參與者，通過回答問題確定用例 參與者為什么要使用該系統(tǒng)？ 參與者是否會在系統(tǒng)中創(chuàng)建、修改、刪除、訪問、存儲數(shù)據(jù)？如果是的話，參與者又是如何來完成這些操作的？ 參與者是否會將外部的某些事件通知給該系統(tǒng)？ 系統(tǒng)是否會將內(nèi)部的某些事件通知該參與者？ 第一步，確定參與者。 第二步，確定用例。通常規(guī)則是：用例應(yīng)該典型地描繪系統(tǒng)功能中某個從

6、開始到結(jié)束的過程。 繪制和檢查用例圖 按按UMLUML標(biāo)準(zhǔn)畫用例圖標(biāo)準(zhǔn)畫用例圖 檢查用例圖檢查用例圖 細(xì)化每個用例的用例規(guī)約 內(nèi)容包括：內(nèi)容包括： 簡要說明簡要說明 事件流事件流 特殊需求特殊需求 前置條件和后置條件前置條件和后置條件 用例模型的檢查 功能需求的完備性功能需求的完備性 模型是否易于理解模型是否易于理解 是否存在不一致性是否存在不一致性 避免二義性語義避免二義性語義用例建模示例用例建模示例 選課系統(tǒng)問題陳述選課系統(tǒng)問題陳述 開發(fā)一個學(xué)生選課系統(tǒng)。通過這個系統(tǒng)，學(xué)生可以選課和查看成績報告單，教授可以選擇所教的課和記錄學(xué)生的成績。 學(xué)校保留原有的“課程目錄”數(shù)據(jù)庫系統(tǒng)來維護(hù)課程信息，

7、但該系統(tǒng)的性能是有限的。所以新系統(tǒng)必須確保能及時訪問舊系統(tǒng)上的數(shù)據(jù)。但新系統(tǒng)只能讀取舊系統(tǒng)的課程信息，不能更新。用例建模示例用例建模示例 每學(xué)期開始時，學(xué)生請求查看本學(xué)期開設(shè)的課程目錄。有關(guān)課程的信息，包括教授名和所開設(shè)的系等，將幫助學(xué)生做出決定。 系統(tǒng)允許學(xué)生每學(xué)期選擇4門課，如果學(xué)生沒有選到主要的課程，還有兩門備選課程可選。每門課的學(xué)生人數(shù)限3到10人。不滿3人的課程將被取消。 另外，每個學(xué)期有一段時間讓學(xué)生更改課程表。學(xué)生可在該時段內(nèi)訪問系統(tǒng)并添加/刪除課程。 用例建模示例用例建模示例 某個學(xué)生的選課一旦結(jié)束，選課系統(tǒng)即將此學(xué)生本學(xué)期的賬單信息送到財(cái)務(wù)系統(tǒng)。 如果在選課時某門課已經(jīng)人滿，

8、學(xué)生在提交信息前必須被告知。 學(xué)期結(jié)束，學(xué)生可進(jìn)入系統(tǒng)查看自己的成績。成績屬于隱秘信息，系統(tǒng)必須提供額外的安全措施阻止未授權(quán)的訪問。教授必須能訪問系統(tǒng)查詢他們主講課程。他們也需要知道是哪些學(xué)生選擇了自己的課程。另外，教授也能登記學(xué)生的成績。用例建模示例用例建模示例 確定參與者學(xué)學(xué)生生要注要注冊課冊課程；程；教教授授要要選擇課選擇課程程來教來教；注注冊冊管理人管理人員員要要維護(hù)關(guān)維護(hù)關(guān)于于教教授和授和學(xué)學(xué)生的所有信生的所有信息；息；財(cái)務(wù)財(cái)務(wù)系系統(tǒng)統(tǒng)要要從從注注冊冊系系統(tǒng)獲統(tǒng)獲得得學(xué)學(xué)生的生的費(fèi)費(fèi)用情用情況況；課課程目程目錄錄系系統(tǒng)統(tǒng)維護(hù)課維護(hù)課程信息。程信息。用例建模示例用例建模示例 確定用例無

9、無論論是是學(xué)學(xué)生，生，教教授授還還是注是注冊員冊員都需要都需要登登錄錄到系到系統(tǒng)統(tǒng)；學(xué)學(xué)生需要使用系生需要使用系統(tǒng)來統(tǒng)來選課選課，也能，也能查查看看自己的成自己的成績績；教教授需要使用系授需要使用系統(tǒng)來統(tǒng)來選擇課選擇課程程，也能，也能記錄記錄學(xué)學(xué)生的成生的成績績；注注冊員冊員必必須須維護(hù)維護(hù)學(xué)學(xué)生、生、教教授的所有信息，授的所有信息，并并在適在適當(dāng)時當(dāng)時候候關(guān)閉關(guān)閉注注冊冊系系統(tǒng)統(tǒng)；當(dāng)選擇課當(dāng)選擇課程的程的過過程完成后，收程完成后，收費(fèi)費(fèi)系系統(tǒng)統(tǒng)必必須須獲獲得得收收費(fèi)費(fèi)信息；信息；學(xué)學(xué)生和生和教教授授選擇課選擇課程，需要程，需要啟動啟動課課程目程目錄錄系系統(tǒng)統(tǒng)。用例建模示例用例建模示例 選課系

10、統(tǒng)用例圖用例建模示例用例建模示例選課用例規(guī)約選課用例規(guī)約1簡要說明 本用例允許學(xué)生選本學(xué)期提供的課程。在學(xué)期開始的添加/刪除時期，學(xué)生可以修改或刪除選擇的課程。課程目錄系統(tǒng)提供了當(dāng)前學(xué)期開設(shè)的所有課程的列表。2事件流2.1基本事件流 用例開始于學(xué)生選擇選課，或修改已存在的課程表。1 1）系統(tǒng)要求學(xué)生指出要執(zhí)行的操作（創(chuàng)建，修改或刪除課程表）系統(tǒng)要求學(xué)生指出要執(zhí)行的操作（創(chuàng)建，修改或刪除課程表）2 2）一旦學(xué)生提供了所需要的信息，以下的一條子事件流將被執(zhí)行）一旦學(xué)生提供了所需要的信息，以下的一條子事件流將被執(zhí)行 如果選擇的是如果選擇的是“創(chuàng)建課程表創(chuàng)建課程表”，創(chuàng)建課程表子事件流將被執(zhí)行，創(chuàng)建課

11、程表子事件流將被執(zhí)行 如果選擇的是如果選擇的是“修改課程表修改課程表”，修改課程表子事件流將被執(zhí)行，修改課程表子事件流將被執(zhí)行 如果選擇的是如果選擇的是“刪除課程表刪除課程表”，刪除課程表子事件流將被執(zhí)行，刪除課程表子事件流將被執(zhí)行2.2備選事件流 3特殊需求 無4前置條件 本用例開始前學(xué)生必須已經(jīng)登錄進(jìn)系統(tǒng)。5后置條件 如果用例成功，學(xué)生的課程表被創(chuàng)建，修改，刪除。否則系統(tǒng)狀態(tài)不變。 描述補(bǔ)充規(guī)約示例描述補(bǔ)充規(guī)約示例選課系統(tǒng)的補(bǔ)充規(guī)約選課系統(tǒng)的補(bǔ)充規(guī)約1 1目標(biāo)目標(biāo) 本文檔的目的是定義選課系統(tǒng)的需求。本補(bǔ)充規(guī)約列出了不便于在用例模型的用例中獲取的系統(tǒng)需求。它和用例模型一起記錄關(guān)于系統(tǒng)的一整套

12、需求。2 2范圍范圍 本補(bǔ)充規(guī)約適用于選課系統(tǒng)，除定義了在許多用例中所共有的功能性需求以外，還定義了系統(tǒng)的非功能性需求，例如：可靠性、可用性、性能和可支持性等。（功能性需求在用例規(guī)約中定義。）描述補(bǔ)充規(guī)約示例描述補(bǔ)充規(guī)約示例3 3參考參考無無4 4功能功能 多個用戶必須能同時執(zhí)行操作。 如果某個學(xué)生所建的課程表中包含人數(shù)已滿的課程，必須通知這位學(xué)生。5 5可行性可行性 桌面用戶界面應(yīng)與 Windows 98/2000/XP 兼容。6 6可靠性可靠性 選課系統(tǒng)在每周7天，每天24小時內(nèi)都應(yīng)是可用的。宕機(jī)的時間應(yīng)少于 10%。7 7性能性能 術(shù)語表示例術(shù)語表示例選課系統(tǒng)的術(shù)語表選課系統(tǒng)的術(shù)語表1.

13、1. 簡介簡介 這份文檔是用來對一些術(shù)語進(jìn)行定義的，同時將用例說明或其他文檔中讀者不太熟悉的術(shù)語進(jìn)行解釋性的描述。通常來說，這份文檔對一些數(shù)據(jù)信息進(jìn)行一些定義，從而使得用例規(guī)約和其他的文檔顯得簡潔易懂。2.2. 定義定義 這份術(shù)語表包含了選課系統(tǒng)中核心概念的定義。 課程：大學(xué)提供的某一門課。 開設(shè)課程：某一課程的具體安排情況，包括一周上課的天數(shù)、時間和教授。 課程目錄：大學(xué)所開設(shè)的所有課程的完整目錄。 教員：所有在此大學(xué)內(nèi)任教的教授。 財(cái)務(wù)系統(tǒng)：用來處理收費(fèi)信息的系統(tǒng)。 成績：學(xué)生某門課程的成績。5.5 5.5 軟件需求描述軟件需求描述 軟件需求規(guī)格說明書 Software Requireme

14、nt Specification 引言 信息描述 功能描述 行為描述 質(zhì)量保證 接口描述 其他5.6 5.6 需求管理需求管理 需求管理的特定實(shí)踐 需求管理的流程 需求確認(rèn) 需求跟蹤 需求變更 需求變更控制 需求變更的利弊 需求變更的流程需求變更狀態(tài)轉(zhuǎn)換需求變更狀態(tài)轉(zhuǎn)換需求管理工具需求管理工具 IBM Rational RequisitePro Telelogic DOORSreg Borland CaliberRM5.7 5.7 需求建模示例需求建模示例網(wǎng)上購物系統(tǒng)網(wǎng)上購物系統(tǒng)當(dāng)今，網(wǎng)上購物已成為一種時尚。本示例作為WEB 應(yīng)用的一例，主要為普通購物用戶和管理員服務(wù)。普通購物用戶在使用本系統(tǒng)

15、的購物功能前，必須先注冊賬號。在注冊頁面中填寫個人信息，如使用本系統(tǒng)的賬號名和密碼,聯(lián)系地址等。在提交表單、完成注冊后，系統(tǒng)將保存信息，以方便管理員管理用戶信息、聯(lián)系用戶。如果用戶已經(jīng)在系統(tǒng)中注冊過，可以在登錄頁面輸入賬號名和密碼。如果密碼正確，用戶就可以購物，否則只能做一般的頁面瀏覽。進(jìn)入系統(tǒng)后，用戶也可選擇維護(hù)自己的信息，比如修改賬號名，密碼，聯(lián)系地址等。如果直接進(jìn)行購物，系統(tǒng)可讓用戶首先瀏覽商品信息，使之對商品的數(shù)量、種類有一個大概的了解。如果用戶對某件商品感興趣，就可以選擇特定商品查看其詳細(xì)信息，接著選擇將商品加入購物車，或繼續(xù)查看其他商品。當(dāng)購物結(jié)束時，用戶首先要瀏覽一下已經(jīng)存在于購

16、物車中的商品項(xiàng)目，包括數(shù)量、單價及總價。這時用戶可以更改任何已存在購物車中的商品數(shù)量。如果確定要購買購物車內(nèi)的商品，系統(tǒng)即生成一份訂購商品的訂單（包括所有商品的名字，單價，小計(jì)，總價），然后由用戶填寫包括用戶姓名、家庭地址、信用卡號碼、電子郵件地址等信息，并提交訂單。以后，系統(tǒng)自動將用戶信息、信用卡信息和購物總價發(fā)送到銀聯(lián)系統(tǒng)，由銀聯(lián)系統(tǒng)驗(yàn)證信用卡信息并執(zhí)行扣款，并將銀聯(lián)系統(tǒng)操作成功與否的信息返回到系統(tǒng)。系統(tǒng)根據(jù)銀聯(lián)系統(tǒng)的操作結(jié)果，向用戶發(fā)送E-MAIL，提示用戶操作成功與否的消息。如果扣款成功，就與物流系統(tǒng)接口，安排給用戶派送購買的商品。管理員進(jìn)入系統(tǒng)時，首先要輸入口令。如果檢查通過，就可以對系統(tǒng)中的信息進(jìn)行維護(hù)和管理，包括： 管理用戶信息。當(dāng)有些用戶有不正常操作時，如填寫訂單時使用不存在的信用卡號，可以將此用戶賬號凍結(jié)，也可以啟用用戶賬號。但管理員無權(quán)修改客戶信息； 管理系統(tǒng)中的商品信息，例如有新的商品時，管理員可向系統(tǒng)中添加此商品。當(dāng)商品的價格或規(guī)格發(fā)生浮動時，管理員也可以對它們作修改，使用戶及時了解商品的最新情況。若某件商品沒有存貨或不再出售時，管理員可刪除系統(tǒng)中的此項(xiàng)商品記錄。 管理客戶定單。及時獲得客戶的資料（資料中有電子郵件地址），以便與客戶聯(lián)系。要求系統(tǒng)對數(shù)據(jù)庫的存取速度要盡量快，并保