6.7 使用案例描述與情境流程

6.7.1 使用案例描述的基本欄位

使用案例圖適合呈現參與者與系統服務的整體關係，但無法完整記錄觸發事件、條件、互動步驟及例外處理。因此，重要使用案例通常需要搭配使用案例描述（Use Case Description）。

欄位可依專案需要調整，但不應為了填滿模板而捏造資訊。

6.7.2 撰寫基本流程

基本流程（Basic Flow，BF）應交替描述參與者動作與系統回應，並保持在需求層級。例如，Case M01（專題競賽報名與審查系統）的UC-01可以建立下列基本流程：

UC-01-BF-01 提交競賽報名的基本流程

流程步驟應避免過度指定畫面、按鈕位置、資料庫或程式元件。除非介面需求已正式確認，否則「系統要求隊長提供資料」通常比「隊長點選右上角藍色按鈕」更適合需求分析。具體介面與實作方式應在系統設計階段依據已確認的需求進一步決定。

6.7.3 替代流程與例外流程

一個使用案例可以包含多個情境，每個情境代表從開始到結束的一條可能路徑。基本流程描述主要的成功情境，替代流程與例外流程則用來記錄其他條件下可能發生的互動。

替代流程（Alternative Flow，AF）描述不同但仍可能完成目標的路徑；例外流程（Exception Flow，EF）則描述因錯誤、限制或外部失敗而無法依基本流程完成的情況。

在單一使用案例描述中，可以使用BF-01、AF-01及EF-01等簡短編號。若同一份文件同時呈現多個使用案例，建議加上使用案例識別碼，例如UC-01-BF-01或UC-03-EF-01，以免不同使用案例的流程編號混淆。

每個流程應清楚記錄：

• 從基本流程的哪一步分出？
• 什麼條件觸發？
• 系統如何回應？
• 是否返回基本流程？
• 使用案例最後處於什麼狀態？

例如：

UC-01-EF-01 團隊人數不符

1. 在基本流程步驟4，系統發現團隊人數少於3人或多於5人。
2. 系統拒絕正式提交並說明未符合BR-01。
3. 使用案例結束，報名資料不轉為正式提交狀態。

UC-01-EF-02 超過報名期限

1. 在基本流程步驟4，系統判定目前時間已超過報名期限。
2. 系統拒絕提交並說明未符合BR-09。
3. 使用案例結束，報名資料不轉為正式提交狀態。

6.7.4 前置條件、後置條件與業務規則

前置條件不是流程第一步，而是使用案例開始前已成立的條件。例如，「隊長已通過身分驗證」可以是前置條件；身分驗證若由本使用案例完成，就應寫入流程而非前置條件。

後置條件記錄結束後的可確認狀態，並可區分：

• 成功後置條件：報名資料已正式提交並保存提交時間。
• 最低保證：提交失敗時，不建立不完整的正式報名紀錄。

業務規則應以識別碼引用，不必在每個流程中重複抄寫全文。例如，UC-04分派評審可引用BR-05，以表明評審不得審查本人所指導之學生團隊。

6.7.5 使用案例描述範例

UC-03-BF-01 上傳專題文件的基本流程

1. 隊長提出上傳專題文件的要求。
2. 系統執行UC-09「驗證使用者身分」。
3. 系統要求隊長提供文件。
4. 隊長提供PDF格式的專題文件。
5. 系統檢查格式與檔案容量。
6. 系統保存文件及上傳紀錄。
7. 系統回覆上傳成功。

UC-03-EF-01 格式不符

1. 系統發現文件不是PDF格式。
2. 系統拒絕上傳，並說明可接受的檔案格式。
3. 使用案例結束，系統不保存不符合格式的文件。

UC-03-EF-02 容量超過限制

1. 系統發現文件超過20 MB。
2. 系統拒絕上傳，並說明容量限制。
3. 使用案例結束，系統不保存超過容量限制的文件。

完成使用案例描述後，應檢查流程是否涵蓋驗收準則、是否與圖及需求一致、是否遺漏重要例外，以及每項規則是否具有正式依據。