Posted inUML

使用案例詳述的全面指南：關鍵概念、方法與範例

引言

使用案例詳述是軟體開發生命週期中的一個關鍵階段，特別是在需求工程與物件導向分析與設計的脈絡下。它彌補了高階使用案例與詳細系統規格之間的差距，使開發人員、分析師與利害關係人能夠理解 如何系統如何回應特定的使用者目標。

本指南提供對 使用案例詳述的全面概述，包括其目的、關鍵概念、逐步方法、最佳實務與實際範例。

1. 什麼是使用案例詳述？

使用案例詳述是將高階使用案例精煉為詳細且可執行的系統行為描述的過程。它將使用者互動的簡單敘述轉化為精確、可測試且可實現的規格。

✅ 目標：定義 什麼系統應該做什麼， 如何應該如何執行，以及 在何種條件下詳細程度足以支援開發與測試。

2. 為何使用案例詳述至關重要

  • 減少模糊性：防止對需求的誤解。

  • 提升可追蹤性：將需求與設計、程式碼及測試案例連結。

  • 支援設計與實作：為類別圖、序列圖與資料庫設計提供基礎。

  • 支援測試：促進測試情境與接受標準的建立。

  • 增強協作：確保利益相關者、開發人員和測試人員之間的共同理解。

3. 用例細化中的關鍵概念

3.1 用例（UC）

用例描述系統為利益相關者（使用者或外部系統）產生價值結果而執行的一系列動作。

範例：「提款」從自動櫃員機。

3.2 利益相關者

與系統互動的外部實體。可以是人類使用者、另一個系統，或時間觸發。

範例：客戶、自動櫃員機、支付網關。

3.3 主要與次要利益相關者

  • 主要利益相關者：啟動用例。

  • 次要利益相關者：支援主要利益相關者（例如銀行伺服器）。

3.4 前提條件

用例開始前必須成立的條件。

範例：使用者必須擁有有效的卡片和正確的PIN。

3.5 後置條件

用例完成後必須成立的條件。

範例：現金已發放，帳戶餘額已更新。

3.6 主要成功情境（基本流程）

導致成功的最常見用例路徑。

範例：插入卡片 → 輸入PIN → 選擇提款 → 輸入金額 → 領取現金。

3.7 替代流程（例外流程）

用例中處理例外、錯誤或變化的分支。

範例：無效PIN → 重新嘗試或取消。

3.8 擴展

主流程中可插入替代行為的點（例如，透過UML中的「<>」）。

範例：「<>：通知銀行可疑活動。」

3.9 非功能需求（NFRs）

對系統行為的限制（例如：效能、安全性、易用性）。

範例：「交易必須在3秒內完成。」

4. 使用案例詳述流程（逐步說明）

步驟 1：識別使用案例

從高階使用案例開始（例如：「下訂單」）。

使用範本：
使用案例名稱：下訂單
主要參與者：顧客
利害關係人：顧客、訂單管理系統、付款網關

步驟 2：定義前置條件

列出使用案例開始前必須滿足的所有條件。

  • 顧客已登入。

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

  • 付款方式已儲存。

步驟 3：定義後置條件

說明使用案例完成後必須為真的內容。

  • 系統中已建立訂單。

  • 庫存已更新。

  • 付款已處理。

  • 已發送確認郵件。

步驟 4：撰寫主要成功情境（基本流程）

詳細說明理想的、成功的流程。

  1. 顧客從購物車中選擇「結帳」。

  2. 系統顯示訂單摘要。

  3. 顧客確認寄送地址。

  4. 客戶選擇付款方式。

  5. 系統處理付款。

  6. 付款已確認。

  7. 系統建立訂單並生成確認資訊。

  8. 顯示確認資訊並發送電子郵件。

步驟 5：識別替代流程（例外流程）

列出可能偏離主流程的情況。

替代流程 A：庫存不足

  1. 系統檢查庫存。

  2. 商品缺貨。

  3. 系統顯示訊息：「商品無法取得。」

  4. 客戶可移除該商品或選擇不包含該商品繼續。

替代流程 B：付款被拒絕

  1. 付款被拒絕。

  2. 系統顯示錯誤：「付款被拒絕。」

  3. 客戶可重試或選擇其他付款方式。

