使用案例描述說明參與者如何透過與系統互動來達成目標。它與使用案例圖相互補充：

• 使用案例圖：顯示參與者、系統範圍及關係。

• 使用案例描述：說明詳細的行為、條件、規則與結果。

圖提供地圖；描述提供路線。

1. 什麼是使用案例？

使用案例代表外部參與者透過系統達成的一項具價值目標。

範例：

• 客戶下訂單

• 員工提出費用報銷申請

• 病患預約會面

• 管理員建立使用者帳戶

• 客戶重設密碼

良好的使用案例應具備：

• 以目標為導向

• 對參與者具價值

• 從使用者角度描述

• 不依賴特定的畫面配置

• 聚焦於可觀察的系統行為

不佳與改善後的使用案例名稱

使用短語動詞–名詞短語，例如「提交費用報銷, 追蹤貨運，或 核准貸款申請.

2. 關鍵概念

2.1 參與者

參與者是指與系統互動的外部角色。

參與者可能是：

• 一個人

• 一個組織

• 另一個軟體系統

• 一個硬體裝置

• 一個排程或基於時間的觸發器

範例：

• 客戶

• 支援專員

• 倉務員

• 金流閘道

• 電子郵件服務

• 管理員

參與者是一個角色，不一定是特定個人。例如，「顧客」通常比「珍·史密斯」更好。

主要參與者與支援參與者

「主要參與者」啟動使用案例以達成目標。

「支援參與者」在執行期間協助系統。

範例：

• 主要參與者：顧客

• 支援參與者：金流閘道

• 使用案例：下訂單

顧客啟動訂單，而金流閘道負責授權付款。

2.2 系統邊界

系統邊界定義了被建模系統內部的內容。

對於線上商店，邊界可能包含：

• 瀏覽商品

• 將商品加入購物車

• 下訂單

• 進行付款

• 追蹤訂單

以下項目位於邊界之外：

• 顧客

• 金流閘道

• 配送公司

• 電子郵件服務提供者

邊界可防止對系統責任產生混淆。

2.3 使用案例

使用案例應描述能產生有意義結果的完整互動。

例如：

下訂單：顧客選擇商品、提供送貨資訊、支付訂單款項，並收到訂單確認。

「驗證信用卡號碼」可能是一個系統功能，但通常太小，無法成為獨立的用戶目標。它可能只是「下訂單」或「進行付款.

2.4 前置條件

前置條件說明在使用案例開始前必須已經為真的事項。

範例：

• 顧客擁有有效的帳號。

• 商品可供銷售。

• 員工已通過驗證。

• 預約時段存在。

• 購物車內至少包含一項商品。

前置條件並非使用案例所執行的動作。

不佳的前置條件：

顧客登入。

較佳的前置條件：

顧客已通過驗證。

2.5 後置條件

後置條件說明在使用案例結束後為真的事項。

範例：

• 訂單已記錄。

• 付款已獲授權。

• 已發送確認電子郵件。

• 該費用報銷申請已處於已提交狀態。

• 該用戶帳戶已標記為啟用狀態。

後置條件應描述結果，而非實現細節。

不佳的後置條件：

「訂單」資料表已更新。

較佳的後置條件：

訂單已儲存並可供履行。

2.6 主要成功場景

主要成功場景，也稱為「基本流程」或「快樂路徑」，描述正常的成功互動。

每個步驟應描述：

1. 參與者與系統之間的互動

2. 系統回應

3. 有意義的業務動作

範例：

1. 顧客選擇商品。

2. 系統顯示目前購物車。

3. 顧客輸入配送資訊。

4. 系統驗證配送資訊。

5. 顧客提交訂單。

6. 系統請求付款授權。

7. 付款閘道授權付款。

8. 系統記錄訂單。

9. 系統顯示訂單確認訊息。

除非對需求至關重要，否則避免使用與介面相關的細節。

不佳的步驟：

客戶點擊右下角的藍色按鈕。

較佳的步驟：

客戶提交訂單。

2.7 替代流程

替代流程描述主要情境的有效變體。

範例：

• 客戶選擇門市取貨而非配送。

• 客戶使用已儲存的付款方式進行付款。

• 管理員核准附有條件的申訴。

• 使用者使用一次性代碼進行驗證。

替代流程可能會重新加入主要流程。

範例：

A1. 客戶使用已儲存的付款方式
在第 6 步，客戶選擇已儲存的付款方式。系統使用該方式請求授權，然後繼續執行第 7 步。

