Spec Review Checklist — 30 個問題抓出 80% 的需求漏洞
QA 在 spec review 階段抓到一個漏洞，等於開發階段省 10 倍時間，上線後省 100 倍。這份 checklist 是我跑 spec review 用的固定問題集。會議前 15 分鐘掃一遍，會議中就有具體問題能問。
怎麼用這份 checklist
- PM/PO 發 spec 後，會議前自己對 checklist 走一輪
- 每個「不確定」「沒寫到」的點，記下來
- 會議上用問題形式問（不要用「你少了 XX」開頭，會撕破臉）
- 會議後寄 follow-up email 把澄清的點寫回 spec
一、前置條件（5 個問題）
- [ ] 誰能用這個功能？ 角色、權限、付費等級、地區限制？
- [ ] 需要先做什麼？ 帳號驗證？綁定？KYC？
- [ ] 依賴哪些功能？ 如果 A 功能掛掉，這個還能用嗎？
- [ ] 支援哪些平台？ Web only？iOS 14+？舊瀏覽器？
- [ ] 多語系怎麼處理？ 文案、日期、貨幣、RTL？
🔍 實例：spec 寫「使用者可以提現」沒寫前置 → 問「未驗證 KYC 的使用者點下去會怎樣？看不到按鈕、按鈕灰、還是跳提示？」
二、輸入與邊界（6 個問題）
- [ ] 每個欄位的型別與長度限制？ （文字 1-50 字、金額 0.01-9999999）
- [ ] 空值 / null 怎麼處理？ 必填還是選填？
- [ ] 特殊字元如何處理？ emoji、SQL injection 字元、跨語言字符
- [ ] 數字邊界？ 0、負數、極大值、小數點精度
- [ ] 時間相關？ 時區、夏令時、未來時間、過去時間、跨午夜
- [ ] 批次/列表上限？ 一次能傳幾筆？10000 筆會 timeout 嗎？
🔍 實例：spec 寫「金額」沒寫精度 → 問「使用者輸 0.001 元會被接受嗎？小數第三位會被四捨五入還是無條件捨去？」
三、狀態機（5 個問題）
- [ ] 有哪些狀態？ 列出來，畫圖
- [ ] 狀態轉換規則？ 從 A → B 的條件是什麼？
- [ ] 有沒有不可逆狀態？ 取消了能恢復嗎？
- [ ] 狀態同時被改怎辦？ 兩個裝置同時操作？
- [ ] 狀態 timeout？ 「待付款」過 30 分鐘自動取消嗎？
🔍 實例：訂單有 pending、paid、shipped、cancelled → 問「shipped 之後能 cancel 嗎？退款流程從哪個狀態走？」
四、錯誤處理（5 個問題）
- [ ] 錯誤訊息文案？ 每種錯誤有對應文案嗎？多語系？
- [ ] 錯誤該不該重試？ 自動 retry 還是讓使用者自己重來？
- [ ] 部分成功怎辦？ 批次 10 筆成功 7 筆怎處理？全 rollback 還是部分提交？
- [ ] 後端 down 時前端表現？ 卡 loading？跳錯誤頁？離線模式？
- [ ] 第三方 API fail 怎辦？ 金流 timeout、簡訊送不出去
🔍 實例：spec 寫「呼叫金流 API」沒寫失敗 → 問「金流 timeout 後使用者看到什麼？訂單會被建立嗎？再按一次會重複扣款嗎？」
五、資料一致性（4 個問題）
- [ ] 資料寫多處嗎？ DB + Cache + 第三方，同步策略？
- [ ] race condition？ 兩個請求同時改同一筆會怎樣？
- [ ] 歷史資料是否受影響？ 改 schema 後舊資料怎處理？
- [ ] 刪除是 soft 還是 hard？ 刪了能查嗎？關聯資料怎麼辦？
🔍 實例：spec 寫「使用者可改 email」沒寫 → 問「email 是 login 用的，改了之後舊 session 還有效嗎？通知會寄到新還舊 email？」
六、非功能性（5 個問題）
- [ ] 效能 SLA？ API 回應 < 500ms？同時 1000 人會掛嗎？
- [ ] 資安？ 敏感資料是否加密？log 會寫到密碼嗎？
- [ ] 稽核？ 操作記錄要留多久？誰能看？
- [ ] 可觀測性？ 出事時怎麼 debug？metrics、logs 有寫嗎？
- [ ] 隱私 / 法遵？ GDPR、個資法、未成年保護？
🔍 實例：spec 沒寫 → 問「使用者要求刪除帳號時，他的訂單記錄要刪嗎？財務紀錄不能刪，但個資要去識別化嗎？」
漏洞模式辨識
走完 checklist 之後，看看 spec 有沒有這些「模糊用詞」：
| 模糊詞 | 該問什麼 |
|---|---|
| 「適時」、「即時」 | 多久內？1 秒？10 秒？next request？ |
| 「自動」 | 觸發條件？頻率？失敗怎辦？ |
| 「合理的」、「合適的」 | 量化標準？ |
| 「通常」、「一般而言」 | 那「不通常」的情況呢？ |
| 「使用者可以」 | 哪些使用者？所有狀態都可以嗎？ |
| 「應該」、「會」 | 不會的時候呢？fallback？ |
| 「等」、「之類」 | 把列舉補完，缺的列出 |
每出現一個，至少一個問題。
用法範例
某次 review「會員等級系統」spec，我用這份 checklist 跑出 12 個問題：
- （前置）非會員看到等級頁面顯示什麼？
- （前置）多語系：等級名稱「黃金」翻成英文要怎麼處理？
- （邊界）累積消費 -100 元（退費）會降級嗎？
- （邊界）跨年度怎麼算？1/1 0:00 自動 reset 還是滾動計算？
- （狀態）從黃金降白金能再升回去嗎？
- （狀態）升等是即時還是次月生效？
- （錯誤）升等通知寄信失敗怎辦？等級會升嗎？
- （一致性）使用者改名後等級記錄要更新嗎？
- （一致性）等級紀錄是寫 DB 還是算的？
- （非功能）後台改規則的話，現有會員等級會被回算嗎？
- （非功能）等級資料 GDPR 刪除請求怎處理？
- （模糊）spec 寫「使用者可以查詢自己的等級歷史」→ 查多久？分頁？匯出？
PM 回去補了 spec，省下後續至少 3 個迴歸測試循環。
最後
Spec review 不是挑剔，是替團隊省錢。會議前 15 分鐘走這份 checklist，會議中用問題形式問清楚，會議後 follow-up 確認寫回 spec。三個月後 PM 會謝謝你。