範本

程式規格書（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 環境中的定位} ...

UX/UI 畫面設計規格範本（UI Specification Template） 適用標準：ISO 9241-210:2019（Human-centred Design）、WCAG 2.2（Web Content Accessibility Guidelines） 適用階段：系統設計階段（Design Phase） 負責角色：UX 設計師、UI 設計師、前端工程師 📑 章節目錄 文件資訊 設計原則與規範 資訊架構（Information Architecture） 畫面流程（UI Flow） 畫面規格（Screen Specification） 元件規格（Component Specification） 響應式設計規格 無障礙設計（Accessibility） 互動規格（Interaction Specification） 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] UI 設計規格書 文件編號 [專案代碼]-UIS-[版本號] 版本 v[X.Y] 建立日期 [YYYY-MM-DD] 最後更新 [YYYY-MM-DD] 撰寫者 [UX/UI 設計師] 審核者 [Product Owner / Tech Lead] 設計工具與資源 項目 工具/位置 Design Tool [Figma / Sketch / Adobe XD] Design File URL [連結] Prototype URL [互動原型連結] Design System [設計系統/元件庫名稱與連結] Icon Library [圖標庫名稱] 2. 設計原則與規範 2.1 設計原則 原則 說明 [一致性] [描述此專案的一致性準則] [簡潔性] [描述簡潔設計方針] [可及性] [無障礙設計目標] [效率] [使用者操作效率目標] 2.2 Design Token / 設計變數 Token 名稱 值 用途 color-primary [#XXXXXX] 主要品牌色 color-secondary [#XXXXXX] 次要色 color-error [#XXXXXX] 錯誤提示 color-success [#XXXXXX] 成功提示 font-family [字型名稱] 主要字型 font-size-base [N]px 基準字級 spacing-unit [N]px 間距基準單位 border-radius [N]px 圓角 2.3 排版規範（Typography） 層級 用途 字級 字重 行高 H1 頁面標題 [N]px [Bold] [N] H2 區塊標題 [N]px [Semi-Bold] [N] H3 子區塊標題 [N]px [Medium] [N] Body 內文 [N]px [Regular] [N] Caption 說明文字 [N]px [Regular] [N] 3. 資訊架構（Information Architecture） 3.1 導航結構（Sitemap） [系統名稱] ├── 首頁 Dashboard ├── 模組 A │ ├── 功能 A-1 │ ├── 功能 A-2 │ └── 功能 A-3 ├── 模組 B │ ├── 功能 B-1 │ └── 功能 B-2 ├── 系統設定 │ ├── 個人設定 │ └── 管理設定（Admin only） └── 說明 / Help 3.2 角色與功能對應 角色 可見模組 可執行操作 [角色 A] [模組清單] [CRUD 權限] [角色 B] [模組清單] [CRUD 權限] 4. 畫面流程（UI Flow） graph TD A[進入點/登入] --> B{角色判斷} B -->|角色A| C[Dashboard A] B -->|角色B| D[Dashboard B] C --> E[功能頁 1] E --> F[表單填寫] F --> G{驗證} G -->|成功| H[成功回饋] G -->|失敗| I[錯誤提示] --> F 5. 畫面規格（Screen Specification） Screen-[NNN]: [畫面名稱] 項目 內容 畫面 ID SCR-[NNN] 畫面名稱 [中英文名稱] URL Path [/path/to/page] 對應 Use Case UC-[NNN] 角色權限 [可存取的角色] 進入條件 [如何到達此頁面] 畫面佈局（Layout）： ...