政府 AI 採購與需求規格

10 分鐘

把 Use Case 寫成可驗收的需求（一）：功能與流程

把一個 AI Use Case 轉成採購需求時，必須把「這個系統應該做什麼」拆解成具體類別，每一類都要能被驗證，而不是只寫「導入智慧化 AI 系統」這種無法驗收的形容詞。

• 功能需求：系統要完成哪些具體任務，對應模組 1 的 Use Case。
• Workflow 需求：步驟順序、分流與人工關卡如何運作，對應模組 2 的 Workflow Canvas。
• 資料與知識需求：需要哪些資料來源、Knowledge Base 如何建立與更新，對應模組 3 的 Context & Data Canvas。

重點: 功能與 Workflow 需求直接承接模組 1、2 的產出：把 Use Case Card 與 Workflow Canvas 拆解成可驗收的條目，而不是重新發明一套形容詞。

12 分鐘

把 Use Case 寫成可驗收的需求（二）：模型、權限、維運

• 模型與工具需求：使用哪種模型、需要連接哪些系統，對應模組 4 的 Tool & Permission Matrix。
• 權限與安全需求：Read/Write 範圍、存取控制、資安要求，對應模組 4、5 的治理設計。
• 紀錄與效能需求：日誌保存、回應時間、可靠性指標，對應模組 6 的測試與評測結果。
• 維運與版本需求：誰負責維運、如何處理模型或系統更新、可替代性（Portability）考量，影響系統能否長期維持可驗收狀態。
• Maintainability（可維護性）：系統出問題時，能不能被及時診斷與修復，而不是只能整套重做。

重點: 模型、權限、紀錄、效能、維運五類需求，把模組 4-6 的治理與測試設計，轉成採購文件上可以被檢核的具體條文。

12 分鐘

概念層級考量：雲端、第三方與所有權

重點: 概念層級的考量不是法律意見，而是提醒承辦人在簽約前就該問清楚：資料在哪裡、誰能拿回來、換供應商會發生什麼事。

12 分鐘

交付物與驗收證據

一條需求如果寫不出對應的交付物（Deliverable）與驗收證據（Acceptance Evidence），通常代表這條需求還不夠具體。交付物是「廠商應該交出什麼」，驗收證據是「機關依據什麼確認交付物真的符合需求」。

• 交付物範例：系統原始碼或授權、操作手冊、測試報告、Knowledge Base 建置文件、權限設定說明。
• 驗收證據範例：模組 6 產出的 Test Case 執行結果、日誌紀錄樣本、權限設定畫面或設定檔、Regression Testing 報告。
• 每條需求都應該能回答：驗證方法是什麼？誰執行驗證？什麼結果算通過？

重點: 每一條需求都要能同時回答「交付什麼」與「怎麼證明做到了」，兩者缺一，這條需求就還沒準備好進入驗收。

14 分鐘

實作：From Use Case to Procurement Requirement

活動 7 把模組 2 的一個 Workflow 需求轉換成具體的採購需求，填入 Government AI Procurement Requirements Sheet，為模組 8 的驗收決定準備好對應的需求基礎。

1. 1選一個 Workflow 需求
   沿用模組 2 的 Workflow 設計。
2. 2寫成具體需求
   避免「智慧化」「更聰明」等無法驗收的形容詞。
3. 3定義驗證方法
   要怎麼確認這個需求有沒有被滿足？
4. 4定義驗收標準與所需證據
   達到什麼條件才算通過？需要哪些證據？

• Government AI Procurement Requirements Sheet 最少欄位：Requirement ID、Category、Requirement、Rationale、Priority、Risk、Verification Method、Acceptance Criterion、Required Evidence、Owner、Supplier Responsibility、Agency Responsibility、Change / Version Rule。

• 前往實作頁：活動 7 From Use Case to Procurement Requirement

重點: 這張 Requirements Sheet 把模組 1-6 的所有判斷，轉成模組 8 驗收時可以逐條核對的依據；寫不出可驗證的需求，就寫不出可驗收的系統。