2.8 異常流程

異常流程描述失敗或異常的情況。

範例：

• 付款遭拒絕。

• 商品缺貨。

• 驗證失敗。

• 外部服務不可用。

• 所需資料無效。

異常流程應說明：

• 問題發生的位置

• 系統採取的行動

• 參與者所見的內容

• 使用案例是否結束或恢復

範例：

E1. 付款遭拒
在第 7 步，支付閘道拒絕該交易。系統顯示原因，將訂單標記為未付款，並允許客戶選擇其他付款方式。

2.9 包含與延伸關係

包含」

使用「包含」，當一個使用案例總是呼叫另一個可重用的行為時。

範例：

• 下訂單 包含 計算總額

• 下訂單 包含 驗證客戶身份

• 提領現金 包含 驗證個人識別碼

被包含的行為是必需的。

下訂單 <<包含>> 計算總額

延伸」

使用「延伸」，當一個可選或條件式行為補充基礎使用案例時。

範例：

• 下訂單 可被 套用折扣碼 延伸

• 結帳 可被 新增禮物留言 延伸

延伸的行為並非總是執行。

套用折扣碼 <<延伸>> 下訂單

一個實用的規則：

• 包含：「這總是作為使用案例的一部分發生。」

• 延伸：「這可能在特定條件下發生。」

請勿使用「包含」與「擴展僅僅是為了將每個流程拆分成小塊。過度分解會使模型難以理解。

2.10 泛化

泛化表示參與者或使用案例之間的繼承關係。

範例：

• 員工是一般參與者。

• 經理是繼承員工行為的專門參與者。

經理 --|> 員工

當專門元素確實是泛化元素的一種類型時，才使用泛化，而不僅僅是因為兩個元素共享幾個步驟。

3. 標準使用案例描述範本

以下範本適用於需求文件、專案規格說明和分析模型。

使用案例 ID:
使用案例名稱:
目標:
範圍:
層級:
主要參與者:
支援參與者:
利害關係人與利益:

觸發條件:

前置條件:

最小保證:

成功保證:

主要成功場景:
1.
2.
3.

替代流程:
A1.
A2.

例外流程:
E1.
E2.

特殊需求:
- 效能
- 安全性
- 可用性
- 可用性
- 合規性

業務規則:

資料需求:

頻率與容量:

假設:

未解問題:

相關使用案例:

欄位說明

4. 範例：下訂單

UC-001 — 下訂單

目標：
允許顧客購買一項或多項產品。

範圍：
線上商店

層級：
使用者目標

主要參與者：
顧客

輔助參與者：

• 金流閘道

• 庫存服務

• 電子郵件服務

• 配送服務

利害關係人與利益：

• 顧客：希望成功購買產品並收到確認。

• 商店：希望記錄有效訂單並收取款項。

• 倉庫：需要準確的履約資訊。

• 金流閘道：需要有效的付款請求。

• 配送服務：需要完整的配送地址。

觸發條件：
顧客提交購物車以進行結帳。

前置條件：

• 購物車中至少有一項商品。

• 商品可供訂購。

• 顧客提供有效的配送地址。

• 系統能夠與付款服務進行通訊。

基本保證：

• 任何未付款的訂單均不被視為已確認。

• 若訂單無法完成，將通知顧客。

• 若付款失敗，已保留的庫存將被釋放。

成功保證：

• 付款已獲授權。

• 訂單已記錄。

• 庫存已保留。

• 客戶收到確認。

• 履約資訊已提供給倉庫。

主要成功情境

1. 客戶檢視購物車。

2. 系統顯示產品、數量、價格、稅金、運費及總金額。

3. 客戶提供送貨資訊。

4. 系統驗證送貨資訊。

5. 客戶選擇付款方式。

6. 客戶提交訂單。

7. 系統檢查產品庫存狀況。

8. 系統向付款閘道請求付款授權。

9. 付款閘道授權付款。

10. 系統建立訂單。

11. 系統保留所訂購的產品。

12. 系統向客戶發送訂單確認。

13. 系統顯示訂單編號及預估送達日期。

替代流程

A1. 客戶使用已儲存的地址

在第 3 步，客戶選擇先前儲存的地址。系統顯示該地址並繼續執行第 4 步。

A2. 客戶使用已儲存的付款方式

在第 5 步，客戶選擇已儲存的付款方式。系統採用該方式並繼續執行第 6 步。

