目錄

m1.理解需求 m2.基於用例的需求描述 m3.用例的獲取 m4.用例圖

2.1 理解需求

需求就是系統（更廣義的說法是專案）必須提供的能力和必須遵從的條件

m1.需求涉及到誰？ Ø客戶（Client）-為開發付錢的人，將來是產品的擁有者。 Ø顧客（Customer）-買商品化軟體的人，或者將來有發言權確定產品是否可以接受。可能與客戶是同樣的人。 Ø涉眾（stakeholder）-任何對系統需求有直接或間接影響的人。 m2.需求的分類 Ø功能需求：系統必須提供服務的描述，系統應該如何響應特定的輸入，系統在特定的情景下的行為

例：使用者能夠搜尋所有的資料集合或者從中選擇一部分進行搜尋

Ø非功能需求：對系統提供服務或者功能的約束，如時間約束，開發過程的約束，標準等；

許多需求是非功能性的，只能夠描述系統的屬性或者系統環境的屬性。 例：系統能夠在1分鐘內處理100次交易。

m3.FURPS+需求模型

縮寫FURPS 描述了需求的主要類別：

ØFunctionality（功能性） ØUsability （可用性） ØReliability （可靠性） ØPerformance （效能） ØSupportability（可支援性） Ø功能性  •特性集（featuresets) •功能（capabilities） •安全性（security） Ø可用性 •人性化因素(RelatedConcepts: User-Centered Design) •美學特性(aesthetics) •使用者介面的一致性（consistencyin the user interface） •線上和上下文相關的幫助（onlineand context-sensitive help） •智慧助手（wizardsand agents） •使用者文件（userdocumentation） •訓練材料（trainingmaterials） Ø可靠性 •失效頻率和嚴重性（frequencyand severity of failure） •可恢復性（recoverability） •可預測性（predictability） •精度（accuracy） •平均失效時間（meantime between failure (MTBF)） Ø效能 •速度（speed）                   效率（efficiency） •可用性（availability）     精度（accuracy） •吞吐量（throughput）     響應時間（response time） •恢復時間（recoverytime） •資源利用率（resourceusage） Ø可支援性 •可測試性（testability） •可擴充套件性（extensibility） •適應性（adaptability） •可維護性（maintainability） •匹配性（compatibility） •可配置性（configurability） •可服務性（serviceability） •可安裝性（installability） •本地化，國際化(localizability,internationalization) mFURPS+中的“+”號意味著還有一些其他的約束，如: Ø設計約束（design constraints） Ø實現需求implementation requirements Ø介面需求interface requirements Ø物理需求physical requirements Ø包裝Packaging Ø授權等等Legal-licensing and so forth 2.2  基於用例的需求描述 m1.參與者、場景、用例 Ø參與者（actor）：是某些具有行為的事物，可以是人（由角色標識）、計算機系統或是組織。 Ø 場景（scenario）：是參與者和系統之間特定的活動和互動，也稱為用例例項（use case instance）。場景是使用系統的一個特定情節或用例的一條執行路徑。

什麼是用例

Ø“一組用例的例項，其中每個例項都是系統執行的一系列活動，這些活動產生了對每個參與者而言可觀察的返回值” Ø 描述了從參與者角度看系統（黑盒子）做了什麼 Ø 用例模型本身不是面向物件建模技術 m2.用例的好處 Ø從使用者的角度獲取操作性需求 Ø 對系統的功能進行清晰而一致的描述 Ø 系統測試的基礎 Ø 提供了從功能需求跟蹤到系統中真正的類和操作的能力 m3.理解用例 Ø 用例是需求，而且主要是功能需求。 Ø 用例是需求，而不是功能或者特徵列表。 Ø 用例是文件，而不是圖，用例建模主要是寫文字，而

不是畫圖。

Ø 用例Use Case:一組相關的成功和失敗場景集合，用

來描述參與者如何使用系統實現其目標

