• 1
  確認屬於哪一個專案底下的哪一個模組
• 2
  摘要應附上該網頁的名稱，甚至檔名或功能規格名稱

• 1
  哪一支網頁／程式（URL、檔名）
• 2
  進行了什麼操作（詳細步驟）
• 3
  什麼時間發生
• 4
  發生了什麼問題（實際結果 vs 預期結果）
• 5
  以前有沒發生過
• 6
  其他人有沒發生過
• 7
  是 Error（程式掛了）、Failed（資料錯誤）、畫面不如預期、速度太慢、版面問題、還是規格異動
• 8
  測試環境的 OS、Browser 版本；沒問題的環境也應提供
• 9
  擷取畫面，甚至錄製操作流程
• 10
  協助重現問題的資訊
• 11
  如果可以，最好能提供測試資料

ECR 是需求或規格層面的變更申請，與問題單不同：

• ✓
  想新增功能，或對現有功能做不在原規格內的修改
• ✓
  現行流程或 UI 需要調整，但系統本身並沒有壞
• ✓
  變更影響範圍較大，需要 PM / SA 評估與核准才能進行
• ✓
  涉及多個模組或系統的連動修改

💡 簡單判斷法：系統按照規格運作，但你覺得「規格應該要不一樣」→ 開 ECR；系統沒按規格運作 → 開問題單

• 1
  變更標題：格式建議 [模組] 簡述想做什麼，讓人一眼看懂
• 2
  變更類型：需求新增 / 需求修改 / 規格調整 / 流程調整 / UI 調整 / 效能 / 安全性
• 3
  優先級：Urgent（影響上線） / High / Normal / Low，如實填寫，勿全填最高
• 4
  變更原因：說明為什麼要改，背景、用戶回饋或業務需求
• 5
  現行作法 (As-Is)：目前系統怎麼運作，截圖更好
• 6
  變更後作法 (To-Be)：期望的結果，盡量附上流程說明或 wireframe
• 7
  影響頁面：列出所有會受影響的頁面或 API，漏填可能遺漏評估範圍
• 8
  驗收標準 (AC)：列出可驗收的條件，讓 IT 知道做到什麼程度算完成

• 1
  審核結果：核准 / 退回 / 需討論，不能空著不填
• 2
  審核意見：退回時務必說明原因，核准時可補充調整重點
• 3
  指派給：核准後填入負責實施的 IT 人員
• 4
  期望完成日期：給 IT 明確的交付時間參考