軟體工程

程式規格書（Program Specification Document）範本 版本：1.0 參照標準：IEEE 1016-2009、ISO/IEC/IEEE 12207:2017、ISO/IEC 8631:1989 適用對象：系統分析師（SA）、開發工程師、委外/外包開發廠商 文件性質：單一程式/批次工作之詳細規格文件，作為程式撰寫與驗收的直接藍圖 📋 使用說明 程式規格書是以「單一程式或批次工作」為撰寫單位的實作藍圖，將 TSD（技術規格文件）的模組/服務層級設計，進一步展開為可直接編碼的輸入輸出欄位、處理邏輯、畫面或報表版面與錯誤代碼。相較於 TSD 偏重物件導向的類別/方法設計，程式規格書更貼近傳統主機、批次、報表與轉檔程式的撰寫方式。 何時使用本範本 批次程式（Batch Job）：日結、月結、對帳、資料清算等排程程式 報表程式：產出固定版面報表、對外申報檔案 介面轉檔程式：與外部系統的檔案交換、資料匯入匯出 委外/外包開發：需要逐支程式驗收，規格必須避免「口頭補充」 任何需要精確定義輸入輸出欄位與處理邏輯、無法僅以 TSD 類別設計涵蓋的程式 與其他文件的關係 SDD（如何設計整體架構） → TSD（模組/服務層級技術規格） → 程式規格書（單一程式的實作藍圖） → Source Code ↑ ↑ ↑ ↑ 架構師 開發工程師 SA / 開發工程師 開發工程師 TSD 定義模組內的類別、方法、演算法與資料結構，適合物件導向、微服務式的系統設計 程式規格書 則是「向下再展開一層」：把 TSD 的設計具體落實到單一程式的輸入來源、輸出目的、逐步處理邏輯與例外情境，讓程式撰寫者（含委外廠商）不需回頭詢問即可完成編碼 兩者可搭配使用：物件導向服務層級用 TSD；批次/報表/轉檔類程式或委外驗收則另補程式規格書 填寫原則 輸入輸出明確：每個欄位都需標註型別、長度、必要性與驗證規則，不可只用文字概略描述 處理邏輯可執行：流程敘述與虛擬碼需精確到可直接轉換為程式碼，邏輯表示法建議依循 ISO/IEC 8631 的慣例（結構化流程圖/虛擬碼），避免撰寫者各自發明符號 正常與異常並重：正常流程之外，需完整列出所有已知的例外情境與對應處理、錯誤代碼 可獨立驗收：規格本身應足以作為驗收依據，尤其用於委外開發時 📄 範本正文 [程式代號/程式名稱] 程式規格書 1. 文件資訊 項目 內容 文件編號 PSD-[專案代碼]-[程式代碼]-[序號] 版本 v0.1 建立日期 YYYY-MM-DD 最後更新 YYYY-MM-DD 撰寫者 [SA / 開發工程師姓名] 審核者 [技術主管 / 架構師] 狀態 草稿 / 審查中 / 已核准 版本歷程 版本 日期 修改人 修改內容摘要 v0.1 YYYY-MM-DD [姓名] 初版建立 關聯文件 文件名稱 文件編號 版本 關聯性 技術規格文件（TSD） TSD-XXX-001 v1.0 所屬模組技術設計 系統設計文件（SDD） SDD-XXX-001 v1.0 系統架構來源 2. 程式基本資訊 項目 內容 程式代號 [如 BATCH-CUST-RECON-001] 程式名稱 [程式中文名稱] 程式類型 Online（線上）/ Batch（批次）/ Report（報表）/ Interface（介面轉檔） 所屬系統/模組 [系統名稱] 觸發方式 排程（Cron）/ 人工執行 / 事件觸發 / API 呼叫 執行排程 [如：每月最後一個工作日 02:00] 前置程式 [執行前必須先完成的程式代號，無則填「無」] 後續程式 [本程式完成後接續執行的程式代號，無則填「無」] 預估工時 [人天] 3. 功能說明 3.1 程式目的 一句話說明本程式解決什麼問題、為何需要。 ...

