6.4 系統邊界與參與者

6.4.1 界定系統邊界

使用案例分析必須先確定研究的是哪一個系統，以及哪些角色位於該系統之外。系統邊界（System Boundary）界定模型所涵蓋的責任範圍；參與者（Actor）則代表位於邊界之外，為達成特定目標而與系統互動的角色或外部系統。請注意，參與者不一定是人，也可以是系統。在以資訊系統為分析對象的使用案例模型中，使用系統的人員角色、其他資訊系統及外部服務都位於系統邊界之外；系統所提供的使用案例則位於邊界之內，內部軟體元件通常不作為使用案例圖中的參與者。若邊界未界定清楚，同一項工作可能同時被解讀為系統功能、人工程序或外部服務，使用案例模型也就難以一致。

系統邊界不是組織邊界、部門邊界或畫面範圍。組織內的人仍位於系統邊界之外；組織內的其他資訊系統，若不屬於本次分析的系統，也位於本系統的邊界之外。邊界內是系統提供的使用案例；邊界外則是與這些使用案例互動的參與者。

界定邊界時，應先回答：

• 本次分析的系統名稱是什麼？
• 哪些業務責任由系統處理？
• 哪些工作由人員在系統外完成？
• 哪些功能由其他資訊系統提供？
• 哪些內容已確定不在專案範圍內？

以Case M01（專題競賽報名與審查系統）為例，接收報名資料、檢查報名條件、分派評審、接收評分及公告結果，可能屬於系統責任。至於教師實際指導學生、評審閱讀專題內容，以及競賽委員會討論特殊爭議，可能是系統外的業務活動。

同一個實體是否位於邊界外，取決於所選定的分析對象。例如，校園身分驗證若由另一套既有系統提供，該驗證系統就是外部參與者（請注意：參與者並不一定是人，在本例中，參與者是外部系統）；若驗證功能是本系統自行負責，則不應把它畫成外部系統。

系統邊界在需求改變時也可能調整。調整後應同步檢查使用案例、介面需求、專案範圍及追蹤關係。

6.4.2 辨識參與者

參與者代表與系統互動時所扮演的角色，不一定是一個特定的人。一個人可以扮演多個角色，同一角色也可以由多人擔任。例如，「主辦單位」與「競賽承辦人員」在模型中代表不同責任，可以由不同人分別擔任，也可以由同一人同時扮演這兩個角色。常見的參與者包括：

辨識參與者時，可以從下列問題著手：

• 誰會啟動某項系統服務？
• 誰會接收系統產生的結果？
• 誰負責提供或維護系統所需資料？
• 哪一個外部系統會傳入資料或接收資料？
• 哪個角色需要查詢、核准、確認或更正資訊？

參與者名稱應使用穩定的角色名稱，不宜直接使用個人姓名，也不宜只寫「使用者」。例如，「王老師」是個人，「教師」可能仍過於寬廣；若其在系統中的責任是評定被分派的專題，則「評審」較能表達角色。

6.4.3 主要參與者、支援參與者與利害關係人

主要參與者（Primary Actor）：主動使用系統以完成目標。例如，隊長提交競賽報名，評審評定參賽專題。

支援參與者（Supporting Actor）：向系統提供服務的參與者。例如，校園身分驗證系統提供身分確認服務。

參與者不等同於所有利害關係人。利害關係人可能關心系統結果，卻不直接與系統互動。例如，競賽贊助單位、競賽指導單位可能關心評審公平性，但若沒有直接使用系統，就不一定出現在使用案例圖中。其需求仍應保留在需求規格或業務規則中。

判斷某個角色是否為參與者，可以檢查：

1. 它是否位於系統邊界之外？
2. 它是否直接與系統交換資訊或訊息？
3. 它是否參與某個使用案例？
4. 它是否代表角色，而不是單一個人或組織單位？

6.4.4 Case M01的邊界與參與者初稿

Case M01可以先建立下列候選清單：

若系統在刪除隊員或指導教師時必須向被刪除者發送通知，則被刪除的隊員與指導教師會在該局部情境中成為接收系統結果的次要參與者，電子郵件服務則可能成為支援參與者。這些角色不一定需要出現在只呈現核心業務責任的整體圖中，但應保留在相關局部模型與需求追蹤資料中。

「主辦單位」與「競賽承辦人員」應分別依其系統責任建立角色。即使同一人同時扮演兩個角色，模型仍可保留兩個參與者，以清楚區分確認競賽結果與執行競賽行政作業的責任。

此表為模型初稿，仍需依需求來源進行確認。例如，若所有使用者都需透過另一套入口完成驗證，校園身分驗證系統可能需要出現在模型中；若驗證方式尚未決定，則應標示為待確認事項，而不是直接定案。

邊界與參與者的品質檢查包括：

• 系統名稱是否明確且一致？
• 每個參與者是否都與至少一個使用案例互動？
• 是否把系統內部元件誤列為參與者？
• 是否把沒有直接互動的利害關係人全部畫入圖中？
• 是否遺漏外部驗證、通知或資料交換系統？
• 角色名稱是否與需求文件一致？