一個用例圖是需求工程中的基本建模工具需求工程用於視覺化參與者(使用者或外部系統)與系統系統(或其功能)。它幫助利益相關者從功能角度理解系統必須執行的任務,並作為技術團隊與業務用戶之間的溝通橋樑。
儘管其結構簡單,用例圖卻經常被誤用,原因在於參與者辨識不清、用例模糊或關係錯誤。本指南旨在釐清關鍵概念,提供逐步方法,並指出常見陷阱以避免。
| 概念 | 說明 |
|---|---|
| 參與者 | 與系統互動的人類使用者、組織或外部系統。在系統環境中扮演「使用者」的角色。範例:學生、教師、管理員、支付網關。 |
| 用例 | 系統為參與者執行的特定目標或功能的描述。定義系統什麼系統會做,而非如何。範例:「註冊課程」、「提交成績」、「產生報表」。 |
| 系統邊界 | 區分系統與外部參與者及系統的界線。界線內的所有內容都屬於系統的一部分。 |
| 關聯 | 連接參與者與使用案例的一條線,表示該參與者可以執行該使用案例。 |
| 泛化 | 一種關係,其中一個參與者從另一個參與者繼承行為(例如:「學生」是一種「使用者」)。 |
| 依賴 | 一種表示一個使用案例依賴於另一個使用案例的關係(e |
| 例如:「產生報表」依賴於「取得學生資料」)。 | |
| 包含 | 一個使用案例,其必要執行另一個使用案例所必需(例如:「提交成績」包含「驗證學生身分證號」)。 |
| 擴展 | 一個使用案例,其條件性地增加功能(例如:當成績低於門檻時,「發送通知」擴展「提交成績」)。 |
⚠️ 重要注意事項:使用案例並非關於功能——它們是關於功能目標以滿足使用者需求。
請問自己以下核心問題,以識別所有相關參與者:
| 問題 | 為什麼重要 |
|---|---|
| 誰使用主要的使用案例? | 識別主要使用者(例如:學生、教授)。 |
| 誰需要日常工作的支援? | 找出支援角色(例如:人力資源人員、IT支援)。 |
| 誰負責系統管理? | 識別管理員角色(例如:系統管理員、資料庫管理員)。 |
| 系統與哪些外部裝置/軟體系統互動? | 識別外部系統(例如:電子郵件、付款網關、ERP)。 |
| 誰對系統的成果感興趣? | 識別利益相關者(例如:家長、董事會成員)。 |
📌 提示:從 最重要的使用者 開始,並逐步向外擴展。使用現實情境或訪談來驗證角色的識別。
💡 範例:在一個 大學學生管理系統中,角色可能包括:
學生
教職員
學術導師
行政人員
付款網關
ERP 系統
一旦識別出角色後,針對每個角色提出以下問題:
| 問題 | 目的 |
|---|---|
| 角色必須執行的主要任務是什麼? | 識別功能目標(例如:註冊、報名、查看成績)。 |
| 該參與者是否希望查詢或修改系統中的資料? | 表示讀取/寫入操作(例如:檢視記錄、編輯個人檔案)。 |
| 該參與者是否希望通知系統其他系統的變更? | 建議以事件驅動的方式觸發(例如:當新增課程時通知系統)。 |
| 該參與者是否應被告知意外事件? | 表示通知的使用情境(例如:「警告:課程人數過多已檢測」)。 |
📌 使用簡潔、目標導向的語言。避免使用技術術語。
✅ 優良使用情境:「註冊課程」
❌ 不良使用情境:「提交帶驗證的註冊表單」→ 變得太技術性。
使用情境可以在不同層級進行建模:
| 層級 | 描述 |
|---|---|
| 頂層使用情境 | 反映業務目標的廣泛功能目標(例如:「管理學生資料」)。 |
| 精煉後的使用情境 | 由頂層目標衍生出的詳細動作。 |
🔁 迭代式開發方法:
從高階業務目標開始。
將其分解為次級目標。
持續精煉每個使用情境,直到具體且可執行為止。
📌 範例分解:
頂層:「支援學生行政管理」
精煉:
學生可以註冊
學生可以選課
系統儲存成績
系統發送註冊確認
這確保系統符合業務目標同時保持實用且可測試.
現在,將參與者和用例放置在圖上,並正確地將它們連接起來。
[參與者] --> [用例]
↑
[包含] [延伸]
↓
[依賴]
將參與者放置在系統邊界外(通常在左側、右側或上方)。
將用例放置在系統邊界內(中央或下方)。
使用實線表示關聯。
使用虛線表示依賴。
使用包含箭頭(→)表示包含關係。
使用延伸箭頭(→)表示延伸關係。
避免使用案例重疊;保持圖示清晰易讀。
📌 視覺範例(文字版):
+------------------+
| 學生 | --> 註冊課程
+------------------+
|
v
+------------------+
| 系統 | --> 儲存課程註冊資料
| (邊界) |
+------------------+
^
|
+------------------+
| 支付網關 | --> 處理費用支付
+------------------+
🚨 常見錯誤:將參與者繪製在系統邊界內——這會暗示參與者是系統的一部分,實際上並非如此。