PRD（產品需求文件｜Product Requirement Document）範本 版本：1.0 參照標準：ISO/IEC/IEEE 29148:2018、ISO 9241-210:2019、IIBA BABOK v3 適用對象：產品經理、UI/UX 設計師、業務分析師、開發團隊 文件性質：產品需求定義與功能規劃文件 📋 使用說明 PRD 是將商業目標轉譯為具體功能需求的關鍵文件，定義「產品要做什麼」。它是 UI/UX 設計師與工程團隊開發的主要依據，橋接業務需求（BRD）與技術實作（SDD/TSD）之間的落差。 何時使用本範本 新產品或新功能的需求定義階段 產品重大改版前的需求整理 跨部門協作時的需求溝通基準文件 填寫原則 以使用者為中心：所有功能描述應從使用者角度出發 量化可驗證：驗收條件必須可量化、可測試 優先序明確：使用 MoSCoW 或數字排序標明優先級 迭代更新：隨需求演進持續更新文件版本 📄 範本正文 [產品/功能名稱] 產品需求文件（PRD） 1. 文件資訊 項目 內容 文件編號 PRD-[專案代碼]-[序號] 版本 v0.1 建立日期 YYYY-MM-DD 最後更新 YYYY-MM-DD 撰寫者 [產品經理姓名] 審核者 [審核者姓名 / 角色] 核准者 [核准者姓名 / 角色] 狀態 草稿 / 審查中 / 已核准 / 已凍結 版本歷程 版本 日期 修改人 修改內容摘要 v0.1 YYYY-MM-DD [姓名] 初版建立 審核紀錄 審核者 角色 審核日期 結果 備註 通過 / 有條件通過 / 退回 2. 產品概述 2.1 產品願景 簡述本產品/功能的願景，說明為何需要此產品，以及期望達成的長期目標。 ...

SDD（系統設計文件｜System Design Document）範本 版本：1.0 參照標準：ISO/IEC/IEEE 42010:2022、ISO/IEC 25010:2023、ISO/IEC/IEEE 15288:2023 適用對象：系統架構師、資深開發工程師、技術主管 文件性質：系統技術架構與設計決策文件 📋 使用說明 SDD 用於制定技術解決方案，規劃「系統要如何實作」。內容涵蓋系統架構、資料庫綱要（Schema）、API 介面規格、模組劃分與資安規範，確保系統具備擴展性與穩定性。 何時使用本範本 系統設計階段，將需求（PRD/FRD/SRD）轉化為技術方案 重大架構變更前的設計評審 跨團隊技術溝通的基準文件 與其他文件的關係 PRD（做什麼） → SDD（如何設計） → TSD（如何實作） ↑ ↑ ↑ 產品經理 架構師 開發工程師 填寫原則 決策可追溯：每個設計決策需記錄原因與替代方案 圖文並茂：架構圖、序列圖、ER 圖等應完整呈現 安全優先：每個模組需考慮資安面向 可演進：設計應預留擴展空間 📄 範本正文 [系統/模組名稱] 系統設計文件（SDD） 1. 文件資訊 項目 內容 文件編號 SDD-[專案代碼]-[序號] 版本 v0.1 建立日期 YYYY-MM-DD 最後更新 YYYY-MM-DD 撰寫者 [架構師姓名] 審核者 [審核者姓名 / 角色] 核准者 [核准者姓名 / 角色] 狀態 草稿 / 審查中 / 已核准 版本歷程 版本 日期 修改人 修改內容摘要 v0.1 YYYY-MM-DD [姓名] 初版建立 審核紀錄 審核者 角色 審核日期 結果 備註 通過 / 有條件通過 / 退回 關聯文件 文件名稱 文件編號 版本 關聯性 產品需求文件（PRD） PRD-XXX-001 v1.0 需求來源 功能需求文件（FRD） FRD-XXX-001 v1.0 功能規格 系統需求規格書（SRD） SRD-XXX-001 v1.0 系統規格 2. 系統概述 2.1 系統背景與目標 簡述本系統的業務背景、核心問題，以及本設計文件欲達成的技術目標。 ...

