9.2 辨識領域概念與候選類別

9.2.1 從業務名詞建立候選清單

辨識候選類別的常見做法，是從需求文件、訪談紀錄、使用案例與活動描述中找出名詞或名詞片語。候選來源通常包括：

• 人員與角色，例如學生、指導教師、評審及競賽承辦人員。
• 組織與群體，例如主辦單位及參賽團隊。
• 事件與交易，例如報名、評審分派、評分及更正申請。
• 文件與紀錄，例如專題文件、評語及競賽結果。
• 規範性概念，例如報名期限、評分狀態及公告狀態。

名詞擷取只是起點。文字中出現的每一個名詞不一定都要建立成類別；沒有直接出現在文字中的概念，也可能因業務規則而必須補充。

9.2.2 判斷候選概念是否值得保留

從需求文件、訪談紀錄、使用案例與活動描述中找出名詞或名詞片語，這些名詞或名詞片語若符合下列一項或多項條件，通常值得進一步分析：

• 具有獨立的業務意義與明確定義。
• 系統需要長期保存或追蹤其資訊。
• 具有多個重要屬性。
• 會與其他概念形成重要關係。
• 會經歷可辨識的生命週期或狀態變化。
• 被多個需求、使用案例或流程共同使用。

例如，「評分更正申請」不只是畫面上的一個按鈕。它具有提出時間、理由、處理狀態及處理結果，並連結評分與經授權的競賽承辦人員，因此適合作為候選類別。

9.2.3 排除不適當的候選類別

名詞分析容易產生過多候選項目，常見的排除情況包括：

• 同義詞： 「參賽隊伍」與「團隊」若意義相同，應選擇一致用語。
• 屬性： 「團隊名稱」通常是團隊的屬性，不必建立獨立類別。
• 動作： 「上傳」是行為，不一定是領域類別；被上傳的「專題文件」才是業務概念。類別是名詞，而非動詞。
• 技術元件： 按鈕、表單、資料表或API通常不是分析類別。目前階段仍不需納入技術元件。
• 範圍外概念： 與目前系統目標無關的概念應移除。
• 過度籠統的詞： 如「資料」「內容」「系統」若缺乏明確的業務語意，不宜直接作為類別。需要具體，而非籠統。

9.2.4 Case M01候選概念初稿

由Case M01目前已確認的內容，可先建立下列候選清單：

這份清單仍屬候選成果。類別是否保留、如何命名，以及彼此如何關聯，仍須透過需求與情境驗證。