初學者敏捷產品經理使用用例圖的完整手冊

理解使用者如何與您的產品互動，是成功開發的基礎。對於敏捷產品經理而言，在撰寫任何程式碼之前，清楚地視覺化這些互動至關重要。本指南涵蓋了您需要了解的有關用例圖的所有內容。我們將探討核心組件、關係，以及如何在不增加額外負擔的情況下，將此技術整合到您的敏捷工作流程中。

無論您是在優化待辦事項清單，還是釐清一次迭代的需求，一個結構良好的圖表都能彌補商業目標與技術執行之間的差距。本手冊旨在幫助您在團隊中建立清晰度與共識。

🎯 什麼是用例圖？

用例圖是使用者（參與者）與系統之間互動的視覺化表示。它著重於系統所提供的功能，而非內部邏輯或實作細節。在敏捷環境中，這些圖表可作為使用者需求的高階地圖。

與詳細的流程圖不同，用例圖不會顯示步驟的順序。相反地，它回答了這樣的問題：「系統能做什麼？」——從使用者的角度出發。

主要特徵包括：

• 著重於功能： 它強調功能與動作。
• 以參與者為中心： 它聚焦於執行動作的主體。
• 系統邊界： 它明確界定系統內部與外部的範圍。
• 高階視圖： 它避免使用技術術語和實作細節。

🧩 用例圖的核心組件

要創建有效的圖表，您必須理解標準符號及其含義。無論您使用何種工具繪製，這些元素都保持一致。

1. 參與者 👤

參與者代表使用者或與主系統互動的外部系統所扮演的角色。參與者通常以簡筆人像表示。

• 主要參與者： 這些是互動的啟動者。例如，「顧客」開始購買。
• 次要參與者： 這些支援主要參與者或系統。例如，「付款網關」驗證交易。
• 內部參與者： 有時，一個子系統會作為另一個子系統的參與者。

2. 用例 ⚙️

用例代表系統執行的特定目標或功能。這些通常以系統邊界內的橢圓形繪製。

• 範例： 「下訂單」或「登入」。
• 描述性名稱： 始終使用動詞-名詞短語（例如「管理庫存」而非「庫存」）。

3. 系統邊界 📦

系統邊界是一個包圍所有使用案例的矩形。此框內的所有內容均屬於系統的一部分，框外的所有內容均為外部。

• 清晰性： 這可避免對系統負責範圍產生混淆。
• 範圍界定： 它有助於利益相關者理解當前發行版本的範圍。

4. 關係 🔗

線條將參與者連接到使用案例，並將使用案例連接到其他使用案例。這些線條定義了各元素之間的互動方式。

• 關聯： 一條實線，將參與者連接到使用案例。
• 包含： 另一個使用案例所必需的使用案例。
• 擴展： 在特定條件下增加可選行為的使用案例。
• 泛化： 一個參與者或使用案例是另一個的專化版本的關係。

🛠️ 如何建立使用案例圖：逐步指南

建立圖表需要協作以及對問題領域的清晰理解。遵循此流程可確保準確性與團隊一致。

步驟 1：識別參與者 🕵️

首先列出所有與系統互動的人。提出以下問題：

• 誰直接使用系統？
• 誰間接受到系統的影響？
• 是否有外部系統參與（例如電子郵件伺服器、付款處理器）？

將這些內容寫在白板或便利貼上。將類似角色歸為一組。

步驟 2：定義目標 🎯

針對每位參與者，詢問他們希望達成什麼目標。這些目標將轉化為使用案例。

• 參與者： 客戶
• 目標： 購買產品
• 使用案例：下訂單

步驟 3：繪製系統邊界 📐

繪製一個大矩形，並以系統或應用程式的名稱標示。將所有已識別的使用案例放置在此矩形內。

步驟 4：將參與者連接到使用案例 🔌

從參與者繪製實線連接到他們互動的使用案例。確保每條線都代表直接互動。

步驟 5：新增關係（包含/延伸） 🔗

根據需要，透過增加複雜性來優化圖表。

• 包含：當一個使用案例總是需要另一個時使用。例如，“結帳”總是包含“登入”。
• 延伸：用於選擇性行為。例如，“套用折扣”僅在輸入代碼時才延伸“下訂單”。

📊 使用案例 vs. 使用者故事 vs. 活動圖

敏捷團隊經常混淆這三種工具。理解它們的差異有助於你為正確的工作選擇合適的工具。

工具	重點	最適合用途	細節層級
使用案例圖	系統功能	高階需求與範圍	中等（概觀）
使用者故事	使用者價值	待辦事項與衝刺規劃	高（具體標準）
活動圖	流程流	複雜邏輯與決策路徑	非常高（逐步進行）

用例圖： 在探索階段使用此圖來定義系統的功能。對於新成員的入職培訓非常有幫助。

使用者故事： 在迭代規劃期間使用此方式來定義具體要完成的工作。格式為：「作為[角色]，我希望[功能]，以便[利益]。」

活動圖： 當邏輯較為複雜時使用。若流程包含許多決策點、迴圈或平行路徑，使用顯示流程的圖表會比簡單的用例更為適合。

🔗 詳細理解關係

