連接願景與執行：掌握用例描述的案例研究

Table of Contents hide

1 引言

2 1. 基礎概念

3 2. 標準規格模板

4 3. 實例研究敘述：UC-201 提領現金

引言

在現代軟體工程中，需求未對齊仍是導致專案延遲、範圍蔓延與利害關係人不滿的主要原因。雖然視覺化建模技術如用例圖能有效呈現系統邊界、參與者與高階目標，但其本質上缺乏開發、測試與品質保證所需的細節層級。這正是 用例描述 變得不可或缺。

精心撰寫的用例敘述能將抽象的系統目標轉化為可執行、逐步明確的規格。透過記錄精確的互動、決策點與錯誤處理路徑，團隊建立單一可信來源，使產品經理、開發人員、測試人員與業務分析師達成一致。本案例研究探討有效用例文件的結構組成，展示結構化敘述、標準化模板與補充性視覺模型如何整合，產出清晰無誤的功能規格。透過實際的自動櫃員機提款情境，我們將檢視如何捕捉業務邏輯、管理偏差，並從概念到實作維持可追溯性。

Mastering Use Case Descriptions

1. 基礎概念

在撰寫詳細規格之前，理解賦予用例結構完整性的核心元件至關重要：

參與者： 任何與系統互動以達成目標的實體（人、外部系統或硬體）。
- 主要參與者： 啟動互動以達成特定目標（例如：銀行客戶）。
- 次要／支援參與者： 在執行過程中為系統提供必要服務或資料（例如：核心銀行 API 或付款網關）。
前置條件： 用例開始前系統或環境必須已存在的狀態。這些條件被假設為成立，且在流程中不會進行驗證。
觸發事件： 啟動用例的特定事件或使用者操作。
主要成功情境（基本流程）： 能導致參與者目標成功完成的最優、無錯誤步驟序列。通常稱為「順利路徑」。
延伸情境／替代與例外流程： 記錄與主要流程的偏差。
- 替代流程： 達成相同目標的不同有效路徑（例如：使用不同的付款方式）。
- 例外流程： 中斷目標並需特殊處理的錯誤狀況、驗證失敗或系統限制。
後置條件： 用例成功完成後系統、資料或環境的保證狀態。

2. 標準規格模板

一致性對於可維護性至關重要。以下模板提供了一個廣泛採用的結構，確保完整性而不產生不必要的冗長：

欄位	描述
使用案例 ID 與名稱	一個唯一的識別碼和動詞-名詞標題（例如：`UC-201：提領現金`).
參與者（們）	列出所有主要與次要參與者。
描述	對使用案例目的與商業價值的簡明摘要。
前置條件	啟動前所需的系統或環境狀態。
觸發事件	啟動互動的精確事件。
主要成功情境	編號且依序的步驟，詳細說明預設的成功路徑。
延伸 / 異常情況	分支流程對應至特定主要情境步驟（例如：`3a`, `8b`).
後置條件	成功完成後的最終系統狀態。

3. 實例研究敘述：UC-201 提領現金

以下規格說明展示了該範本與基礎概念如何應用於真實的銀行場景。

使用案例 ID 與名稱： UC-201 - 提領現金
主要參與者：銀行客戶
次要參與者： 核心銀行系統 / ATM 網路
描述： 描述已驗證的銀行客戶如何使用自動櫃員機（ATM）從其支票帳戶或儲蓄帳戶中提取現金。
前置條件： ATM 保持活躍的網路連接，並擁有足夠的實體現金。
觸發條件： 客戶將銀行卡插入 ATM 卡片讀取器。

主要成功場景（基本流程）

系統讀取銀行卡並提示輸入個人識別密碼（PIN）。
客戶輸入其 PIN。
系統與核心銀行系統核對 PIN。
系統顯示可用的交易選項。
客戶選擇「提取現金」。
系統提示選擇帳戶類型（支票／儲蓄）及提款金額。
客戶選擇目標帳戶並輸入可用金額。
系統與核心銀行系統核對資金是否充足。
系統扣款並指令現金發放裝置釋放指定金額。
系統發放現金，彈出卡片，並列印交易憑證。
客戶收取現金、卡片與憑證。

擴展（替代與異常流程）

3a. 無效 PIN：
1. 系統通知客戶 PIN 錯誤，並要求重新輸入。
2. 客戶輸入新的 PIN。
3. 回到第 3 步繼續。
4. 異常： 若客戶連續三次輸入無效 PIN，系統將保留卡片並終止會話。
8a. 資金不足：
1. 系統顯示「資金不足」錯誤，並提示客戶輸入較低金額或取消。
2. 客戶選擇「取消」。
3. 系統退出卡片並終止會話。

後置條件

交易已安全記錄，帳戶餘額準確更新，實體ATM現金庫存相應減少，終端機重設為待機歡迎畫面。

4. 記述最佳實務

為確保使用案例描述保持可執行、可擴展且對開發人員友好，請遵循以下既定指南：

保持封裝盒觀點： 記錄什麼系統從使用者觀點所執行的動作，而非如何其內部如何實現。避免提及資料庫結構、API端點或UI像素位置。
使用主動語態與清晰語法： 使用直接的主詞-動詞結構以消除歧義。
- 避免： 「系統評估PIN。」
- 建議： 「系統驗證PIN。」
明確標示擴展關係： 始終將替代流程與例外流程直接連結至其分岔的步驟編號（例如， 5a 從第5步分岔）。這能確保可追溯性，並簡化測試案例的產生。
針對基本商業流程（EBP）： 每個使用案例應代表一個由單一參與者對應單一商業事件所執行的完整且具價值的任務。避免記錄細微的UI點擊或系統微互動。
區分前置條件與觸發條件： 前置條件是一種靜態狀態（例如：「使用者擁有活躍會話」），而觸發條件是一種動態動作（例如：「使用者點擊『提交訂單』」）。將二者區分清楚可避免邏輯重疊與範圍混淆。

5. 可視化系統互動

雖然文字敘述提供深度，但視覺模型能立即呈現結構清晰度。在規格說明中整合使用案例圖與序列圖，可確保利害關係人對系統邊界與時間執行有統一的理解。

A. 使用案例關係圖

此圖表描繪參與者互動，定義系統邊界，並說明可重複使用行為之間的包含關係。

PlantUML

在 VPasCode 中編輯 PlantUML

PlantUML Edit PlantUML in VPasCode

@startuml
skinparam theme plain
skinparam packageStyle rectangle

actor "銀行客戶" as customer
actor "核心銀行系統" as bank

rectangle "ATM 系統" {
    usecase "提款現金" as UC_Withdraw
    usecase "查詢餘額" as UC_Balance
    usecase "驗證使用者" as UC_Auth
    
    ' 包含關係
    UC_Withdraw ..> UC_Auth : <<include>>
    UC_Balance ..> UC_Auth : <<include>>
}

customer --> UC_Withdraw
customer --> UC_Balance
UC_Withdraw --> bank
UC_Balance --> bank
@enduml

Edit PlantUML in VPasCode

在 VPasCode 中編輯 PlantUML

B. 主成功場景的順序圖

此圖將主成功場景（提款現金用例）轉換為時間順序的時間軸，明確訊息傳遞流程、同步點以及系統間的交接。