替代流程 C：無效的送貨地址

  1. 系統驗證地址。

  2. 地址無效。

  3. 系統提示客戶進行修正。

步驟 6：定義擴展（<> 關係）

使用 UML 風格的擴展來顯示選擇性行為。

  • <>: 通知庫存系統

    • 觸發條件：結帳期間商品缺貨時。

    • 目的：通知倉庫補貨。

  • <>: 套用折扣優惠券

    • 觸發條件：客戶輸入有效的優惠券代碼。

    • 目的：降低總金額。

步驟 7：新增非功能需求（NFRs）

包含系統限制。

  • 訂單必須在5秒內處理完畢。

  • 付款必須使用 TLS 1.3 進行加密。

  • 系統必須支援 10,000 名同時使用者。

步驟 8：審查與驗證

與利害關係人合作，以確保完整性和準確性。

  • 提問：「這是否涵蓋所有使用者目標？」

  • 提問：「所有邊界情況是否都已考慮？」

  • 提問：「開發人員能否根據此內容進行開發？」

5. 詳細說明的工具與技術

工具／技術 目的
用例圖（UML） 呈現參與者與用例。
順序圖 顯示用例期間物件之間的訊息傳遞流程。
活動圖 模擬複雜的工作流程與決策點。
使用者故事地圖 將用例與使用者旅程及優先順序連結。
決策表 釐清複雜邏輯（例如：折扣規則）。

6. 最佳實務

  1. 保持用例以使用者為中心：專注於使用者目標，而非系統功能。

  2. 使用一致的命名：使用動詞-名詞格式（例如：「更新個人資料」）。

  3. 避免技術術語：撰寫給非技術性利害關係人。

  4. 使用簡單明瞭的語言：表達清晰且簡潔。

  5. 迭代：隨著理解的加深，逐步完善使用案例。

  6. 連結至其他實體：將使用案例與類別圖、測試案例及使用者故事連結。

  7. 優先排序：首先關注高價值或高風險的使用案例。

7. 實際案例：線上銀行 – 轉帳

使用案例：轉帳

主要參與者：客戶
次要參與者：銀行伺服器、詐欺偵測系統

前置條件

  • 客戶已登入。

  • 來源帳戶有足夠資金。

  • 未超過轉帳金額上限。

後置條件

  • 資金已從來源帳戶轉至目標帳戶。

  • 交易已記錄於雙方帳戶中。

  • 已向雙方發送通知。

主要成功情境

  1. 客戶從儀表板選擇「轉帳」。

  2. 系統顯示轉帳表單。

  3. 客戶輸入目標帳戶與金額。

  4. 系統驗證帳戶與金額。

  5. 客戶確認轉帳。

  6. 系統檢查詐欺偵測規則。

  7. 交易已核准並執行。

  8. 顯示確認訊息。

替代流程

  • A1：資金不足
    → 系統顯示：「資金不足。」
    → 客戶可取消或調整金額。

  • A2：偵測到詐欺
    → 系統阻止轉帳並發送警示。
    → 客戶必須透過雙重身份驗證確認或聯繫支援。

  • A3：無效的收款帳戶
    → 系統顯示：「帳戶未找到。」
    → 客戶可重新輸入或使用帳戶查詢功能。

擴展功能

  • <>：向收款人發送通知

    • 觸發條件：轉帳完成。

    • 目的：通知收款人。

  • <>：收取轉帳手續費

    • 觸發條件：轉帳金額大於1,000美元。

    • 目的：扣除5美元手續費。

非功能需求

  • 所有轉帳必須記錄並可審計。

  • 回應時間 ≤ 2秒。

  • 資料在傳輸中及靜止狀態下均需加密。

8. 常見陷阱與避免方法

陷阱 解決方案
過於模糊（例如：「系統應處理訂單」） 使用具體且可衡量的動作。
過於技術性的語言 使用自然語言；避免使用程式碼或資料庫術語。
遺漏例外路徑 使用替代流程來涵蓋失敗情況。
沒有明確的成功標準 明確定義後置條件。
未進行利益相關者審查 讓使用者、測試人員和業務分析師參與。

9. 結論

