8.2 辨識資料需求與候選實體

8.2.1 從名詞與業務事件找出資料

需求文字中的名詞是辨識資料實體的起點。人員、組織、事件、交易、文件與紀錄，都可能成為候選實體。例如Case M01中的競賽、團隊、報名、專題文件、評審分派、評分及競賽結果。

業務事件也能協助辨識資料。當流程出現「提交報名」「正式送出評分」「提出更正申請」或「確認結果」時，可以詢問：

• 事件發生前需要讀取哪些資料？
• 事件完成後需要新增或更新哪些資料？
• 是否必須保存事件的時間、執行者及結果？
• 事後是否需要查詢、稽核或還原？

8.2.2 判斷實體是否具有獨立意義

候選實體通常具有一項以上特徵：

• 需要獨立識別。
• 具有多個重要屬性。
• 與其他資料形成重要關係。
• 會在多個使用案例中被讀取或更新。
• 具有需要保存的狀態或歷程。

舉例來說，在Case M01中，「評分更正申請」具有提出者、理由、時間、處理人員與處理結果，並且DR-06要求保存更正前後內容，因此不能只當成評分上的一個布林欄位。

8.2.3 排除不適當的實體

常見誤判包括：

• 把按鈕、頁面或表單視為資料實體。這是系統介面，不是資料實體。
• 把「查詢」「上傳」等動作視為實體。
• 把PDF等允許值視為獨立實體。通常PDF檔案內容是資料的一個屬性，跟專題題目一樣，都是屬性。
• 把同一概念的不同稱呼建立成兩個實體。需統一同一概念的不同稱呼，避免出現兩個實體。
• 由其他資料計算的結果重複保存，卻沒有保存需求的資料視為實體。
• 因AI建議而加入沒有來源的資料。這應該加以確認後才加入。

8.2.4 建立候選資料實體清單

候選清單只是分析起點，不代表所有欄位與關係已經確認。