m4.用例的表示法 Ø摘要：簡介描述用例，通常只給出主成功場景。 Ø 非正式：用若干非正式段落來描述用例，通常給出多個不同場景。 Ø 詳述：詳細描述用例，通常給出所有的步驟及場景，並給出前置和後置條件等細節。 m緒言 Ø範圍：系統用例，業務用例 Ø級別：使用者目標級別，子功能級別（可被許多用例重複使用的） Ø主要角色 Ø涉眾 Ø前置條件和後置條件 m主成功場景和步驟（或基本流程） m擴充套件（或替代流程） m特殊需求：非功能性需求，質量屬性或約束 m技術和資料變元表：使用者對如何實現系統的要求 m範圍：業務用例 m級別：使用者目標 m主要參與者：學生 m涉眾及其關注點： Ø—學生：希望能網上選課，並可以準確獲知待選課程和待修學分，並快速完成選課。 Ø—教務管理員：希望準確記錄每個學生的選課情況，並能自動篩選統計選修每門課程人數，方便進行課程班的設立和授課教師的安排。有較強的容錯能力。 Ø—教師：希望方便準確查詢選課學生的名單。 m前置條件：教務管理員已經設立好待選課程，並開發網上選課。 m後置條件：記錄學生的選課資訊，更新選課資料庫。 m主成功場景(基本流程)： Ø1.學生輸入學生證號以及個人密碼； Ø2.系統識別學生身份的有效性； Ø3.系統對學生進行註冊識別； Ø4.系統顯示學生本學期的待選課程 Ø5.學生自己要上的課程並確認； Ø6.退出時，系統給出所選課程列表及相應學分合計。 m擴充套件（替代流程）： Ø2a.學生身份檢查失敗，提示重新輸入（3次機會）。 Ø3a.註冊識別失敗，提示沒有註冊（尚未交學費）的學生不能選課。 Ø5b.選擇課程確認失敗，所選幾門課程中在上課時間上發生衝突時，系統提示重選。 m特殊要求： Ø1.能同時允許2000以上人同時進行選課； Ø2.系統應具備較強的資料恢復能力； Ø3.選課期間每個2小時資料備份一次 m技術和資料變元表： Ø1.支援網上選課。 Ø2.能自動進行上課時間是否衝突以及選課學分是否滿足要求的判斷。 m發生頻率： Ø每學期末發生頻率高約20000人次，其他時間不選課。 m5.用例的作用 Ø可作為計劃的基礎。可以估算實現每個用例所需的時間和資源 Ø可用來捕獲功能需求。它們是分析、設計和實現的基礎 Ø可作為軟體測試的基礎。測試人員可將那些在用例中描述的訊息序列以及動作序列作為測試指令碼來驗證系統的功能 Ø可作為文件的基礎

2.3 用例的獲取

m1.主要過程 Ø（1）選擇系統邊界 Ø（2）尋找參與者 Ø（3）確定每個參與者的目標 Ø（4）定義用例 m2.確定系統邊界

可能的系統：

Ø整個組織：如一個企業； Ø一個組織的某個部門：如企業的財務處； Ø計算機系統的硬體/軟體邊界：如企業的進、銷、存計算機管理系統。

系統邊界作用：

Ø定義系統問題域的目標、任務、規模及系統提供的功能。 Ø系統中所有元素與系統外事物的分界線 m3.尋找參與者

參與者是與系統交換資料的實體。參與者可以是使用者，外部的硬體或者另外一個系統。

m1）參與者的識別。可通過以下問題進行尋找： Ø系統的主要客戶是誰？ Ø誰從該系統中獲取資訊？ Ø誰向系統中提供資訊？ Ø誰來安裝系統？ Ø誰來作業系統？ Ø誰來關閉系統？ Ø在預定的時刻，是否有事件自動發生？ Ø誰使用或者刪除系統中的資訊？ Ø系統從何處獲得資訊？ m2）參與者的分類 Ø主要參與者：從系統獲取資訊的使用者，是執行系統主要功能的參與者。（何種服務、業務需求、時間、效能及介面等） Ø次要參與者：僅僅給用例提供某種服務。（何種服務、時間、效能、介面等） m3）參與者的職責 Ø啟動者：何種事件、時間因素、介面 Ø服務者：何種服務、介面、時間、資料量等 Ø接收者：何種資訊、介面 Ø輔助者：何種服務、介面 m4）參與者和系統邊界的關係
m5）參與者的規約模板

m4. 定義用例

一般而言，為每一個使用者目標定義用例

Ø用例名稱以動詞開頭 Ø將CRUD (create, retrieve, update, delete)這些分散的目標合併成一個CRUD用例：管理 <X> m1）定義用例的粒度 Ø大的用例，如：我們的企業需要拓寬銷售渠道；

整個系統就只有一個用例!!!

Ø小的用例，如：輸入口令；

系統中可能有成百上千個用例!!!

m2）用例的經驗方法 Ø老闆測試 •老闆是付錢的人 •老闆必須看到可量化的價值 ØEBP（elementary business processes）用例 •定義：一個人於某時刻在一個地點所執行的任務，用以響應業務事件。該任務能夠增加可量化的業務價值，並且以持久狀態留下資料。例如批准信用卡額度。 •關注於基本業務過程層面上用例 Ø規模測試 •用例通常應該包括多個步驟 •在詳細描述的情形下，應該需要3-10頁文字 m3）用例的分類

根據用例產生的階段，可把用例分為業務用例和系統用例。