A3. 客戶選擇門市取貨

在第 3 步，客戶選擇門市取貨而非送貨。系統顯示可用門市及取貨日期，然後繼續執行第 5 步。

例外流程

E1. 產品無貨

在第 7 步，系統判定某產品無貨。系統識別該無貨產品，更新購物車，並請客戶檢視訂單。

E2. 付款遭拒

在第 9 步，支付網關拒絕付款。系統不會確認訂單、釋放庫存保留、顯示失敗訊息，並允許客戶選擇另一種付款方式。

E3. 支付網關無法使用

在第 8 步，支付網關未能在設定的超時時間內回應。系統將付款嘗試標記為待處理，通知客戶，並防止重複提交訂單。

業務規則

• 訂單必須包含至少一項產品。

• 產品數量必須大於零。

• 當可用庫存不足時，不得訂購該產品。

• 訂單確認前必須完成付款授權。

• 價格與稅金須依據現行定價規則計算。

• 客戶僅可在履行程序開始前取消訂單。

特殊需求

• 在正常負載下，訂單摘要應於兩秒內顯示。

• 付款資訊不得以純文字儲存。

• 重複提交不得產生重複訂單。

• 系統必須記錄付款與訂單狀態變更的稽核軌跡。

5. 使用案例層級

使用案例描述可撰寫於不同詳細程度的層級。

摘要層級使用案例

摘要使用案例描述廣泛的業務流程。

範例：

履行客戶訂單

此可能包含：

• 接收訂單

• 揀選產品

• 包裝訂單

• 發貨訂單

使用者目標層級使用案例

此通常是需求分析中最實用的層級。

範例：

下訂單

它描述了一個主要參與者可在一次會話中達成目標。

子功能層級的使用案例

這描述了一個較小且可重複使用的系統行為。

範例：

• 計算訂單總額

• 驗證付款

• 產生發票

當行為被重複使用或技術上複雜時，子功能層級的使用案例很有用，但它們不應用於取代使用者目標的使用案例。

6. 撰寫高品質的使用案例描述

使用以參與者為中心的語言

從參與者的角度撰寫：

客戶提交訂單。

避免使用以實作為中心的措辭：

OrderController 呼叫訂單服務。

後者應屬於設計文件，而非業務使用案例。

保持每個步驟為原子性

避免合併過多動作：

客戶輸入詳細資料、選擇付款方式、確認訂單並收到電子郵件。

透過將互動分開來改進：

1. 客戶輸入送貨資訊。

2. 系統驗證該資訊。

3. 客戶選擇付款方式。

4. 客戶確認訂單。

5. 系統傳送確認訊息。

描述可觀察的行為

讀者應能判斷該需求是否已實現。

薄弱：

系統處理該請求。

較強：

系統驗證請求、記錄索賠、分配索賠編號，並顯示提交狀態。

避免過早進行使用者介面設計

使用：

客戶提供配送資訊。

而非：

客戶將地址輸入文字方塊，並點擊綠色的「繼續」按鈕。

第二種版本不必要地限制了介面。

保持主流程順利成功

不要在基本流程中納入所有可能的錯誤。將錯誤置於例外流程中。

單獨識別業務規則

業務規則通常適用於多個使用案例。將其分開可避免重複且不一致的文字。

明確說明失敗行為

針對每個重要失敗，請指定：

• 資料是否已儲存

• 交易是否已回滾

• 參與者是否可以重試

• 是否通知管理員

• 使用案例是否結束或恢復

7. 從需求到使用案例

一個實用的工作流程如下：

1. 識別正在建模的系統。

2. 列出外部參與者。

3. 詢問每個參與者希望達成什麼目標。

4. 將每個目標轉換為使用案例名稱。

5. 定義系統邊界。

6. 撰寫主要成功情境。

7. 加入替代流程與例外流程。

8. 加入業務規則與特殊需求。

9. 繪製使用案例圖。

10. 與利害關係人共同審查模型。

11. 將使用案例連結至需求、測試與設計產出。

角色目標分析

一個有幫助的問題是：

此角色需要系統達成什麼業務成果？

8. 使用案例圖標記法

最常見的要素包括：

• 角色：外部角色

• 使用案例：系統能力或參與者目標

• 系統邊界：系統範圍

• 關聯：參與者參與使用案例

• 包含：所需的重用行為

• 擴展：選取或條件式行為

• 泛化：專門的參與者或使用案例

