使用案例文件範本(Use Case Document Template)

適用標準:ISO/IEC/IEEE 29148:2018、UML 2.5.1(Unified Modeling Language)
適用階段:需求分析階段(Requirements Phase)
負責角色:系統分析師(SA)、業務分析師(BA)


📑 章節目錄

  1. 文件資訊
  2. 系統範圍與參與者
  3. 使用案例圖(Use Case Diagram)
  4. 使用案例清單
  5. 使用案例規格(逐案詳述)
  6. 業務規則
  7. 非功能性需求對應
  8. 追溯矩陣

📝 範本


1. 文件資訊

項目內容
文件名稱[系統名稱] 使用案例文件
文件編號[專案代碼]-UCD-[版本號]
版本v[X.Y]
建立日期[YYYY-MM-DD]
最後更新[YYYY-MM-DD]
撰寫者[BA/SA 姓名]
審核者[技術主管 / 業務主管]

版本歷程

版本日期修改人修改內容
v1.0[YYYY-MM-DD][姓名]初版發布

2. 系統範圍與參與者

2.1 系統邊界

項目說明
系統名稱[系統全名]
系統目的[一句話描述系統核心價值]
系統範圍[包含/不包含的功能範疇]

2.2 參與者(Actors)清單

參與者 ID名稱類型說明相關角色/系統
ACT-001[名稱][人/系統/時間][簡述][實際角色]
ACT-002[名稱][人/系統/時間][簡述][實際角色]

3. 使用案例圖(Use Case Diagram)

graph LR
    subgraph "System Boundary: [系統名稱]"
        UC1([UC-001: 使用案例名稱])
        UC2([UC-002: 使用案例名稱])
        UC3([UC-003: 使用案例名稱])
    end

    Actor1[/Actor 1\] --> UC1
    Actor1 --> UC2
    Actor2[/Actor 2\] --> UC2
    Actor2 --> UC3
    UC2 -.->|include| UC1
    UC3 -.->|extend| UC2

4. 使用案例清單

UC ID使用案例名稱主要參與者優先級複雜度狀態
UC-001[名稱][Actor][High/Medium/Low][High/Medium/Low][Draft/Review/Approved]
UC-002[名稱][Actor][High/Medium/Low][High/Medium/Low][Draft/Review/Approved]

5. 使用案例規格(逐案詳述)

UC-[NNN]: [使用案例名稱]

項目內容
Use Case IDUC-[NNN]
名稱[使用案例名稱]
簡述[一句話描述目的]
主要參與者[Primary Actor]
次要參與者[Secondary Actors,若無填 N/A]
觸發條件[什麼事件啟動此使用案例]
前置條件[執行前必須滿足的條件]
後置條件(成功)[成功完成後系統/資料狀態]
後置條件(失敗)[失敗時系統/資料狀態]
優先級[High / Medium / Low]
頻率[每日 N 次 / 每週 N 次]

主要流程(Main Flow):

步驟參與者動作描述
1[Actor][動作]
2System[系統回應]
3[Actor][動作]
4System[系統回應]

替代流程(Alternative Flow):

替代流程 ID分支點條件步驟描述
AF-1Step [N][條件][替代步驟描述]
AF-2Step [N][條件][替代步驟描述]

例外流程(Exception Flow):

例外 ID分支點條件系統回應
EX-1Step [N][錯誤條件][錯誤處理描述]
EX-2Step [N][錯誤條件][錯誤處理描述]

業務規則:

規則 ID說明
BR-[NNN][業務規則描述]

UI 原型參考:

畫面描述連結
[畫面名稱][簡述][Figma/Wireframe URL]

6. 業務規則

規則 ID規則名稱描述適用 UC來源
BR-001[名稱][規則詳細描述]UC-001, UC-003[法規/政策]
BR-002[名稱][規則詳細描述]UC-002[業務部門]

7. 非功能性需求對應

UC ID效能要求安全要求可用性要求
UC-001[回應時間 < Ns][需認證/授權等級][可用性 %]
UC-002[TPS ≥ N][需加密][7×24]

8. 追溯矩陣

UC IDBRD 需求FRD 功能測試案例設計元件
UC-001BRD-§3.1FR-001TC-001~003[Module A]
UC-002BRD-§3.2FR-004TC-004~006[Module B]

📖 使用說明

各章節填寫指引