Ø業務用例 •系統提供的業務功能與執行者的互動，描述問題域中各實體之間的聯絡和業務往來。 Ø系統用例 •系統用例是指執行者與系統的互動，它描述系統的功能需求和動態行為。對於建立的每一項業務用例，都需要一組系統用例來輔助和支援。系統用例可通過分析系統的業務流和控制流來確定。

2.4 用例圖

用例圖是表達用例和參與者及其之間關係的載體。

由主題（subject）、

參與者、用例、

關係組成。

m1. 參與者與用例之間的關係

參與者類和用例類之間的關係是關聯關係，它指明瞭參與者類和包含用例類的系統之間的通訊關係

m2.用例之間的關係

1)包含關係(include)

一個用例可以簡單地包含其他用例具有的行為，並把它所包含的用例行為做為自身行為的一部分，這被稱作包含關係。

m2)擴充套件關係(extend)

擴充套件關係是從擴充套件用例到基本用例的關係，它說明為擴充套件用例定義的行為如何插入到為基本用例定義的行為中。以下情況，可使用擴充套件用例：

a.表明用例的某一部分是可選的系統行為；

b.表明只在特定條件（如例外條件）下才執行的分支流；

c.表明可能有一組行為段，其中的一個或多個段可以在基本用例中的擴充套件點處插入。所插入的行為段和插入的順序取決於在執行基本用例時與主角進行的互動。

3)泛化關係(Generalization)

一個用例也可以被特別列舉為一個或多個子用例，這種關係稱作泛化關係：

n父用例能夠被使用時，任何子用例也可以被使用 n子用例可以存取和修改由父用例定義的屬性 n子用例行為序列中必須包含其父用例的行為序列 n子用例可以在繼承自父用例的行為序列中插入其它與父用例無關的步驟
m3. 參與者之間的關係

參與者之間可以存在泛化關係。

m4.建模技術 Ø對系統語境建模

給定一個系統，會有一些事物存在與它的內部，一些存在與外部。存在於系統內部的事物的職責是完成系統外部事物期望系統提供的行為。

所有存在與系統外部並於系統進行互動的事物構成了該系統的語境（context）。語境定義了系統存在的環境。

對系統語境建模，所強調的是圍繞在系統周圍的參與者。

語境建模策略

u決定哪些行為是系統的一部分以及哪些行為是外部實體所執行的，以此識別系統的邊界。這也同時定義了主題。 u考慮以下幾組事物來識別系統周圍的參與者： u需要從系統中得到幫助以完成其任務的組 u執行系統的功能時所需要的組 u與外部硬體或其它軟體系統進行互動的組 u為了管理和維護而執行某些功能的組 u將彼此類似的參與者組織成一般/特殊層次結構 u在需要加深理解的地方，為每個參與者提供一個構造型。 Ø對系統需求建模

需求是系統的設計特徵、特性或行為。陳述系統的需求，相當於陳述系統外部的事物與系統之間建立的一份合約，該合約聲明瞭希望系統做什麼事。大多數情況下，並不關心繫統怎麼做。

需求建模策略

u通過識別系統周圍的參與者來建立系統的語境。 u對於每個參與者，考慮它期望的或需要系統提供的行為。 u把這些公共行為命名為用例。 u分解公共行為，放入新的用例中以供其他用例使用；分解異常行為，放入新的用例中以延伸較為主要的控制流。 u在用例圖中對這些用例、參與者以及他們的關係進行建模 u用陳述非功能需求的註解或約束來修飾這些用例。 m提示語技巧

一個結構良好的用例圖，應滿足一下要求：

Ø關注與系統的靜態用例檢視的一個方面的通訊 Ø只包含那些對於理解這個方面必不可少的用例和參與者。 Ø提供與它的抽象層次相一致的詳細標示，只能加入那些對於理解問題必不可少的修飾（比如擴充套件點） Ø沒有簡化到使讀者誤解其重要的語義的程度。

繪製用例圖的策略

Ø給出一個表達其用途的名稱。 Ø擺放元素時，儘量減少線的交叉。 Ø從空間上組織元素，使得在語義上接近的行為和角色在物理位置上也接近。 Ø用註解和顏色作為視覺化提示，以突出圖的重要的特徵。 Ø嘗試不顯示太多的關係種類。

小結

m使用者模型檢視從使用者角度來描述系統所應具有的功能，其基本成分是系統、參與者和用例 m參與者是與系統發生互動作用的外部使用者、程序或其它系統的理想化概念。一個實際使用者可能對應系統的多個參與者。不同的使用者也可以只對應於一個參與者。每個參與者可以參與一個或多個用例 m參與者之間可以存在泛化關係，參與者和用例存在之間存在通訊關係，用例之間則可以存在包含、擴充套件和泛化三種關係