使用案例圖不應嘗試顯示：

• 每個工作流程步驟

• 資料表

• 類別屬性

• 詳細的業務規則

• 畫面配置

• 內部演算法

這些應屬於活動圖、類別圖、序列圖或書面需求。

9. PlantUML 圖表示範例

下列範例模擬了「下訂單」使用案例及其相關行為。

@startuml
left to right direction

skinparam packageStyle rectangle
skinparam shadowing false
skinparam usecase {
    BackgroundColor #F8FBFF
    BorderColor #2F5597
    ArrowColor #555555
}

actor Customer
actor "Payment Gateway" as Payment
actor "Inventory Service" as Inventory
actor "Email Service" as Email
actor "Delivery Service" as Delivery

rectangle "Online Store" {
    usecase "Browse Products" as Browse
    usecase "Manage Cart" as Cart
    usecase "Place Order" as PlaceOrder
    usecase "Calculate Order Total" as CalculateTotal
    usecase "Check Product Availability" as CheckStock
    usecase "Authorize Payment" as AuthorizePayment
    usecase "Reserve Inventory" as ReserveInventory
    usecase "Send Order Confirmation" as SendConfirmation
    usecase "Track Order" as TrackOrder
    usecase "Apply Discount Code" as ApplyDiscount
}

Customer --> Browse
Customer --> Cart
Customer --> PlaceOrder
Customer --> TrackOrder

Payment --> AuthorizePayment
Inventory --> CheckStock
Inventory --> ReserveInventory
Email --> SendConfirmation
Delivery --> TrackOrder

PlaceOrder ..> CalculateTotal : <<include>>
PlaceOrder ..> CheckStock : <<include>>
PlaceOrder ..> AuthorizePayment : <<include>>
PlaceOrder ..> ReserveInventory : <<include>>
PlaceOrder ..> SendConfirmation : <<include>>

ApplyDiscount ..> PlaceOrder : <<extend>>

@enduml

解釋

• 「顧客」 啟動 下訂單.

• 下訂單 始終包含計算、庫存檢查、付款授權、庫存保留與確認。

• 套用折扣碼 為選填項目，因此它會延伸 下訂單.

• 外部服務參與特定的系統行為。

• 系統邊界為 線上商店 矩形。

元素的精確位置由渲染引擎控制。重要的建模決策包括參與者、使用案例、邊界與關係。

10. 在 Visual Paradigm VPasCode 中建立圖表

VPasCode 是一個基於瀏覽器的文字轉圖表平台，支援 PlantUML、Mermaid、Graphviz 及其他圖表格式。它提供原始碼編輯與即時渲染，讓圖表能隨著程式碼的變更而自動更新。

基本工作流程

1. 開啟 VPasCode 編輯器。

2. 建立新的 PlantUML 圖表。

3. 貼上 PlantUML 原始碼。

4. 確認編輯器能識別 PlantUML 語法。

5. 檢視即時預覽。

6. 在原始碼窗格中編輯參與者、使用案例、關係與樣式。

7. 匯出或複製已渲染的圖表。

8. 將圖表加入專案文件。

VPasCode 支援 PlantUML 使用案例圖表，並在瀏覽器中提供即時渲染。它還提供 PlantUML 圖表的範例與樣式選項。

AI 輔助生成範例提示

若使用 AI 圖表生成功能，一個有用的提示為：

建立線上商店的 PlantUML 使用案例圖表。

主要參與者：
- 顧客

支援參與者：
- 金流閘道
- 庫存服務
- 電子郵件服務
- 配送服務

主要使用案例：
- 瀏覽商品
- 管理購物車
- 下訂單
- 追蹤訂單

下訂單必須包含：
- 計算訂單總額
- 檢查商品庫存
- 授權付款
- 保留庫存
- 發送訂單確認

套用折扣碼應延伸自下訂單。

使用名為「線上商店」的系統邊界。

將生成的程式碼視為起點。請檢視是否：

• 參與者確實是外部的

• 使用案例代表使用者目標

• 包含 和 延伸 使用正確

• 系統邊界準確

• 關聯反映真實的業務行為

VPasCode 也支援在基於文字的圖形編輯與 Visual Paradigm 的圖形化建模工具之間切換，當團隊希望進行基於原始碼的版本控制以及用於版面細化的視覺編輯時，這將非常有用。

11. 維護 PlantUML 使用案例圖

使用有意義的別名

別名讓關聯更易於維護：