TSD（技術規格文件｜Technical Specification Document）範本 版本：1.0 參照標準：ISO/IEC/IEEE 15288:2023、ISO/IEC 25010:2023、IEEE 1016-2009 適用對象：資深開發工程師、技術主管、QA 工程師 文件性質：工程師實作指南與底層技術規格文件 📋 使用說明 TSD 是工程師的實作指南，詳細說明「底層技術與程式碼邏輯」。內容涵蓋類別與函式設計、演算法邏輯、資料結構、錯誤處理機制及自動化測試規劃。 何時使用本範本 進入開發實作階段前，將 SDD 的設計轉化為可直接編碼的技術規格 複雜演算法或業務邏輯需要詳細記錄時 技術交接或 Code Review 的參考文件 與其他文件的關係 PRD（做什麼） → SDD（如何設計） → TSD（如何實作） ↑ ↑ ↑ 產品經理 架構師 開發工程師 填寫原則 可直接編碼：規格描述需精確到可直接轉換為程式碼 測試可驗證：每個功能模組需附帶測試策略 錯誤完整：覆蓋所有已知的錯誤場景與處理方式 效能可量化：關鍵演算法需標注時間/空間複雜度 📄 範本正文 [模組/功能名稱] 技術規格文件（TSD） 1. 文件資訊 項目 內容 文件編號 TSD-[專案代碼]-[模組代碼]-[序號] 版本 v0.1 建立日期 YYYY-MM-DD 最後更新 YYYY-MM-DD 撰寫者 [工程師姓名] 審核者 [技術主管 / 架構師] 狀態 草稿 / 審查中 / 已核准 版本歷程 版本 日期 修改人 修改內容摘要 v0.1 YYYY-MM-DD [姓名] 初版建立 關聯文件 文件名稱 文件編號 版本 關聯性 系統設計文件（SDD） SDD-XXX-001 v1.0 架構設計 產品需求文件（PRD） PRD-XXX-001 v1.0 需求來源 API 規格文件 API-XXX-001 v1.0 介面規格 2. 技術概述 2.1 模組/功能範圍 簡述本 TSD 涵蓋的模組或功能範圍，以及與其他模組的邊界。 ...

API 規格文件範本（API Specification Document） 參照標準：OpenAPI Specification 3.1（OAS 3.1）/ Linux Foundation 標準 文件用途：定義 RESTful API 的端點、請求/回應格式、認證機制與錯誤處理規範 適用階段：系統設計階段（Detail Design Phase） 📋 章節目錄 文件資訊 API 概述 認證與授權 共用規範 端點定義 資料模型 錯誤處理 版本策略 OpenAPI 規格檔 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 API-{專案代碼}-{序號} API 名稱 {系統名稱} API API 版本 v{主版本} 文件版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 已發布 建立日期 {YYYY-MM-DD} 最後更新 {YYYY-MM-DD} 負責人 {姓名/角色} Base URL https://{domain}/api/v{version} 📖 使用說明 API 版本與文件版本分開管理：API 版本影響端點路徑，文件版本追蹤文件修訂 Base URL 需區分環境（DEV/SIT/UAT/PROD） 依據 OpenAPI 3.1 info 物件結構設計 💡 範例 項目 內容 文件編號 API-HRM-001 API 名稱 HRMS API API 版本 v1 Base URL https://api.company.com/hrms/v1 2. API 概述 📝 範本 2.1 API 目的 {描述此 API 提供的服務範圍與主要功能} ...