此圖示由 Visual Paradigm AI 聊天機器人生成:

| 陷阱 | 為何錯誤 | 如何修正 |
|---|---|---|
| 🚫 過度複雜化參與者 | 創造太多參與者(例如「John Doe」、「Sarah Smith」),而非將角色歸類 | 將相似角色歸類(例如「學生」、「教職員」) |
| 🚫 使用模糊的使用案例 | 使用如「管理資料」、「做某事」等模糊語句 | 以具體且目標導向的語句取代(例如「提交課程註冊」) |
| 🚫 遺漏依賴關係 | 未顯示一個使用案例如何依賴另一個使用案例 | 新增包含或延伸在需要時建立關係 |
| 🚫 錯誤使用「延伸」 | 使用擴展用於一般工作流程 |
使用包含用於必要步驟;使用擴展僅用於可選或條件性的步驟 |
| 🚫 忽略外部系統 | 不包含支付網關、電子郵件等 | 識別所有外部系統並展示它們的互動 |
| 🚫 僅使用一個參與者 | 假設僅有一名使用者使用系統 | 識別所有利害關係人及其需求 |
| 🚫 使用技術術語 | 例如,“更新資料庫”、“呼叫 API” | 專注於功能行為——「提交請求」更佳 |
| 實踐 | 說明 |
|---|---|
| ✅ 從業務目標開始 | 自上而下建模——與戰略目標保持一致。 |
| ✅ 尽早讓利害關係人參與 | 訪談終端使用者或領域專家以驗證用例。 |
| ✅ 保持用例獨立 | 每個用例應代表一個單一且明確的目標。 |
| ✅ 使用現實世界的情境 | 以實際使用者活動為基礎(例如,學生註冊課程)。 |
| ✅ 與團隊驗證 | 與開發人員、測試人員和業務分析師一起審查圖表。 |
| ✅ 迭代更新 | 隨著需求的演變,以較小的週期逐步完善圖表。 |
| ✅ 詳細記錄使用案例 | 在另一份文件中包含前置條件、後置條件以及成功/失敗標準。 |
[30] 需求工程 – 使用案例建模的基礎性著作。
[27] 在軟體需求中識別使用案例 – 從參與者推導使用案例的實用方法。
[16, 40] – 全面的需求工程與系統設計文獻。
IEEE/ISO 標準:ISO/IEC 29148 – 使用案例規格指南。
推薦書籍:
軟體需求:第一次就做對 作者:Ian Sproul
統一軟體開發流程(RUP) – 介紹 UML 中的使用案例建模
會員
圖書館員
管理員
線上目錄系統
支付網關
會員:
借書
還書
搜尋書籍
查看會員狀態
圖書館員:
借出書籍
歸還書籍
更新書籍記錄
生成逾期清單
管理員:
新增書籍
管理使用者帳戶
生成年度報告
線上目錄系統:
搜尋書籍
通知會員新到書籍
付款網關:
處理罰款
處理續借費用
會員 → 借書 → 包含 → 還書
圖書館員 → 借出 → 延長 → 發送提醒(若逾期)
管理員 → 新增書籍 → 包含 → 更新目錄
此圖表清楚地顯示了誰做什麼、他們能做什麼,以及系統之間如何互動。
✅ 我是否已識別所有相關參與者?
✅ 使用案例是否具描述性且以目標為導向?
✅ 所有參與者是否都至少與一個使用案例相連?
✅ 依賴關係(包含/擴展)是否正確建模?
✅ 是否有遺漏的參與者或用例?
✅ 該圖表是否容易閱讀和理解?
✅ 我是否已與相關利益相關者審查過?
建立一個 用例圖 不僅僅是畫線和方框——它是一種 戰略性流程 需要 對使用者需求的深入理解, 語言表達的清晰性,以及 對細節的關注.
雖然圖表看似簡單, 參與者與用例的誤用 會導致不良的系統設計、遺漏需求以及使用者的挫敗感。透過遵循本指南中的步驟——透過現實世界中的問題識別參與者、從參與者需求推導用例,並避免常見陷阱——您就能建立準確、可執行且與利益相關者一致的用例圖。
✅ 請記住: 一個良好的用例圖講述一個故事 ——講述使用者如何與系統互動以達成目標的故事。