撰寫訣竅：先回答「為什麼要做這個功能？解決了誰的什麼痛點？」，目標是後續所有規格、卡控、驗收標準的指北針，遇到爭議時都要回頭對齊目標。

MUST 寫

• 用「動詞 + 對象 + 目的」描述每一條目標，例如「提供 X 讓 Y 可以 Z」
• 對應到具體角色（誰受益），避免「提升使用體驗」這種無主詞、無對象的空話
• 標註尚未確認的目標（可用斜體 + * 標記），保留討論彈性

MUST NOT 寫

• 不寫實作細節（那是「規格」段的事），這裡只談「要達成什麼」
• 不寫無法被驗證的形容詞（「更好用」、「更直覺」），改用可量化或可觀察的結果
• 不把「待釐清的問題」混進來，應該移到「待釐清」段以投票形式呈現

撰寫訣竅：權限是規格書的「政治體制」，誰能看、誰能改、誰能刪一旦寫錯，後面整份規格的卡控、驗收、UI 條件都會跟著錯。建議用 CRUD（或 RCED）矩陣明確列出，避免用「管理者」「使用者」這種模糊詞。

MUST 寫

• 每個角色都對應到 R/C/E/D 的明確權限組合
• 角色名稱用站內詞彙連結（例如 排班負責人），維持全文一致
• 若有「自己 vs 他人」的差異（如只能編輯自己的資料），要特別點出

MUST NOT 寫

• 不寫尚未定義的角色，未定義就先列在「待釐清」
• 不用「Admin / User」這種通用詞代替業務角色
• 不把功能說明混進來（例如「排班負責人可以排班」），那是規格段的責任

撰寫訣竅：規格是把「目標」轉成可被開發的功能清單。建議「宏觀 → 微觀」兩段式拆解：

• 宏觀：用心智圖或魚骨圖切出大項（例：正式班表 → 日曆介面、篩選、編輯、統計、保存）
• 微觀：對每個大項用 5W + 1H 展開細節，並從「功能面」和「資料面」兩個角度各跑一次

MUST 寫 — 功能面 5W1H

• WHAT：是什麼功能
• WHO：誰可以用（對齊「使用角色」段的權限）
• WHERE：在哪個介面 / 頁面下可以使用
• WHEN：什麼情況下會用到（時間、狀態、前置條件）
• HOW：怎麼運作，作法要回扣「目標」

MUST 寫 — 資料面 5W1H

• WHAT：是什麼資料
• WHO：誰可以讀寫（對齊權限）
• WHERE：資料從哪來、存到哪
• WHEN：更新週期、是否需要實時
• HOW：如何處理、轉換、呈現

MUST 寫 — 資料敏感度：每個欄位都要交代型別細節，否則就是在把決策丟給工程師。

MUST NOT 寫

• 不寫實作技術（資料表名稱、API path、framework），那是技術設計文件的範疇
• 不寫沒有對應目標的功能（沒有 WHY 的功能就是 over-engineering）
• 不寫「之後再決定」的欄位細節（型別、長度、格式），有疑慮移到「待釐清」
• 不寫無 WHO 的功能（沒指定角色等於所有人都能用，幾乎都是漏洞）

撰寫訣竅：卡控是「不能做什麼 / 系統會擋什麼」的明確規則，是工程師寫驗證邏輯與 QA 設計反向測試案例的依據。每條卡控都應該能對映到一條驗收標準。

MUST 寫

• 用「條件 → 結果」格式描述，例如「同一天已有人 → 無法再選第二位」
• 列出資料合法性限制（必填、格式、長度、範圍、唯一性）
• 列出狀態流轉限制（例如已保存的班表不能被刪除）
• 與「驗收標準」表中的反向情境互相對照，確認每條卡控都有測試覆蓋

MUST NOT 寫

• 不寫「應該要擋」這種模糊語氣，要寫死「無法選取」「按鈕 Disabled」「跳出錯誤訊息 X」
• 不把 UI 行為（顏色、動畫）寫進來，那屬於規格 / 設計稿
• 不重複「規格」段已寫過的功能描述，卡控只列「限制與例外」

撰寫訣竅：邊界情況是「合法但極端」的場景——資料量爆量、時區、跨月跨年、空集合、最大/最小值、並發操作、網路中斷後重試。和「卡控」的差別是：卡控擋掉非法行為，邊界情況處理合法但容易被忽略的極端狀況。

MUST 寫

• 空狀態（沒有任何值日生、班表為空時頁面長什麼樣）
• 極值（一個月排 30 天都同一人、單人排班次數為 0）
• 時間相關（跨月、跨年、夏令時間、不同時區、月底 31 號）
• 並發（兩個排班負責人同時編輯時誰先寫入）
• 資料載入失敗 / 網路中斷時的 fallback

MUST NOT 寫

• 不寫「應該要處理一下」這種沒有結論的記錄，要寫死預期行為
• 不把「卡控」的內容（非法輸入）重複寫進來
• 不把實作層細節（DB transaction、lock 機制）寫進來，邊界情況只談「使用者看到什麼結果」

撰寫訣竅：驗收標準用 Given / When / Then（BDD）格式，是 PM、工程師、QA 三方對「做完了沒」的共同契約。每一條「目標」、「規格」、「卡控」、「邊界情況」理論上都應該至少有一條對應的 Scenario。

MUST 寫

• 正向情境（happy path）：使用者照預期操作能達成目標
• 反向情境（卡控觸發）：使用者違反規則時系統的回應
• 邊界情境：極值、空狀態、跨期等的預期結果
• 每個 Scenario 都用「使用者語言」寫，不寫 SQL、API、code

MUST NOT 寫

• Given/When/Then 不要寫實作（不要寫「呼叫 POST /api/schedule」），改寫「點擊保存按鈕」
• 不寫沒有 Then 的 Scenario（沒有預期結果就無法驗收）
• 不寫一個 Scenario 包含多個 When（一條只驗一件事，多步驟拆成多條）
• 不在 Then 中寫「應該要正常運作」這種不可驗證的描述