6.5 辨識與命名使用案例

6.5.1 從參與者目標辨識使用案例

使用案例（Use Case）描述參與者為達成特定目標而與系統進行的一組互動。系統分析師應從需求、業務事件及參與者目標中，辨識並逐步確認系統必須提供的使用案例，並為各使用案例建立清楚且一致的名稱，使讀者能理解參與者使用系統的目的。

為了建立使用案例，可以針對每個參與者逐一詢問：

• 為什麼需要使用系統？
• 希望完成哪些工作？
• 哪些事件會促使其使用系統？
• 完成後希望取得什麼結果？
• 哪些資料需要建立、查詢、修改、確認或提交？

例如，隊長的目標是提交競賽報名、修改報名資料及上傳專題文件；評審的目標是查看被分派的專題及提交評分；主辦單位的目標是確認競賽結果；競賽承辦人員的目標則是分派評審、處理評分更正及公告競賽結果。

需求、事件及業務流程也能協助發現使用案例：

6.5.2 使用案例的命名原則

使用案例通常採用「動詞＋業務名詞」命名，例如：

• 提交競賽報名
• 修改報名資料
• 上傳專題文件
• 分派評審
• 評定參賽專題
• 處理評分更正
• 確認競賽結果
• 公告競賽結果

這樣的「動詞＋業務名詞」命名方式很有規律，可以避免在命名時沒有抓到重點。使用案例名稱應符合下列原則：

1. 表達目標：名稱應說明參與者希望完成的事。
2. 使用業務語言：採用利害關係人熟悉且已確認的詞彙。
3. 保持一致：同一概念在不同文件與模型中應使用相同的正式名稱。
4. 避免實作用語：不以資料表、API、按鈕或程式模組命名。
5. 控制範圍：避免「管理系統」等過大的名稱，也要避免「點選送出」等過小的名稱。

為使用案例命名是必要的，使用案例的識別碼可用於追蹤與管理，但不能取代名稱。不要只用一個識別碼編號來標示使用案例。

確認使用案例清單時，應檢查每個名稱是否具備明確的參與者、目標、觸發事件及可觀察結果，並確認其不是畫面操作、內部演算法或尚未獲得需求支持的推測。以下是常見的不適當使用案例名稱：

6.5.3 判斷是否需要拆分或合併

使用案例所涵蓋的範圍可能過大或過小。範圍過大時可能需要拆分；範圍過小且不具獨立業務價值時，則可能需要納入其他使用案例。判斷是否拆分時，可以檢查：

• 使用案例是否包含多個可分別完成的參與者目標？
• 使用案例是否由不同參與者在不同時間完成？
• 使用案例是否具有各自獨立的觸發事件與結果？
• 使用案例是否需要分別授權、追蹤或驗收？

例如，「管理競賽」可能同時包含報名、評審分派、評分及結果公告。這些工作具有不同目標，可能在不同時間由不同參與者完成，也需要分別授權、追蹤與驗收，因此宜拆成多個使用案例。

判斷某個候選項目是否應納入其他使用案例時，可以檢查：

• 候選項目是否只是另一個目標中的操作步驟？
• 候選項目單獨完成時，是否沒有獨立的業務價值？
• 候選項目是否只有在支援另一個完整目標時才具有意義？

例如，「輸入專題名稱」「檢查必填欄位」及「顯示成功訊息」通常是競賽報名流程的一部分。這些項目本身沒有獨立的業務目標，通常應納入「提交競賽報名」的互動流程，而不應分別建立使用案例。

6.5.4 建立候選使用案例清單並逐項核對

以Case M01（專題競賽報名與審查系統）為例，可先建立下列候選清單，清單中的使用案例必須與正式需求逐項核對。例如，UC-04應遵守BR-05「評審不得審查本人所指導之學生團隊」；UC-03應反映PDF格式及20 MB容量限制；UC-05與UC-06則應符合已提交評分不能直接修改的規則。

此表仍屬候選清單。各項使用案例在需求、業務規則、驗收準則與參與者責任完成核對後，才可轉為正式使用案例清單；共用或條件式行為若被建成獨立使用案例，也應配置識別碼並建立追蹤關係。