交付成果需求檢查清單分析 是做什麼的？
授權條款： 採用 CC BY 4.0 釋出 — 可自由使用、改編和分享，但需標示出處。
一份提供的清單只是關於義務的主張，而非義務的證明。 一份看似結構完整、使用正確術語且僅列出真實工件的清單，仍可能遺漏資助方實際要求的每項內容，並用無人要求的工作填補其餘部分。正是其看似合理的外表使其具有風險，因為收到清單的人即將承諾產出清單上的每一項。
此技能對每一個項目的提問並非「這是真實存在的東西嗎？」，而是 「誰要求這個，我能引用他們的說法嗎？」 當答案是「沒有人」時，說出這個事實本身就是一個重要發現，而非需要填補的缺口。
使用時機
- 有人手持一份清單（來自範本、供應商、顧問、框架或 AI），正在決定是否採用或追蹤它。
- 工作由某個發布自身需求、範本或檢查清單的機構提供資金、進行監管或監督。
不適用於：從無到有起草一份清單（應從資助方的範本開始），或審查已完成的文件品質。
方法
1. 按原樣編目提供的清單
完全按照提供的順序編號每個項目。先不要合併、重新命名或新增。記錄清單的來源和日期（如果已知）。
2. 取得並閱讀管轄來源文件
確認誰為此工作提供資金、進行監管或批准。取得他們實際的範本、檢查清單或指導文件，並閱讀其章節列表。 不要根據此類範本「可能」包含的內容進行推理。需求會隨著生效日期而變化，而下游的摘要通常不會承載這些日期，因此原始文件是唯一可靠的檢查依據。記錄每個來源文件的標題、版本和日期。
如果無法取得某個管轄來源文件，請說明情況，並在每個依賴該文件的結論處標記為「暫定」。
3. 為每個項目標記一個權威值
| 標籤 | 意義 | 所需證據 |
|---|---|---|
| 資助方 | 資金提供或監督機構要求 | 範本章節、指導條款或獎勵條件 |
| 法規 | 法令或法規要求 | 引用具體條文 |
| 指定人員 | 特定人員在某個日期要求 | 人員姓名與日期 |
| 常見實務 | 常見且可能有用，但未找到要求來源 | 已搜尋的範圍 |
「常見實務」是合法的結果，而非失敗。同時標記任何依賴於專案中不存在之機構或角色的項目（例如，一個沒有發布簽署委員會的專案卻有該委員會的相關項目）。
4. 在單獨的第二輪中找出遺漏項目
僅在步驟 3 完成後，逐章節 瀏覽管轄範本，並列出提供的清單遺漏的每個必要項目。將新增的項目明顯地與提供的項目分開，以便任何人都能區分哪些來自來源、哪些是分析引入的。新增項目的數量上限為來源文件要求的項目，並記錄任何考慮過但被拒絕的項目，同時附上理由。每個新增的項目都是交給實際工作人員的工作。
5. 輸出
- 表格： 項目 · 來源（提供/新增） · 權限標籤 · 引用或證據 · 備註（依賴於不存在的機構、與其他項目重疊等）。
- 刪除 / 保留 / 新增：
- 刪除： 無要求來源的常見實務項目，且團隊不需要。說明每個項目被刪除的原因。
- 保留： 有引用來源的項目，加上團隊選擇保留的常見實務項目，並標明此為選擇。
- 新增： 清單遺漏的必要項目，每個項目附上其引用來源。
- 已閱讀的來源檔案： 每個管轄文件的標題、版本和日期，以及任何無法取得的文件。
範例（通用）
一個接受軟體捐贈的開源函式庫，從顧問那裡獲得了一份包含 17 個項目的「標準發布文件」清單，並分為設計、建置、發布和維護四個群組。查閱該捐贈專案的里程碑範本，發現有 5 個必要交付成果。其中 2 個在清單上但名稱不同；另外 3 個根本不在清單上。在提供的 17 個項目中，有 2 個與捐贈要求相符，1 個是依賴套件的授權合規條款要求的，2 個是主要維護者要求的，其餘 12 個是常見實務，沒有要求來源。這 12 個中有 3 個假設存在一個專案中沒有的安全審查團隊。結果：保留 5 項，新增 3 項，刪除或設為選用 12 項。
如果沒有進行此檢查，團隊會承諾完成 17 個項目，卻錯過了捐贈審查者實際會檢查的 3 個項目。
報告完成前的檢查清單
- 每個提供的項目都有且僅有一個權威標籤。
- 每個標記為「資助方」或「法規」的項目，都附有實際閱讀過的來源文件的引用。
- 管轄範本已逐章節閱讀完畢，或者已說明其缺失，且所有結論都標記為暫定。
- 新增的項目與提供的項目已明顯分開。
- 刪除 / 保留 / 新增建議已給出，且每一行都有理由。