6.9 AI輔助使用案例建模、追蹤與品質檢查

6.9.1 AI可以協助的工作

生成式AI可以協助整理候選參與者、候選使用案例及候選情境，也能產生PlantUML或Mermaid等文字式使用案例模型，或比較需求與模型之間的不一致。但AI無法自行確認需求真實性，因此，AI不應替代權責人員決定系統範圍與業務規則。

• 從需求文件擷取候選參與者與目標。
• 將相關FR、BR及AC歸入候選使用案例。
• 找出過大、過小或名稱不一致的使用案例。
• 產生使用案例描述初稿。
• 列出可能的替代流程與例外流程。
• 產生PlantUML、Mermaid或其他文字式模型語法。
• 比對圖、描述、需求及驗收準則。
• 產生審查清單與待確認事項。

AI輸入應盡量包含系統範圍、正式術語及識別碼登錄表，並明確要求AI不得自行補充缺乏來源支持的內容。資料不足時，應將相關項目標示為待確認事項（TBC），並由人工進一步查核，而不是補成看似完整的需求。

6.9.2 建立可追溯的提示詞

提示詞可以要求AI為每個候選項目保留依據：

若AI無法指出某項功能的來源，該內容就不應直接列為正式模型元素。

6.9.3 建立追蹤矩陣

以下以Case M01「專題競賽報名與審查系統」為例，建立使用案例追蹤矩陣。矩陣將使用案例連結至功能需求（FR）、業務規則（BR）及驗收準則（AC），可用來檢查模型是否具有需求依據，也能協助發現尚未建立驗收準則的項目。

矩陣應以正式需求登錄內容為準；表中若缺乏足夠依據的關係，必須再確認。

6.9.4 AI品質檢查流程

可採用下列流程：

1. 提供已確認的需求、規則及術語。
2. 要求AI產生候選模型與來源對照。
3. 以第二次提示要求AI只檢查缺漏、衝突與無來源內容。
4. 由系統分析者核對每項判斷。
5. 將未確認內容轉為TBC，不直接納入正式模型。
6. 修正模型後重新執行追蹤與一致性檢查。

檢查項目包括：

• 是否出現不存在的角色或系統？
• 是否將利害關係人誤當成參與者？
• 是否把操作步驟誤列為使用案例？
• 是否統一使用Case M01的正式術語「專題」？
• 關係方向與UML語意是否正確？
• 是否有FR未被任何使用案例反映？
• 是否有使用案例缺乏需求依據？
• 圖與文字描述是否使用相同識別碼及名稱？

6.9.5 AI Lab：產生並審查候選模型

任務：以Case M01需求資料產生並審查候選使用案例模型。

操作步驟：

1. 提供系統範圍、參與者候選清單與識別碼登錄表。
2. 要求AI輸出候選使用案例清單及來源對照。
3. 要求AI依指定工具產生PlantUML或Mermaid初稿；若使用Mermaid，應採用Mermaid 11.13版（含）以前支援的語法。
4. 人工檢查系統的邊界、名稱、關係與規則。
5. 將錯誤分為語法錯誤、語意錯誤、需求錯誤及無來源假設。
6. 修正後再次比對需求覆蓋情況。

AI輸出的流暢程度不能作為正確性的證據。正式採用前，應由熟悉業務與UML的人員共同確認。