BRD 業務需求文件範本（Business Requirements Document） 參照標準：IIBA BABOK Guide v3 / ISO/IEC/IEEE 29148:2018 文件用途：記錄業務層級需求，作為專案啟動與範圍確認的基礎依據 適用階段：專案啟始階段（Initiation Phase） 📋 章節目錄 文件資訊 業務目的與範圍 業務背景與現況分析 利害關係人分析 業務需求 限制條件與假設 解決方案選項評估 驗收標準 風險評估 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 BRD-{專案代碼}-{序號} 文件名稱 {系統/專案名稱} 業務需求文件 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 核定 建立日期 {YYYY-MM-DD} 最後更新 {YYYY-MM-DD} 撰寫者 {姓名/角色} 審核者 {姓名/角色} 核定者 {姓名/角色} 版本歷程 版本 日期 修改人 修改內容摘要 v0.1 {YYYY-MM-DD} {姓名} 初稿建立 v1.0 {YYYY-MM-DD} {姓名} 正式發布 📖 使用說明 文件編號：採用組織標準編碼規則，確保唯一性與可追溯性 狀態管理：遵循 Draft → Under Review → Approved 的生命週期 版本歷程：每次修改必須記錄，符合 ISO/IEC/IEEE 29148 的組態管理要求 文件核定後進入基線管理（Baseline），後續修改需走變更控制流程 💡 範例 項目 內容 文件編號 BRD-ERP-001 文件名稱 人力資源管理系統 業務需求文件 版本 v1.2 狀態 核定 建立日期 2026-03-01 最後更新 2026-04-15 撰寫者 王小明 / 業務分析師 審核者 李主管 / 人資部經理 核定者 張總監 / IT 總監 2. 業務目的與範圍 📝 範本 2.1 業務目的（Business Purpose） {描述為什麼需要這個專案/系統，要解決什麼業務問題} ...

FRD 功能需求文件範本（Functional Requirements Document） 參照標準：ISO/IEC/IEEE 29148:2018（取代 IEEE 830-1998） 文件用途：將業務需求轉化為系統可實作的功能性與非功能性需求規格 適用階段：需求分析階段（Requirements Analysis Phase） 📋 章節目錄 文件資訊 導言 整體描述 系統功能需求 外部介面需求 非功能性需求 資料需求 其他需求 需求追溯矩陣 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 FRD-{專案代碼}-{序號} 文件名稱 {系統名稱} 功能需求文件 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 核定 / 基線 建立日期 {YYYY-MM-DD} 最後更新 {YYYY-MM-DD} 撰寫者 {姓名/角色} 審核者 {姓名/角色} 核定者 {姓名/角色} 對應 BRD {BRD 文件編號} 版本歷程 版本 日期 修改人 修改內容摘要 v0.1 {YYYY-MM-DD} {姓名} 初稿建立 📖 使用說明 FRD 承接 BRD（業務需求文件），將業務需求細化為系統功能規格 對應 BRD 欄位用於建立文件間的追溯關係 狀態增加「基線」代表已納入組態管理，後續變更需走 Change Request 流程 💡 範例 項目 內容 文件編號 FRD-HRM-001 文件名稱 人力資源管理系統 功能需求文件 版本 v2.1 狀態 基線 對應 BRD BRD-ERP-001 v1.2 2. 導言 📝 範本 2.1 目的（Purpose） 本文件定義 {系統名稱} 的功能性與非功能性需求規格，作為系統設計、開發與驗收測試的依據。 ...