用例細化不僅僅是文檔編寫的過程——它是一項戰略性流程，確保系統能以清晰、精確和完整的方式滿足真實用戶的需求。透過系統性地將高階用例擴展為詳細且可執行的規格，團隊能降低風險、改善溝通，並為成功的軟體交付奠定穩固基礎。

✅ 最後提示：將用例細化視為一種迭代式對話——而非一次性任務。隨著你對系統及其使用者了解得越多，持續優化它。

附錄：用例細化範本

# 用例名稱：[例如：更新個人資料]

**主要參與者**：[例如：客戶]  
**次要參與者**：[例如：資料庫、電子郵件服務]  
**利益相關者**：[例如：客戶、支援團隊]

### 前置條件
- [列出條件]

### 後置條件
- [列出結果]

### 主成功場景（基本流程）
1. [步驟 1]  
2. [步驟 2]  
...

### 替代流程
- **A1：[名稱]**  
  1. [步驟]  
  2. [步驟]  
- **A2：[名稱]**  
  ...

### 擴展（<<extend>>）
- **<<extend>>：[名稱]**  
  - 觸發條件：[何時]
  - 目的：[為何]

### 非功能需求
- [效能、安全性、易用性等]

### 備註
- [額外背景或假設]

遵循此指南，團隊可以掌握用例細化的藝術，並建立不僅具備功能，更真正符合使用者期望的系統。

附錄 – ATM 提款用例描述：

用例名稱

提款

主要參與者

客戶（銀行帳戶持有人）

次要參與者

  • ATM 機器

  • 銀行伺服器（核心銀行系統）

  • 支付網關（用於交易處理）

  • 詐欺偵測系統

  • 印表機（用於列印收據）

利益相關者與利益

  • 客戶：希望安全且高效地提款。

  • 銀行：確保交易完整性、防範詐欺，並確保帳戶更新準確。

  • ATM 運營商：維持機器可用性與現金庫存。

  • 安全團隊：監控可疑行為並防止詐騙。

前置條件

  1. 客戶已將有效的銀行卡插入自動櫃員機。

  2. 客戶已成功驗證身分（輸入正確的PIN）。

  3. 客戶的帳戶處於活躍狀態且未被鎖定。

  4. 自動櫃員機的保險箱內有足夠的現金。

  5. 客戶帳戶有足夠的可用餘額。

  6. 每日提款金額尚未超過限制。

後置條件

  1. 向客戶發放所要求的現金金額。

  2. 客戶帳戶餘額減少所提款金額。

  3. 銀行系統中建立交易紀錄。

  4. 列印收據（若客戶要求）。

  5. 自動櫃員機記錄交易以供審計與對帳。

主要成功情境（基本流程）

步驟 系統動作 參與者回應
1 自動櫃員機提示：「請輸入您的PIN。」 客戶輸入PIN。
2 自動櫃員機與銀行伺服器驗證PIN。 系統確認PIN正確。
3 自動櫃員機顯示主選單：「提款、查詢餘額、轉帳、退出。」 客戶選擇「提款」。
4 自動櫃員機提示：「請輸入提款金額。」 客戶輸入金額（例如：100美元）。
5 自動櫃員機驗證：

  • 金額在每日限額內。

  • 帳戶有足夠資金。

  • 自動櫃員機有足夠現金。｜系統確認有效性。｜
    | 6 | 自動櫃員機向銀行伺服器請求授權。 | 銀行伺服器批准交易。 |
    | 7 | 自動櫃員機從金庫發放現金。 | 客戶收到現金。 |
    | 8 | 自動櫃員機提示：「您需要收據嗎？」 | 客戶選擇「是」或「否」。 |
    | 9 | 若選擇「是」：自動櫃員機列印收據，內容包括：

  • 日期/時間

  • 提款金額

  • 餘額

  • 交易編號｜客戶領取收據。｜
    | 10 | 自動櫃員機顯示：「感謝使用。請取出您的卡片。」 | 客戶取出卡片。 |
    | 11 | 自動櫃員機返回待機狀態。｜系統重置。｜

✅ 成功結果：客戶收到現金（並可選擇性獲得收據）。帳戶已更新。

替代流程（異常情境）