關係為您的圖表增添了深度。它們能清楚說明功能之間的依賴關係。

包含關係（<>)

此關係表示一個用例必須包含另一個用例。這是強制性的。

• 情境： 一位使用者想要「預訂航班」。
• 限制條件： 他們無法在未「選擇座位」的情況下執行此操作。
• 圖示： 「預訂航班」<> 「選擇座位」。

這有助於開發人員了解某些步驟是較大流程中不可妥協的部分。

延伸關係（<>)

此關係表示僅在特定條件下才會發生的選擇性行為。

• 情境： 一位使用者想要「檢視帳戶」。
• 條件： 若帳戶被鎖定，系統必須「顯示鎖定警告」。
• 圖示： 「檢視帳戶」<> 「顯示鎖定警告」。

適度使用延伸關係。過度使用會使圖表變得混亂。

一般化（繼承）

當一個參與者或用例是另一個的特殊版本時使用。

• 參與者：「管理員」和「使用者」都可能繼承自「人員」。
• 用例：「透過信用卡付款」可能繼承自「付款」。

透過顯示共用行為，可減少圖表中的重複內容。

🔄 將用例整合至敏捷工作流程

敏捷強調迭代與反饋。靜態圖表很容易迅速過時。以下是保持其相關性的方法。

1. 待辦事項精煉 🧹

在精煉會議期間，使用圖表確保不會遺漏任何功能。若提出新功能，應檢查其是否符合現有系統邊界。若不符合，可能需要建立全新的系統。

2. 迴圈規劃 🗓️

在為迴圈選擇故事時，參考圖表以了解故事之間的關聯。若某個故事依賴特定用例，請確保參與者與互動關係明確。

3. 完成定義 ✅

使用圖表來驗證完整性。若圖表中的某個用例在迴圈中未被處理，則不應標記為完成。

4. 利益相關者溝通 🗣️

用例非常適合與非技術型利益相關者溝通。它們能以視覺化方式總結產品功能，而不會讓對方被技術細節淹沒。

⚠️ 應避免的常見錯誤

即使經驗豐富的產品經理在製作這些圖表時也會犯錯。請留意這些陷阱。

• 細節過多：不要畫出每一筆點擊。保持高階層次。若需展示點擊行為，請使用其他圖表。
• 內部邏輯：不要包含資料庫查詢或 API 呼叫。這些屬於實作細節，而非使用者功能。
• 混淆參與者：不要使用特定人物（例如「John」）作為參與者。應使用角色（例如「顧客」）。
• 遺漏邊界：務必明確定義系統邊界。此處的模糊會導致範圍蔓延。
• 忽略延伸關係：若存在許多錯誤狀態或可選功能，建議使用延伸關係，而非使主流程混亂。

📝 範例：電子商務平台

讓我們來看一個實際範例，以鞏固這些概念。想像一個線上商店。

參與者

• 訪客： 不登入即可瀏覽。
• 註冊使用者： 擁有一個帳戶。
• 管理員： 管理商店。

使用案例

• 瀏覽目錄
• 搜尋產品
• 加入購物車
• 結帳
• 管理庫存

關係

• 訪客 和 註冊使用者 都可以 瀏覽目錄.
• 結帳 包含 輸入運送資訊.
• 結帳 延伸為 套用優惠碼（可選）。
• 管理員僅與…互動管理庫存.

🛡️ 維護的最佳實務

軟體會演進，你的圖表也必須跟著演進。如果圖表與現實不符，靜態圖表就會變成負擔。

• 定期檢視：將圖表視為活文件。在迭代檢視時更新它。
• 版本控制：追蹤變更內容。如果系統有重大變更，請為圖表建立版本。
• 協作：不要獨自繪製。請讓開發人員與測試人員參與，以確保技術可行性。
• 簡潔為先：如果圖表過於複雜而難以閱讀，請將其拆分為多個視圖（例如按模組或參與者）。

🔍 何時應跳過用例圖

雖然強大，但這些圖表並非總是最佳選擇。要知道何時該跳過它們。

• 簡單專案：如果系統僅有三個功能，清單可能就足夠了。
• 複雜邏輯：如果流程涉及複雜的狀態機，狀態圖或活動圖會更合適。
• 快速原型設計：如果你正在極速推進並需要驗證一個假設，白板草圖比正式圖表更佳。

📈 衡量成功

你如何知道你的用例圖是否有效？

• 更清晰的需求： 在迭代期間，開發團隊提出較少問題。
• 減少返工： 用於修正不符合預期流程功能的時間減少。
• 更好的共識： 利益相關者能理解產品願景，而無需技術說明。

🚀 前進中

將用例圖融入你的敏捷實踐需要時間。從小處著手。選擇一個功能並進行規劃。與團隊分享。收集反饋。對圖表本身進行迭代。

請記住，目標不是完美無缺。目標是溝通。一個能清晰闡述複雜概念的簡單圖表，遠比一個完美卻無人理解的圖表更有價值。

透過掌握參與者、用例和關係的基礎知識，你將為產品建立更堅實的基礎。這個基礎能支援你的待辦事項清單，引導你的迭代開發，並確保團隊在打造正確的東西。

讓你的圖表保持可見。持續更新。並始終聚焦於使用者。