章節填寫時機負責人重點說明
§1 文件資訊文件建立時BA/SA確保版本追蹤
§2 系統範圍需求啟動會議後BA定義 In/Out Scope
§3 UC 圖需求分析中期SA使用 UML 標準畫法
§4 UC 清單持續更新BA/SA含優先排序
§5 UC 規格逐案分析時BA/SA每個 UC 完整填寫
§6 業務規則配合 UC 分析BA統一管理,避免重複
§7 NFR 對應設計轉換前SA與 NFR 文件交叉引用
§8 追溯矩陣設計/測試階段補充SA/QA確保需求可追溯

Use Case 撰寫原則

  1. 一個 UC = 一個完整的使用者目標(User Goal Level)
  2. 主要流程描述「快樂路徑」(Happy Path)
  3. 使用「主詞 + 動詞 + 受詞」格式撰寫步驟
  4. 替代流程處理分支選擇,例外流程處理錯誤
  5. 前/後置條件需可驗證

💡 範例(以 HRMS 人力資源管理系統為例)


範例:參與者清單

參與者 ID名稱類型說明相關角色
ACT-001員工一般員工使用系統全體正職員工
ACT-002直屬主管審核部屬的請假/加班部門主管、組長
ACT-003HR 人員管理人事資料與考勤人資部同仁
ACT-004系統管理員系統維護與設定IT 部門
ACT-005薪資系統系統外部薪資計算系統SAP HR Module
ACT-006排程器時間定時觸發任務CRON/Scheduler

範例:使用案例圖

graph LR
    subgraph "System Boundary: HRMS 請假模組"
        UC1([UC-001: 申請請假])
        UC2([UC-002: 審核請假])
        UC3([UC-003: 查詢假別餘額])
        UC4([UC-004: 取消請假])
        UC5([UC-005: 產生月考勤報表])
    end

    EMP[/員工\] --> UC1
    EMP --> UC3
    EMP --> UC4
    MGR[/直屬主管\] --> UC2
    MGR --> UC3
    HR[/HR 人員\] --> UC5
    SCHED[/排程器\] --> UC5
    UC1 -.->|include| UC3
    UC4 -.->|extend| UC1

範例:UC-001 申請請假

項目內容
Use Case IDUC-001
名稱申請請假
簡述員工透過系統提交請假申請,經主管審核後生效
主要參與者員工(ACT-001)
次要參與者直屬主管(ACT-002)、HR 系統
觸發條件員工點選「申請請假」功能
前置條件1. 員工已登入系統 2. 員工為在職狀態
後置條件(成功)假單建立,狀態為「待審核」,主管收到通知
後置條件(失敗)假單未建立,顯示失敗原因
優先級High
頻率每日約 50~100 次

主要流程(Main Flow):

步驟參與者動作描述
1員工進入請假申請頁面
2System顯示假別清單與各假別剩餘天數
3員工選擇假別、輸入起迄日期、事由
4System計算請假天數(排除假日),驗證餘額是否足夠
5System顯示請假摘要(含代理人建議)
6員工指定職務代理人,確認送出
7System建立假單(狀態:PENDING),發送通知給直屬主管
8System顯示「申請成功,等待主管審核」訊息

替代流程(Alternative Flow):

替代流程 ID分支點條件步驟描述
AF-1Step 3請假 ≤ 0.5 天不需指定代理人,跳至 Step 7
AF-2Step 6員工選擇暫存假單儲存為 DRAFT,不發通知

例外流程(Exception Flow):

例外 ID分支點條件系統回應
EX-1Step 4假別餘額不足顯示「[假別]剩餘 N 天,不足」,阻止送出
EX-2Step 4起迄日期重疊已核准假單顯示「日期與已核准假單衝突」
EX-3Step 7找不到直屬主管通知 HR 人工指派審核人

業務規則:

規則 ID說明
BR-001特休假需提前 3 個工作天申請(緊急狀況除外)
BR-002病假超過 3 天需附診斷證明
BR-003請假天數計算排除國定假日與週末
BR-004同部門同日請假人數不得超過 30%

📌 審閱重點

  • 每個 Use Case 是否都對應到明確的使用者目標?
  • 前/後置條件是否可驗證、可測試?
  • 替代/例外流程是否涵蓋常見邊界情境?
  • 追溯矩陣是否完整連結需求→設計→測試?