usecase "下訂單" as PlaceOrder
Customer --> PlaceOrder

新增註解

' 核心客戶交易
usecase "下訂單" as PlaceOrder

註解有助於其他團隊成員理解原始碼並維護圖形。

保持圖形專注

如果圖形包含太多使用案例：

• 建立情境圖

• 按業務領域建立獨立圖形

• 使用套件分組

• 透過文件連結相關圖形

• 避免在最上層顯示所有子功能

使用一致的命名

選擇一種規範並一致地應用它：

• 下訂單

• 取消訂單

• 追蹤訂單

避免混用風格，例如：

• 下訂單

• OrderCancellation

• tracking_function

將原始檔案與專案一併儲存

典型的儲存庫結構可能如下：

docs/
  use-cases/
    UC-001-place-order.md
    UC-002-track-order.md
  diagrams/
    online-store-use-cases.puml

將.puml原始檔案納入版本控制，可讓變更可審查且可重現。

12. 可追溯性

成熟的需求流程會將使用案例與其他專案產出連結起來。

可追蹤性有助於回答以下問題：

• 哪些需求已涵蓋？

• 哪些使用案例尚未測試？

• 哪些設計元件支援業務目標？

• 若需求變更，哪些項目會受到影響？

13. 常見錯誤

將內部元件建模為參與者

若資料庫或內部服務位於系統邊界內，通常不視為參與者。

參與者必須位於被建模系統的邊界之外。

將畫面視為使用案例

畫面是用戶介面元素，未必代表用戶目標。

使用：

提交費用報銷申請

而非：

費用報銷申請畫面

使用「包含」來處理每個共用步驟

僅有共用詞彙不足以作為建立包含使用案例的依據。請在以下情況使用「包含」：當該行為為必要且具獨立意義時。

使用「延伸」來處理一般步驟

若某行為必然發生，則不應將其建模為延伸。

撰寫實作細節

避免提及以下項目：

• 控制器

• 資料表

• API 端點

• 類別

• 內部方法

除非該文件明確為技術設計。

省略失敗行為

若使用案例僅說明成功情況，則其不完整。應涵蓋付款拒絕、無效資料、逾時、授權失敗及資源不可用等情境。

使用案例過於寬泛

「管理整個業務」並非可執行目標。應將寬泛目標拆解為使用者目標層級的使用案例。

使用案例過於細小

「驗證欄位」與「顯示訊息」通常屬於系統步驟，而非獨立參與者的目標。

14. 審查檢查表

在核准使用案例描述前，請確認：

範圍與參與者

• 系統邊界是否明確？

• 是否已識別所有外部參與者？

• 參與者是否為角色而非個人姓名？

• 支援系統是否僅在為外部系統時才進行建模？

目標品質

• 該使用案例是否為主要參與者提供價值？

• 名稱是否為清晰的動詞–名詞片語？

• 該使用案例是否處於適當的層級？

流程品質

• 主要情境是否描述成功結果？

• 每個步驟是否為原子性且可觀察的？

• 替代路徑是否已記錄？

• 例外路徑是否已記錄？

• 復原行為是否明確？

條件與結果

• 前置條件是否可測試？

• 成功保證是否明確？

• 是否已定義最低限度保證？

• 業務規則是否與程序步驟分開？

圖表品質

• 所有使用案例是否都在正確的邊界內？

• 參與者的關聯是否有意義？

• 是否「包含」關聯是強制性的嗎？

• 是否「延伸」關聯是選填的或條件性的？

• 圖表是否在沒有過多細節的情況下仍可閱讀？

需求品質

• 每個重要步驟是否可測試？

• 是否已包含非功能性需求？

• 未解決的問題是否已記錄？

• 使用案例是否已連結至需求與測試案例？

15. 建議交付物結構

對於完整的專案套件，請使用以下結構：

1. 系統情境
2. 參與者目錄
3. 使用案例圖
4. 使用案例目錄
5. 詳細使用案例描述
6. 業務規則
7. 非功能性需求
8. 可追蹤矩陣
9. 開放問題與假設
10. PlantUML 原始檔

強而有力的使用案例描述必須對分析師而言足夠精確、對利害關係人而言可理解，並可由品質保證團隊進行測試。最佳工作流程是：使用書面描述來定義行為，使用使用案例圖來溝通範圍與關聯，並在 VPasCode 中使用 PlantUML 以保持視覺模型易於編輯與維護。

參考資料