A1：輸入錯誤的PIN（共三次）

  • 觸發條件：客戶連續三次輸入錯誤的PIN。

  • 系統動作：自動櫃員機鎖住卡片並顯示：「卡片已鎖。請聯絡您的銀行。」

  • 使用者動作：客戶離開並聯絡銀行。

  • 後置條件：卡片暫時被鎖定；交易已被記錄。

⚠️ 注意：這是為了防止未經授權訪問而採取的安全措施。

A2：資金不足

  • 觸發條件：客戶輸入的金額超過可用餘額。

  • 系統動作：ATM顯示：「資金不足。當前餘額：$X。」

  • 使用者動作：客戶選擇「取消」或輸入較低金額。

  • 後置條件：未發放現金；帳戶無變動。

A3：ATM現金不足

  • 觸發條件：客戶輸入有效金額，但ATM錢箱為空或低於最低限度。

  • 系統動作：ATM顯示：「現金不可用。請稍後再試。」

  • 使用者動作：客戶取消或稍後返回。

  • 後置條件：交易未處理；帳戶無變動。

A4：提款金額超出每日上限

  • 觸發條件：客戶嘗試提取超過每日上限的金額（例如：$1,000）。

  • 系統動作：ATM顯示：「超出每日提款上限。請嘗試較小金額。」

  • 使用者動作：客戶減少金額或取消。

  • 後置條件：交易未處理。

A5：交易被銀行伺服器拒絕

  • 觸發條件: 銀行伺服器拒絕交易（例如，由於欺詐警報、帳戶凍結）。

  • 系統動作: ATM 顯示：「交易被拒絕。請聯絡您的銀行。」

  • 參與者動作: 客戶取消並聯絡銀行。

  • 後置條件: 未發放現金；帳戶無變更。

擴展（<> 關係）

擴展 觸發條件 目的
<>: 通知欺詐檢測系統 當在境外提款或超出正常行為時 標記可疑活動以供審查
<>: 向客戶發送簡訊警報 成功提款後 通知客戶交易資訊（增強安全性）
<>: 計收提款手續費 針對非主要帳戶持有者或特定帳戶類型 針對特定服務收取費用
<>: 列印交易紀錄 若客戶於選單中選擇「列印紀錄」 提供近期交易的列印摘要

非功能需求（NFRs）

類別 需求
效能 交易必須在 3 秒內處理完畢。
安全性 所有通訊均加密（TLS 1.3）。PIN 永遠不會以明文儲存或傳輸。
可靠性 ATM在銀行伺服器確認授權前不得發放現金。
易用性 介面必須可存取（例如：大型按鈕、為視障人士提供語音引導）。
可用性 ATM必須有99.9%的時間處於運作狀態。
審計與合規 所有交易必須記錄並可追溯七年（根據銀行法規）。

注意事項

  • ATM必須定期維護，以確保現金供應與硬體可靠性。

  • 若交易完成後30秒內未取出卡片，系統將自動保留卡片（防盜功能）。

  • 系統支援多種貨幣及匯率計算（如適用）。

使用案例圖（UML 總結）

[客戶] --(提款)--> [ATM]
[ATM] --(驗證PIN)--> [銀行伺服器]
[ATM] --(檢查資金)--> [銀行伺服器]
[ATM] --(發放現金)--> [現金庫]
[ATM] --(列印收據)--> [印表機]
[ATM] --(通知防詐系統)--> [防詐偵測系統]

（注意：在完整的UML圖中，使用案例關係如<>和<>將會顯示。）

✅ 總結

這詳細的使用案例針對「提款」所提供的詳細使用案例，提供了一個清晰、結構化且可測試的規格，內容包括：

  • 捕捉使用者目標與系統行為。

  • 處理現實世界中的異常情況。

  • 支援安全性、合規性與易用性。

  • 作為設計、測試與實作的基礎。

適用於敏捷開發週期、系統設計文件或正式需求規格書。

📘 下一步:

  • 將此轉換為順序圖 用於顯示物件互動。

  • 建立測試案例 根據每個流程（主要與替代）進行。

  • 連結至類別圖 （例如，帳戶, 交易, 自動櫃員機, 詐欺偵測器).