範本

變更日誌範本（CHANGELOG Template） 參照標準：Keep a Changelog 1.1.0 / Semantic Versioning 2.0.0 文件用途：記錄專案每個版本的顯著變更，讓使用者與開發者了解版本間的差異 適用階段：專案全生命週期（每次發版皆需更新） 📋 章節目錄 文件資訊 格式規範 變更類別定義 版本編號規則 撰寫規範 CHANGELOG 完整範本 自動化產生 附錄 1. 文件資訊 📝 範本 項目 內容 文件名稱 CHANGELOG.md 位置 專案根目錄 格式 Markdown（Keep a Changelog 格式） 維護者 {Release Manager / 開發團隊} 更新時機 每次版本發布（Release） 📖 使用說明 CHANGELOG.md 置於專案根目錄，與 README.md 並列 每次 Release 前更新，不是每個 Commit 都記錄 記錄「對使用者有意義的變更」，非所有技術細節 💡 範例 CHANGELOG.md 通常長這樣的開頭： # Changelog All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). 2. 格式規範 📝 範本 # Changelog All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). ## [Unreleased] ### Added - {新功能描述} ## [{版本號}] - {YYYY-MM-DD} ### Added - {新增功能} ### Changed - {變更項目} ### Deprecated - {即將移除的功能} ### Removed - {已移除的功能} ### Fixed - {修復的問題} ### Security - {安全性修復} [Unreleased]: {repo-url}/compare/v{版本}...HEAD [{版本號}]: {repo-url}/compare/v{前版本}...v{版本} 📖 使用說明 [Unreleased] 區塊永遠在最上方，收集尚未發布的變更 發版時將 [Unreleased] 內容移至新版本區塊 版本由新到舊排列（最新在最上面） 底部的連結區塊提供版本間的 diff 比較連結 💡 範例 見第 6 節完整範本。 ...

資料庫設計文件範本（Database Design Document Template） 適用標準：ISO/IEC 11179（Metadata Registries）、DAMA DMBOK 2.0、ISO/IEC/IEEE 42010:2022 適用階段：系統設計階段（Design Phase） 負責角色：系統架構師（SA）、資料庫管理師（DBA） 📑 章節目錄 文件資訊 資料庫架構概觀 實體關聯模型（ER Diagram） 資料表設計 索引設計策略 資料關聯與完整性約束 命名規範 資料治理與安全 效能設計考量 資料遷移與版本控制 附錄 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 資料庫設計文件 文件編號 [專案代碼]-DBD-[版本號] 版本 v[X.Y] 建立日期 [YYYY-MM-DD] 最後更新 [YYYY-MM-DD] 撰寫者 [SA/DBA 姓名] 審核者 [技術主管/架構師] 核准者 [專案經理] 版本歷程 版本 日期 修改人 修改內容 v1.0 [YYYY-MM-DD] [姓名] 初版發布 關聯文件 文件名稱 文件編號 關係 系統架構文件（SAD） [編號] 上游輸入 功能需求文件（FRD） [編號] 需求來源 API 規格文件 [編號] 介面對應 2. 資料庫架構概觀 2.1 資料庫技術選型 項目 選擇 說明 RDBMS [PostgreSQL / SQL Server / MySQL] [選型原因] 版本 [版本號] 部署模式 [Single / Primary-Replica / Cluster] [HA 需求] 字元集 [UTF-8 / UTF-16] 排序規則 [Collation] 2.2 資料庫實例配置 實例名稱 用途 主機 連接埠 備註 [DB_MAIN] 主要業務資料 [hostname] [port] Primary [DB_READ] 讀取副本 [hostname] [port] Read Replica [DB_ARCHIVE] 歷史資料歸檔 [hostname] [port] Archive 2.3 Schema 架構 [Database] ├── schema: core -- 核心業務資料表 ├── schema: auth -- 認證授權相關 ├── schema: audit -- 稽核軌跡 ├── schema: staging -- ETL 暫存區 └── schema: archive -- 歷史歸檔 3. 實體關聯模型（ER Diagram） 3.1 概念層 ERD（Conceptual ER Diagram） 呈現主要實體（Entity）之間的高階關係，不含欄位細節。 ...