README 範本（README Template） 參照標準：GitHub Community Standards / Open Source Guides / Make a README 文件用途：提供專案的入口文件，讓開發者快速了解、安裝、使用與貢獻專案 適用階段：專案全生命週期（建立即應存在，持續維護） 📋 章節目錄 文件資訊 專案名稱與描述 徽章區（Badges） 快速開始 安裝指南 使用方式 API 參考 專案結構 貢獻指南 授權條款 附錄 1. 文件資訊 📝 範本 項目 內容 文件名稱 README.md 位置 專案根目錄 格式 GitHub Flavored Markdown (GFM) 維護者 {姓名/團隊} 最後更新 {YYYY-MM-DD} 📖 使用說明 README.md 是專案的「門面」，通常是訪客看到的第一份文件 遵循 GitHub Community Standards 建議結構 內容需保持最新，過時的 README 比沒有 README 更糟 💡 範例 本範本以 HRMS 專案為例，展示完整 README 結構。 ...

SAD 系統架構文件範本（System Architecture Document） 參照標準：ISO/IEC/IEEE 42010:2022（取代 IEEE 1471-2000） 文件用途：描述系統架構決策、觀點、視圖與品質屬性，作為開發團隊的設計藍圖 適用階段：系統設計階段（System Design Phase） 📋 章節目錄 文件資訊 架構概述 架構利害關係人與關注點 架構觀點定義 邏輯視圖 開發視圖 部署視圖 流程視圖 資料架構視圖 架構決策記錄 品質屬性與戰術 安全架構 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 SAD-{專案代碼}-{序號} 文件名稱 {系統名稱} 系統架構文件 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 核定 建立日期 {YYYY-MM-DD} 最後更新 {YYYY-MM-DD} 架構師 {姓名} 審核者 {姓名/角色} 對應 FRD {FRD 文件編號} 版本歷程 版本 日期 修改人 修改內容摘要 v0.1 {YYYY-MM-DD} {姓名} 初版架構設計 📖 使用說明 依據 ISO/IEC/IEEE 42010:2022 第 5.1 節，架構描述應包含識別資訊 SAD 承接 FRD，將功能需求與非功能需求轉化為架構設計方案 架構文件是「活文件」（Living Document），隨設計演進持續更新 💡 範例 項目 內容 文件編號 SAD-HRM-001 文件名稱 人力資源管理系統 系統架構文件 版本 v1.3 架構師 陳建築 對應 FRD FRD-HRM-001 v2.1 2. 架構概述 📝 範本 2.1 系統背景（System Context） {描述系統在組織 IT 環境中的定位} ...

事件報告與根因分析範本（Incident Report & Root Cause Analysis） 參照標準：ITIL 4（Incident Management & Problem Management）/ ISO/IEC 20000-1:2018 / SRE Postmortem 文件用途：記錄生產環境事件、分析根本原因、制定改善行動，防止問題再次發生 適用階段：維運監控階段（Operations Phase）— Continuous Improvement 📋 章節目錄 事件摘要 時間軸 影響評估 根因分析 解決方案 改善行動計畫 經驗教訓 附錄 1. 事件摘要 📝 範本 項目 內容 事件編號 INC-{YYYYMMDD}-{序號} 事件標題 {一句話描述事件} 嚴重等級 SEV1（Critical）/ SEV2（Major）/ SEV3（Minor）/ SEV4（Low） 事件狀態 調查中 / 已解決 / 已關閉 發生時間 {YYYY-MM-DD HH:MM} (UTC+8) 偵測時間 {YYYY-MM-DD HH:MM} 解決時間 {YYYY-MM-DD HH:MM} 事件持續時間 {N} 分鐘/小時 MTTD {偵測時間 - 發生時間} MTTR {解決時間 - 偵測時間} 受影響系統 {系統/服務名稱} 受影響使用者 {人數/比例} 事件負責人 {Incident Commander} 報告撰寫者 {姓名} 報告日期 {YYYY-MM-DD} 📖 使用說明 嚴重等級定義： SEV1：核心業務完全中斷，影響全部使用者 SEV2：核心功能嚴重降級，影響大部分使用者 SEV3：非核心功能異常，影響部分使用者 SEV4：輕微異常，幾乎不影響使用者 MTTD（Mean Time To Detect）：衡量監控能力 MTTR（Mean Time To Resolve）：衡量恢復能力 事件報告需在事件解決後 3-5 個工作日 內完成 Blameless 原則：報告聚焦系統與流程改善，不歸咎個人 💡 範例 項目 內容 事件編號 INC-20260520-001 事件標題 HRMS 薪資查詢 API 持續回傳 500 Error 嚴重等級 SEV2（核心功能嚴重降級） 發生時間 2026-05-20 10:15 偵測時間 2026-05-20 10:18（Grafana 告警） 解決時間 2026-05-20 10:28（回滾完成） 事件持續時間 13 分鐘 MTTD 3 分鐘 MTTR 10 分鐘 受影響使用者 ~200 人（薪資查詢功能不可用） 事件負責人 張 SRE 2. 時間軸 📝 範本 時間 (UTC+8) 事件 執行者 備註 {HH:MM} {發生/偵測/行動/解決} {人員} {補充說明} 📖 使用說明 時間軸是事件報告最有價值的部分，需精確到分鐘 涵蓋：事件發生 → 偵測 → 通知 → 診斷 → 緩解 → 解決 → 驗證 資料來源：監控日誌、Slack 訊息時間戳、告警記錄 時間軸讓團隊復盤流程效率，找出可改善的環節 💡 範例 時間 (UTC+8) 事件 執行者 備註 10:12 v2.1.0 部署完成，新版上線 DevOps 林 K8s Green deployment 完成 10:15 薪資計算排程 CronJob 啟動（與 API 衝突） System 排程被新設定觸發 10:15 DB Lock 衝突開始，API 回應逾時 System PostgreSQL row-level lock 10:18 Grafana 告警：5xx rate > 5% Alert System #hrms-alerts 頻道 10:19 SRE 張確認告警，開始調查 SRE 張 檢查 Pod 日誌 10:21 確認問題：DB Lock contention SRE 張 pg_stat_activity 發現 lock wait 10:23 聯繫 Tech Lead 決策：啟動回滾 SRE 張 → Tech Lead 王 Slack 通訊 10:24 Tech Lead 確認回滾，授權執行 Tech Lead 王 10:25 開始執行回滾腳本 SRE 張 ./rollback-hrms-v2.1.0.sh 10:27 流量切換至 v2.0.3 完成 SRE 張 Blue deployment 10:28 健康檢查通過，冒煙測試通過 SRE 張 + QA 陳 服務恢復 10:30 通知團隊：服務已恢復 SRE 張 Slack + Email 10:45 通知受影響使用者：服務已恢復 PM 林 系統公告 3. 影響評估 📝 範本 3.1 業務影響 影響維度 評估 受影響功能 {功能清單} 受影響使用者數 {人數/比例} 收入損失 {金額/無法計量} 資料損失 {是/否，描述} SLA 違反 {是/否，影響 SLA 指標} 信譽影響 {高/中/低} 3.2 技術影響 影響維度 評估 受影響服務 {服務清單} 相依服務影響 {是否連鎖影響} 資料一致性 {是否受影響} 安全性影響 {是否有安全疑慮} 📖 使用說明 影響評估用於確認嚴重等級是否正確、作為改善優先級依據 業務影響由 PM/產品團隊提供；技術影響由工程團隊評估 SLA 違反需記錄，可能涉及客戶賠償或內部 KPI 💡 範例 3.1 業務影響 影響維度 評估 受影響功能 薪資查詢、薪資條下載 受影響使用者數 ~200 人（嘗試查詢薪資的員工） 收入損失 無直接收入損失（內部系統） 資料損失 無 SLA 違反 否（SLA 99.5% 月度，本月仍在 SLA 內） 信譽影響 低（事件持續 13 分鐘，非上班尖峰） 4. 根因分析 📝 範本 4.1 根本原因 Root Cause Statement： ...