資料遷移計畫範本（Data Migration Plan Template） 適用標準：ISO/IEC 25024（資料品質）、DAMA DMBOK 2.0（Data Management） 適用階段：部署上線階段（Deployment Phase） 負責角色：DBA、Data Engineer、SA、PM 📑 章節目錄 文件資訊 遷移概要 來源與目標分析 遷移策略 資料映射規則 資料清洗與轉換規則 驗證策略 風險與應變 時程與里程碑 附錄 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 資料遷移計畫 文件編號 [專案代碼]-DMP-[版本號]-[日期] 版本 v[X.Y] 建立日期 [YYYY-MM-DD] 負責人 [DBA / Data Engineer] 審核者 [SA / PM] 2. 遷移概要 項目 內容 遷移類型 [全量遷移 / 增量遷移 / 混合式] 來源系統 [舊系統名稱 + 版本] 目標系統 [新系統名稱 + 版本] 遷移目的 [系統升級 / 平台轉換 / 整併 / 雲遷移] 資料量估計 [N] GB / [N] 筆記錄 停機視窗 [YYYY-MM-DD HH:mm ~ HH:mm] 遷移方式 [Big Bang / Phased / Parallel Run] 3. 來源與目標分析 3.1 來源系統 項目 內容 資料庫類型 [RDBMS: SQL Server / Oracle / PostgreSQL / NoSQL] 版本 [ver] Schema 數量 [N] Table 數量 [N] 總資料量 [N] GB 編碼 [UTF-8 / Big5 / …] 3.2 目標系統 項目 內容 資料庫類型 [RDBMS / NoSQL / Data Lake] 版本 [ver] Schema 設計 [New / Modified / Same] 字元編碼 [UTF-8] 3.3 遷移範圍 資料分類 資料表 筆數(估) 大小(估) 優先級 備註 Master Data [table list] [N] [N]MB P1 Transaction Data [table list] [N] [N]GB P1 Historical Data [table list] [N] [N]GB P2 Config/Lookup [table list] [N] [N]KB P1 Attachments/BLOB [storage] [N] [N]GB P2 3.4 排除範圍 資料類型 排除原因 [暫存資料/Log] [無業務價值] [超過 N 年的歷史資料] [封存處理] 4. 遷移策略 4.1 遷移方式比較 方式 說明 優點 缺點 適用場景 Big Bang 一次性全量搬遷 簡單明確 停機時間長 資料量小/可停機 Phased 分批搬遷 降低風險 需處理雙寫 資料可分割 Parallel Run 新舊並行 最安全 成本最高 核心業務系統 選定策略：[Big Bang / Phased / Parallel Run] ...

運維手冊範本（Runbook） 參照標準：ITIL 4 Service Operation / ISO/IEC 20000-1:2018 第 8.5 節「Service delivery」 文件用途：提供系統日常維運、告警處理、故障排除的標準化操作程序 適用階段：營運維護階段（Operations & Maintenance） 📋 章節目錄 文件資訊 系統概述 常見操作程序 告警處理 故障排除決策樹 緊急聯絡人 SLA 與 SLO 維護窗口與排程作業 備份與還原 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 RB-{專案代碼}-{序號} 文件名稱 {系統名稱} 運維手冊 版本 v{主版本}.{次版本} 建立日期 {YYYY-MM-DD} 最後更新 {YYYY-MM-DD} 維護者 {姓名/團隊} 適用環境 Production / Staging / All 版本歷程 版本 日期 修改人 修改內容 v1.0 {日期} {姓名} 初版 📖 使用說明 Runbook 為活文件，需隨系統變更持續更新 任何維運操作變更需同步更新本文件 建議每季審閱一次，確保內容與現況一致 💡 範例 項目 內容 文件編號 RB-HRM-001 文件名稱 HRMS 運維手冊 維護者 DevOps 團隊 — 周維運 適用環境 Production 2. 系統概述 📝 範本 2.1 系統架構 {架構圖 — 包含所有元件與連接關係} 2.2 元件清單 元件名稱 技術堆疊 部署位置 端點 用途 {元件} {技術} {位置} {URL/IP} {說明} 2.3 相依服務 外部服務 用途 端點 擁有者 SLA {服務} {用途} {端點} {團隊} {SLA} 2.4 存取方式 環境 入口 認證方式 備註 {環境} {URL/方式} {認證} {備註} 📖 使用說明 系統概述幫助值班人員快速了解系統全貌 元件清單需包含所有運行中的服務（含背景 Worker、排程任務等） 相依服務標明擁有者，出問題時知道找誰 💡 範例 2.2 元件清單 元件名稱 技術堆疊 部署位置 端點 用途 hrms-api .NET 8 Web API AKS hrms-prod ns https://hrms-api.internal:443 後端 API hrms-web React 18 + Nginx AKS hrms-prod ns https://hrms.company.com 前端 SPA hrms-worker .NET 8 Worker Service AKS hrms-prod ns N/A（內部處理） 背景排程任務 PostgreSQL v16 Azure DB for PostgreSQL hrms-db.postgres.database.azure.com:5432 主資料庫 Redis v7 Azure Cache for Redis hrms-cache.redis.cache.windows.net:6380 Session + Cache 3. 常見操作程序 📝 範本 3.1 {操作名稱} 項目 內容 操作目的 {為什麼要做} 執行頻率 手動觸發 / 每日 / 每週 / 每月 預估時間 {分鐘} 影響範圍 {影響說明} 所需權限 {權限} 步驟： ...

部署指南範本（Deployment Guide） 參照標準：ITIL 4 Release Management / ISO/IEC 20000-1:2018 第 8.5.2 節「Release management」 文件用途：提供系統部署的標準化步驟指引，確保可重複、可追蹤、可回滾的部署流程 適用階段：部署與上線階段（Release & Deployment） 📋 章節目錄 文件資訊 部署概述 先決條件 部署架構 部署步驟 驗證程序 回滾程序 監控確認 聯絡窗口 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 DG-{專案代碼}-{序號} 文件名稱 {系統名稱} v{版本} 部署指南 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 核定 建立日期 {YYYY-MM-DD} 計畫部署日期 {YYYY-MM-DD HH:mm} 撰寫者 {姓名/角色} 審核者 {姓名/角色} 核准者 {姓名/角色} 版本歷程 版本 日期 修改人 修改內容 v1.0 {日期} {姓名} 初版 📖 使用說明 依據 ITIL 4 Release Management 實務，每次部署需有正式的部署指南 文件需在部署前完成審核，未經核准不得執行部署 適用於所有環境（SIT / UAT / Staging / Production）部署 💡 範例 項目 內容 文件編號 DG-HRM-003 文件名稱 HRMS v1.0.0 正式環境部署指南 計畫部署日期 2026-10-15 22:00（維護窗口） 核准者 IT 副總 — 黃資訊 2. 部署概述 📝 範本 2.1 部署資訊摘要 項目 內容 部署類型 新系統上線 / 版本升級 / Hotfix / 組態變更 部署版本 {Application Version} 目標環境 {環境名稱} 部署方式 全量部署 / 滾動更新 / 藍綠部署 / 金絲雀部署 預估停機時間 {分鐘/小時} / 零停機 影響範圍 {受影響的服務/使用者} 維護窗口 {起始時間} ~ {結束時間} 2.2 變更內容摘要 變更編號 類型 描述 {CR/JIRA 編號} 功能/修復/組態 {簡述} 2.3 部署風險評估 風險等級 說明 高/中/低 {為何此等級} 📖 使用說明 部署類型決定所需的審核層級與流程嚴格度 Hotfix 可簡化流程但仍需記錄 預估停機時間需告知業務方，以便安排使用者通知 💡 範例 2.1 部署資訊摘要 項目 內容 部署類型 新系統上線 部署版本 HRMS v1.0.0 (Build #2026.10.12.1) 目標環境 Production (Azure AKS - hrms-prod) 部署方式 藍綠部署（Blue-Green Deployment） 預估停機時間 零停機（流量切換時間 < 30 秒） 影響範圍 全公司員工（約 2,000 人） 維護窗口 2026-10-15 22:00 ~ 2026-10-16 02:00 3. 先決條件 📝 範本 3.1 核准與簽核 項目 狀態 確認人 日期 變更審核委員會（CAB）核准 ☐ {姓名} {日期} 測試報告簽核 ☐ {姓名} {日期} 業務方確認上線同意 ☐ {姓名} {日期} 回滾計畫審核 ☐ {姓名} {日期} 3.2 技術先決條件 項目 驗證方式 狀態 {基礎設施就緒} {驗證命令/方式} ☐ {相依服務可用} {驗證命令/方式} ☐ {資料庫備份完成} {驗證命令/方式} ☐ {SSL 憑證有效} {驗證命令/方式} ☐ {DNS 設定確認} {驗證命令/方式} ☐ 3.3 部署所需權限 系統/資源 所需權限 帳號 {系統} {權限} {帳號} 📖 使用說明 所有先決條件需在部署開始前全部確認（Checklist 全部打勾） 任何一項未完成則不得啟動部署 資料庫備份是最關鍵的先決條件，未備份禁止部署 💡 範例 3.2 技術先決條件 項目 驗證方式 狀態 AKS 叢集節點 ≥ 4 kubectl get nodes 確認 Ready ☑ PostgreSQL 資料庫完整備份 確認 Azure Backup 最新備份 < 1 小時 ☑ Redis Cache 可連線 redis-cli ping 回應 PONG ☑ AD 連線正常 測試 LDAP bind ☑ Container Registry 映像已推送 az acr repository show-tags 確認 v1.0.0 存在 ☑ SSL 憑證效期 > 30 天 openssl s_client 確認到期日 ☑ 4. 部署架構 📝 範本 4.1 目標環境架構圖 {架構圖或 Mermaid 圖} 4.2 環境資訊 元件 主機/端點 規格 備註 Application Server {Host/IP} {CPU/RAM} {說明} Database {Host/IP:Port} {版本/規格} {說明} Cache {Host/IP:Port} {版本/規格} {說明} Load Balancer {Host/IP} {類型} {說明} Storage {Host/Path} {容量} {說明} 4.3 網路與防火牆規則 來源 目的 Port Protocol 用途 {來源} {目的} {Port} TCP/UDP {用途} 📖 使用說明 架構圖幫助部署人員理解全貌，建議使用 Mermaid 或繪製圖示 網路規則需在部署前確認已開通，避免部署後才發現連線失敗 機敏資訊（密碼、連線字串）不寫入文件，使用 Secret Manager 或變數引用 💡 範例 4.1 目標環境架構圖 Internet → Azure Front Door → AKS Ingress → Service ├── hrms-api (3 replicas) ├── hrms-worker (2 replicas) └── hrms-web (3 replicas) ↓ PostgreSQL (Azure DB for PostgreSQL) Redis (Azure Cache for Redis) Azure Blob Storage 5. 部署步驟 📝 範本 5.0 部署前通知 時間 對象 通知方式 內容 部署前 {N} 小時 {對象} {方式} {內容} 5.1 資料庫變更 步驟 指令/操作 預期結果 確認者 1 {SQL / Migration 指令} {預期輸出} {姓名} 2 {SQL / Migration 指令} {預期輸出} {姓名} 5.2 應用程式部署 步驟 指令/操作 預期結果 確認者 1 {部署指令} {預期輸出} {姓名} 2 {部署指令} {預期輸出} {姓名} 5.3 組態更新 步驟 指令/操作 預期結果 確認者 1 {組態變更指令} {預期結果} {姓名} 5.4 流量切換 步驟 指令/操作 預期結果 確認者 1 {切換指令} {預期結果} {姓名} 📖 使用說明 步驟需按執行順序排列，不可跳步 每步驟需有具體指令（可複製貼上執行）與預期結果 「確認者」在部署時簽名確認該步驟已完成 資料庫變更必須先於應用程式部署（確保 schema 相容） 機敏值（密碼）用環境變數或 Secret 引用，不寫死 💡 範例 5.2 應用程式部署 步驟 指令/操作 預期結果 確認者 1 kubectl set image deployment/hrms-api hrms-api=hrmacr.azurecr.io/hrms-api:v1.0.0 -n hrms-prod deployment.apps/hrms-api image updated DevOps 2 kubectl rollout status deployment/hrms-api -n hrms-prod --timeout=300s deployment successfully rolled out DevOps 3 kubectl set image deployment/hrms-web hrms-web=hrmacr.azurecr.io/hrms-web:v1.0.0 -n hrms-prod deployment.apps/hrms-web image updated DevOps 4 kubectl rollout status deployment/hrms-web -n hrms-prod --timeout=300s deployment successfully rolled out DevOps 5 確認所有 Pod 狀態正常：kubectl get pods -n hrms-prod 所有 Pod 狀態為 Running，READY 1/1 DevOps 6. 驗證程序 📝 範本 6.1 Smoke Test（冒煙測試） 測試項目 驗證方式 預期結果 實際結果 Pass/Fail {基本功能 1} {驗證方式} {預期} {實際} {基本功能 2} {驗證方式} {預期} {實際} 6.2 健康檢查 端點/服務 驗證指令 預期回應 實際回應 Pass/Fail {端點} {指令} {預期} {實際} 6.3 整合驗證 驗證項目 驗證方式 預期結果 實際結果 Pass/Fail {外部系統連接} {指令/操作} {預期} {實際} 6.4 部署成功判定標準 標準 說明 所有 Smoke Test 通過 — 健康檢查端點回應 200 持續 5 分鐘 無 Critical/High Alert 部署後 15 分鐘內 日誌無異常 Error 抽查近 100 條 Log 📖 使用說明 驗證程序在部署完成後立即執行，決定是否接受本次部署 Smoke Test 覆蓋核心業務路徑（如登入、主要功能），不需全面測試 若任何 P1 驗證失敗，立即啟動回滾程序 💡 範例 6.1 Smoke Test 測試項目 驗證方式 預期結果 實際結果 Pass/Fail 首頁可存取 curl -s -o /dev/null -w "%{http_code}" https://hrms.company.com 200 200 Pass 員工登入 使用測試帳號登入 成功進入首頁 成功 Pass 請假申請 建立一筆特休假申請 申請成功，狀態=待審核 成功 Pass 薪資查詢 查詢本月薪資明細 顯示薪資資料 成功 Pass 6.2 健康檢查 端點/服務 驗證指令 預期回應 實際回應 Pass/Fail API Health curl https://hrms-api.company.com/health {"status":"healthy"} 同預期 Pass DB 連線 curl https://hrms-api.company.com/health/db {"status":"connected"} 同預期 Pass Redis 連線 curl https://hrms-api.company.com/health/cache {"status":"connected"} 同預期 Pass 7. 回滾程序 📝 範本 7.1 回滾觸發條件 條件 決策者 {觸發條件 1} {角色} {觸發條件 2} {角色} 7.2 回滾步驟 步驟 指令/操作 預期結果 確認者 1 {回滾指令} {預期} {姓名} 2 {回滾指令} {預期} {姓名} 7.3 資料庫回滾 步驟 指令/操作 預期結果 確認者 1 {DB 回滾指令} {預期} {姓名} 7.4 回滾後驗證 驗證項目 方式 預期結果 {驗證項} {方式} {預期} 7.5 回滾時間預估 項目 預估時間 應用程式回滾 {分鐘} 資料庫回滾 {分鐘} 驗證完成 {分鐘} 總計 {分鐘} 📖 使用說明 每次部署必須有回滾計畫，這是 ITIL 4 Release Management 的核心要求 回滾步驟需預先演練驗證，不可「部署當天第一次嘗試回滾」 資料庫回滾是最複雜的部分（若有 schema 變更），需特別規劃 藍綠部署的回滾最簡單：切回舊版流量即可 💡 範例 7.1 回滾觸發條件 條件 決策者 Smoke Test 失敗 2 項以上 DevOps Lead 部署後 15 分鐘內出現 Critical Alert DevOps Lead 業務方回報核心功能異常 IT 副總 部署超過維護窗口仍未完成 DevOps Lead + PM 7.2 回滾步驟（藍綠部署） 步驟 指令/操作 預期結果 確認者 1 通知團隊啟動回滾 Teams 群組通知已發送 DevOps Lead 2 kubectl rollout undo deployment/hrms-api -n hrms-prod rollback to previous revision DevOps 3 kubectl rollout undo deployment/hrms-web -n hrms-prod rollback to previous revision DevOps 4 kubectl rollout status deployment/hrms-api -n hrms-prod successfully rolled out DevOps 5 執行 Smoke Test 驗證回滾成功 所有項目 Pass QA 6 通知業務方服務已恢復 Email/Teams 通知已發送 PM 8. 監控確認 📝 範本 8.1 部署後監控期間 項目 內容 加強監控期間 部署後 {N} 小時 監控人員 {姓名/值班表} 告警通知管道 {方式} 8.2 關鍵監控指標 指標 正常範圍 告警門檻 監控工具 API 回應時間 (P95) < {ms} > {ms} {工具} Error Rate < {%} > {%} {工具} CPU 使用率 < {%} > {%} {工具} Memory 使用率 < {%} > {%} {工具} 活躍連線數 < {N} > {N} {工具} 8.3 日誌檢查項目 日誌類型 檢查重點 工具/指令 Application Log {重點} {工具} Access Log {重點} {工具} Error Log {重點} {工具} 📖 使用說明 部署後加強監控是確保部署穩定的最後一道防線 監控期間內若指標異常，仍可啟動回滾 建議部署後 24 小時為加強監控期，48 小時後轉為一般監控 💡 範例 8.2 關鍵監控指標 指標 正常範圍 告警門檻 監控工具 API P95 回應時間 < 200ms > 500ms Grafana + Prometheus Error Rate (5xx) < 0.1% > 1% Azure Monitor CPU 使用率 < 60% > 85% Azure Monitor Memory 使用率 < 70% > 90% Azure Monitor Pod Restart Count 0 > 2 Kubernetes Dashboard DB Connection Pool < 80% > 95% Application Insights 9. 聯絡窗口 📝 範本 角色 姓名 電話 備用聯絡 職責 部署指揮 {姓名} {電話} {備用} 部署決策、Go/No-Go 判定 DevOps 工程師 {姓名} {電話} {備用} 執行部署操作 DBA {姓名} {電話} {備用} 資料庫變更 開發 Lead {姓名} {電話} {備用} 技術問題排除 QA {姓名} {電話} {備用} 部署驗證 業務窗口 {姓名} {電話} {備用} 業務確認 📖 使用說明 部署當天所有窗口需保持電話暢通 部署指揮負責 Go/No-Go 決策與回滾決定 建議建立即時通訊群組（如 Teams/Slack War Room）方便即時溝通 💡 範例 角色 姓名 電話 備用聯絡 職責 部署指揮 黃資訊（IT 副總） 0912-xxx-xxx Teams Go/No-Go 決策 DevOps 周維運 0933-xxx-xxx Teams 執行部署 DBA 趙資料 0922-xxx-xxx Teams DB Migration 開發 Lead 吳開發 0955-xxx-xxx Teams 問題排查 QA 林品質 0966-xxx-xxx Teams Smoke Test 10. 附錄 📝 範本 10.1 部署 Checklist 總表 階段 檢查項 確認 時間 確認者 部署前 CAB 核准 ☐ 部署前 資料庫備份完成 ☐ 部署前 通知使用者 ☐ 部署中 DB Migration 完成 ☐ 部署中 應用程式部署完成 ☐ 部署後 Smoke Test 通過 ☐ 部署後 健康檢查正常 ☐ 部署後 監控指標正常 ☐ 部署後 通知使用者服務恢復 ☐ 10.2 相關文件 文件 說明 {文件名} {用途} 10.3 術語定義 術語 定義 CAB Change Advisory Board，變更諮詢委員會 Blue-Green 藍綠部署，同時維護兩套環境，透過流量切換完成零停機部署 Smoke Test 冒煙測試，部署後快速驗證核心功能 Rollback 回滾，將系統恢復至部署前的版本 Maintenance Window 維護窗口，預先規劃的系統維護時段 📖 使用說明 Checklist 在部署當天使用，逐項確認並記錄時間 此 Checklist 同時作為部署紀錄保存，不可事後補填 💡 範例 10.1 部署 Checklist（已執行） 階段 檢查項 確認 時間 確認者 部署前 CAB 核准 ☑ 10/13 15:00 黃資訊 部署前 PostgreSQL Full Backup ☑ 10/15 21:30 趙資料 部署前 Email 通知全公司維護 ☑ 10/15 18:00 PM 部署中 DB Migration (3 scripts) ☑ 10/15 22:05 趙資料 部署中 K8s Deployment 更新 ☑ 10/15 22:15 周維運 部署後 Smoke Test (5/5 Pass) ☑ 10/15 22:30 林品質 部署後 監控 15 分鐘無告警 ☑ 10/15 22:45 周維運 部署後 通知服務恢復 ☑ 10/15 22:50 PM 📌 範本使用注意事項 ...

需求異動申請表範本（Change Request Template） 適用標準：ISO/IEC/IEEE 15288:2023（系統生命週期）、ITIL 4 Change Management、CMMI 適用階段：需求分析階段 / 全生命週期（Requirements Phase / Cross-Phase） 負責角色：業務分析師（BA）、專案經理（PM）、變更管理委員會（CCB） 📑 章節目錄 變更申請資訊 變更描述 影響分析 變更方案 審核與決議 實施追蹤 變更驗收 📝 範本 1. 變更申請資訊 項目 內容 變更編號 CR-[YYYY]-[NNN] 申請日期 [YYYY-MM-DD] 申請人 [姓名 / 部門] 專案名稱 [專案名稱] 變更類型 [需求變更 / 設計變更 / 範圍變更 / 缺陷修正] 優先級 [Critical / High / Medium / Low] 緊急程度 [緊急 / 一般] 目前狀態 [Draft / Submitted / Under Review / Approved / Rejected / Implementing / Completed / Cancelled] 2. 變更描述 2.1 變更摘要 項目 內容 變更標題 [一句話描述變更內容] 變更原因 [為什麼需要這個變更] 業務背景 [觸發變更的業務情境或事件] 2.2 現行需求（As-Is） 需求編號 需求描述 文件來源 [REQ-NNN] [目前的需求描述] [BRD/FRD §N.N] 2.3 變更後需求（To-Be） 需求編號 變更後描述 變更差異摘要 [REQ-NNN] [修改後的需求描述] [新增/修改/刪除了什麼] 2.4 相關附件 附件名稱 說明 [附件1] [UI 原型 / 流程圖 / 規格書片段] 3. 影響分析 3.1 影響範圍評估 影響面向 受影響項目 影響程度 說明 功能模組 [受影響的模組清單] [High/Medium/Low] 資料庫 [Schema / Table 異動] [High/Medium/Low] API 介面 [受影響的 API] [High/Medium/Low] UI 畫面 [受影響的頁面] [High/Medium/Low] 外部系統 [受影響的介接系統] [High/Medium/Low] 文件 [需更新的文件] [High/Medium/Low] 測試案例 [需新增/修改的測試] [High/Medium/Low] 3.2 時程影響 項目 原定日期 變更後日期 延遲天數 [里程碑1] [YYYY-MM-DD] [YYYY-MM-DD] [N] days 上線日期 [YYYY-MM-DD] [YYYY-MM-DD] [N] days 3.3 成本影響 成本項目 追加工時（人天） 追加費用 說明 開發 [N] 人天 [金額] 測試 [N] 人天 [金額] 設計 [N] 人天 [金額] 其他 [N] 人天 [金額] 合計 [N] 人天 [金額] 3.4 風險評估 風險 ID 風險描述 發生機率 影響程度 緩解措施 R-1 [風險描述] [High/Med/Low] [High/Med/Low] [措施] 4. 變更方案 4.1 建議方案 項目 內容 方案說明 [概述如何實施此變更] 實施步驟 1. [步驟1]2. [步驟2]3. [步驟3] 需要資源 [人力/環境/工具] 預計工期 [N] 個工作天 測試範圍 [需要回歸測試的範圍] 4.2 替代方案（如有） 方案 說明 工時 優點 缺點 方案 A [說明] [N] 天 [優點] [缺點] 方案 B [說明] [N] 天 [優點] [缺點] 5. 審核與決議 5.1 審核記錄 審核者 角色 審核日期 決議 意見 [姓名] PM [YYYY-MM-DD] [Approve/Reject/Defer] [意見] [姓名] Tech Lead [YYYY-MM-DD] [Approve/Reject/Defer] [意見] [姓名] Business Owner [YYYY-MM-DD] [Approve/Reject/Defer] [意見] 5.2 CCB 決議 項目 內容 會議日期 [YYYY-MM-DD] 最終決議 [Approved / Rejected / Deferred / Need More Info] 核准條件 [附帶條件，如有] 預計實施版本 [Release / Sprint] 6. 實施追蹤 6.1 實施任務 任務 ID 任務描述 負責人 預計完成 實際完成 狀態 T-1 [修改設計文件] [姓名] [日期] [日期] [Done/In Progress/TODO] T-2 [修改程式碼] [姓名] [日期] [日期] [Done/In Progress/TODO] T-3 [更新測試案例] [姓名] [日期] [日期] [Done/In Progress/TODO] T-4 [執行回歸測試] [姓名] [日期] [日期] [Done/In Progress/TODO] 6.2 文件更新追蹤 文件名稱 更新內容 更新人 更新日期 狀態 [BRD / FRD / SAD] [章節 N.N] [姓名] [日期] [Done/Pending] 7. 變更驗收 項目 內容 驗收日期 [YYYY-MM-DD] 驗收人 [申請人 / Business Owner] 驗收結果 [Pass / Fail / Conditional Pass] 備註 [驗收意見] 📖 使用說明 變更管理流程 graph LR A[申請提出] --> B[影響分析] B --> C[CCB 審核] C -->|Approved| D[排入計畫] C -->|Rejected| E[結案通知] C -->|Deferred| F[暫緩追蹤] D --> G[實施變更] G --> H[驗證測試] H --> I[驗收結案] 各章節填寫指引 章節 填寫時機 負責人 重點說明 §1 申請資訊 提出申請時 申請人 正確分類與設定優先級 §2 變更描述 提出申請時 申請人/BA As-Is / To-Be 需明確對比 §3 影響分析 評估階段 SA/PM 需跨團隊協作評估 §4 變更方案 評估階段 SA/Tech Lead 提供可行方案供 CCB 決策 §5 審核決議 CCB 會議後 PM 記錄完整決議與附帶條件 §6 實施追蹤 實施期間 PM 追蹤每個任務進度 §7 驗收 實施完成後 申請人/QA 確認變更符合預期 優先級與緊急程度定義 優先級 定義 SLA Critical 阻擋上線/嚴重業務影響 24 hr 內決議 High 重大功能缺失 3 工作天內決議 Medium 功能改善/優化 7 工作天內決議 Low 可延後的改善建議 下次 Sprint Planning 討論 💡 範例（以 HRMS 人力資源管理系統為例） 範例：變更申請 項目 內容 變更編號 CR-2026-015 申請日期 2026-04-10 申請人 李美玲 / 人力資源部 專案名稱 HRMS 人力資源管理系統 變更類型 需求變更 優先級 High 緊急程度 一般 範例：變更描述 變更標題： 新增「彈性工時」假別類型與計算邏輯 ...

非功能性需求設計規格範本（NFR Design Specification Template） 適用標準：ISO/IEC 25010:2023（SQuaRE - 系統與軟體品質模型）、ISO/IEC/IEEE 29148:2018 適用階段：系統設計階段（Design Phase） 負責角色：系統架構師（SA）、效能工程師、SRE 📑 章節目錄 文件資訊 品質屬性總覽 效能設計（Performance） 可用性設計（Availability） 延展性設計（Scalability） 可靠性設計（Reliability） 可維護性設計（Maintainability） 可觀測性設計（Observability） 安全性設計（Security） 相容性設計（Compatibility） 驗證與測試策略 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 非功能性需求設計規格 文件編號 [專案代碼]-NFR-[版本號] 版本 v[X.Y] 建立日期 [YYYY-MM-DD] 撰寫者 [SA 姓名] 審核者 [技術主管] 2. 品質屬性總覽 依 ISO/IEC 25010:2023 品質模型分類 品質屬性 子特性 目標等級 優先級 驗證方式 效能效率 時間行為、資源利用、容量 [目標] [High/Med/Low] [效能測試] 可用性 成熟度、容錯性、可恢復性 [目標] [High/Med/Low] [HA 測試] 延展性 水平/垂直擴展能力 [目標] [High/Med/Low] [負載測試] 可靠性 容錯、一致性 [目標] [High/Med/Low] [Chaos 測試] 可維護性 模組化、可測試性、可修改性 [目標] [High/Med/Low] [Code Review] 安全性 機密性、完整性、可用性 [目標] [High/Med/Low] [安全測試] 相容性 瀏覽器、裝置、整合 [目標] [High/Med/Low] [相容測試] 3. 效能設計（Performance） 3.1 效能目標 指標 日常目標 尖峰目標 測量方式 回應時間（P50） < [N]ms < [N]ms APM / Load test 回應時間（P95） < [N]ms < [N]ms APM / Load test 回應時間（P99） < [N]ms < [N]ms APM / Load test 吞吐量（TPS） ≥ [N] ≥ [N] Load test 並發用戶 [N] [N] Load test 錯誤率 < [N]% < [N]% Monitoring 3.2 效能設計策略 策略 適用場景 設計方案 快取 [高頻讀取、低頻更新] [快取層級/策略/TTL] 非同步處理 [非即時、耗時任務] [Message Queue + Worker] 連接池 [DB/HTTP 連線] [Pool size + timeout 設定] 分頁查詢 [大量資料列表] [Cursor-based / Offset pagination] 批次處理 [大量寫入] [Batch size + 排程策略] CDN [靜態資源] [CDN provider + cache policy] 3.3 效能預算（Performance Budget） 資源 預算 目前值 狀態 首頁載入（FCP） < [N]s [N]s [✅/⚠️/❌] 最大內容繪製（LCP） < [N]s [N]s [✅/⚠️/❌] 累計版面偏移（CLS） < [N] [N] [✅/⚠️/❌] 互動至下一次繪製（INP） < [N]ms [N]ms [✅/⚠️/❌] JS Bundle Size < [N]KB [N]KB [✅/⚠️/❌] API Response Size < [N]KB (avg) [N]KB [✅/⚠️/❌] 4. 可用性設計（Availability） 4.1 SLA 定義 服務 SLA 目標 允許停機/月 計算方式 [核心服務] [99.9%] [~43.8 min] Uptime / Total time [次要服務] [99.5%] [~3.6 hr] [背景服務] [99.0%] [~7.3 hr] 4.2 高可用設計 元件 HA 模式 Failover 時間 健康檢查 [元件] [Active-Active / Active-Passive / N+1] [N]s [HTTP/TCP/Custom] 4.3 停機策略 停機類型 通知時間 持續時間 影響範圍 核准 計畫性維護 [N 天前] [N hr] [描述] [PM/業務] 緊急修復 [即時] [N hr] [描述] [Tech Lead] 5. 延展性設計（Scalability） 5.1 擴展策略 維度 策略 設計 水平擴展（Scale-Out） [無狀態 + Load Balancer] [Auto-scaling rules] 垂直擴展（Scale-Up） [資料庫 / 特殊運算] [上限與遷移計畫] 資料擴展 [分區 / Sharding] [分區策略] 5.2 容量規劃 時間軸 預估用戶 預估資料量 預估 TPS 對應架構 上線 [N] [N] GB [N] [架構描述] 6 個月 [N] [N] GB [N] [是否需擴展] 1 年 [N] [N] GB [N] [擴展方案] 3 年 [N] [N] GB [N] [重大架構變更?] 6. 可靠性設計（Reliability） 6.1 容錯設計 故障場景 影響 容錯機制 降級方案 [單節點故障] [描述] [自動 failover] [N/A] [DB 連線失敗] [描述] [Circuit Breaker] [顯示快取資料] [外部 API 超時] [描述] [Retry + Timeout] [預設值/離線模式] [整個 AZ 故障] [描述] [Multi-AZ 部署] [部分功能降級] 6.2 Circuit Breaker 設計 服務 Open 條件 Half-Open 條件 Close 條件 Fallback [服務] [N 次失敗 in M 秒] [N 秒後] [N 次成功] [降級方案] 6.3 Retry 策略 場景 最大重試 退避策略 可重試條件 [HTTP call] [N] 次 [Exponential backoff + jitter] [5xx, timeout, network error] [DB operation] [N] 次 [Fixed interval] [Deadlock, connection lost] 7. 可維護性設計（Maintainability） 品質指標 目標 度量方式 程式碼覆蓋率 ≥ [N]% [CI/CD report] 技術債指標 [SQALE ≤ N days] [SonarQube] 模組耦合度 [低耦合] [Architecture fitness test] 部署頻率 [≥ N 次/週] [CI/CD metrics] 修復前置時間 [< N hr] [DORA metrics] 8. 可觀測性設計（Observability） 8.1 三大支柱 支柱 工具 設計 Metrics [Prometheus / CloudWatch] [RED + USE metrics] Logging [ELK / Loki] [Structured JSON, correlation ID] Tracing [Jaeger / Zipkin / OTEL] [Distributed tracing, 100% sampling for errors] 8.2 SLI/SLO 定義 SLI（指標） SLO（目標） 計算方式 告警閾值 Availability [99.9%] successful requests / total requests < 99.8% → Warning Latency (P95) [< 200ms] histogram_quantile(0.95) > 300ms → Warning Error Rate [< 0.1%] 5xx / total requests > 1% → Critical Throughput [≥ N TPS] rate(requests_total[5m]) < N*0.7 → Warning 9. 安全性設計（Security） 詳見安全設計文件（SecurityDesign_Template.md），此處僅摘要 NFR 指標 ...

System_Analysis_Phase/ ├── 01_SRS/ # 需求規格文件 │ ├── 01_前言.md │ ├── 02_整體描述.md │ ├── 03_功能性需求.md │ ├── 04_非功能性需求.md │ ├── 05_系統介面需求.md │ └── 附錄_名詞解釋_參考資料.md │ ├── 02_Use_Case/ # 使用案例文件 │ ├── 00_使用案例總覽圖.png │ ├── UC01_名稱_使用案例說明.md │ ├── UC02_名稱_使用案例說明.md │ ├── UCxx_…md │ ├── 使用案例活動圖/ # Activity Diagrams │ │ ├── UC01_活動圖.png │ │ └── UC02_活動圖.png │ └── 使用案例需求對應表.xlsx │ ├── 03_System_Model/ # 系統模型 (UML) │ ├── Object_Model/ # 物件模型 │ │ ├── 類別圖_ClassDiagram.png │ │ └── 物件圖_ObjectDiagram.png │ ├── Interaction_Model/ # 互動模型 │ │ ├── UC01_序列圖_Sequence.png │ │ ├── UC02_序列圖_Sequence.png │ │ └── 通訊圖_Communication.png │ ├── State_Model/ # 狀態模型 │ │ ├── ClassA_狀態圖.png │ │ └── ClassB_狀態圖.png │ └── Supplementary_Model/ # 補充模型 │ ├── 組件圖_Component.png │ └── 部署圖_Deployment.png │ ├── 04_Data_Model/ # 資料模型 │ ├── ER_Model.png │ ├── Class_Table_Mapping.xlsx │ └── Data_Dictionary.xlsx │ ├── 05_RTM/ # 需求追蹤矩陣 │ └── Requirement_Traceability_Matrix.xlsx │ ├── 06_Validation_Review/ # 驗證與審查 │ ├── 需求審查會議紀錄.md │ ├── 問題清單與解決狀態.xlsx │ └── 需求基線確認_Baseline_Approval.pdf │ └── README.md # 系統分析階段文件總覽

1️⃣ 需求規格文件 (SRS – Software Requirement Specification) 目錄建議： 前言 1.1 文件目的 1.2 系統範疇與邊界 1.3 定義、縮寫與名詞解釋 1.4 文件參考資料 整體描述 2.1 系統目標 2.2 系統使用者與利害關係人 2.3 作業環境 (硬體/軟體/網路/外部系統) 2.4 假設與限制 功能性需求 按使用案例或模組分項列出需求 非功能性需求 效能需求 (Response Time, Throughput) 安全性需求 (Authentication, Authorization, Audit) 可用性 / 擴充性需求 法規/合規性需求 系統介面需求 外部系統介接規格 API / 資料交換格式 2️⃣ 使用案例文件 (Use Case Specification) 目錄建議： 使用案例總覽 (Use Case Diagram) 使用案例清單 UC01：名稱、角色、前置條件、後置條件、主要流程、替代流程、例外情境 UC02 … 使用案例活動圖 (Activity Diagram) 用案例與需求對應表 (Traceability) 3️⃣ 系統模型文件 (UML Models) ...

1️⃣ 需求規格文件 (SRS – Software Requirement Specification) 目錄： 01_SRS/ ├── 01_前言.md # 文件目的、系統範疇、名詞定義 ├── 02_整體描述.md # 系統目標、利害關係人、作業環境、限制 ├── 03_功能性需求.md # 按模組/使用案例列需求 ├── 04_非功能性需求.md # 效能、安全性、可用性、法規 ├── 05_系統介面需求.md # 外部系統介接、API、資料交換 └── 附錄_參考資料.md 2️⃣ 使用案例文件 (Use Case Specification) 目錄： 02_Use_Case/ ├── 00_使用案例總覽圖.png ├── UC01_名稱_說明.md # 前置條件、後置條件、主要/替代流程 ├── UC02_名稱_說明.md ├── UCxx_…md ├── 使用案例活動圖/ │ ├── UC01_活動圖.png │ └── UC02_活動圖.png └── 使用案例需求對應表.xlsx 3️⃣ 系統模型文件 (UML Models) 目錄： 03_System_Model/ ├── Object_Model/ # 物件模型 │ ├── 類別圖_ClassDiagram.png │ └── 物件圖_ObjectDiagram.png ├── Interaction_Model/ # 互動模型 │ ├── UC01_序列圖.png │ ├── UC02_序列圖.png │ └── 通訊圖_Communication.png ├── State_Model/ # 狀態模型 │ ├── ClassA_狀態圖.png │ └── ClassB_狀態圖.png └── Supplementary_Model/ # 補充模型 ├── 組件圖_Component.png └── 部署圖_Deployment.png ...