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 涵蓋的模組或功能範圍，以及與其他模組的邊界。 ...

版本：2.0 最後更新：2026 年 5 月 19 日 適用對象：後端工程師、前端工程師、QA 工程師、系統架構師、DevOps 工程師 定位：企業內部標準教材 文件維護：內部技術團隊 適用於：Postman v12.x（2026 年最新穩定版，向下相容 v11.x） Created by：Eric Cheng Postman 教學手冊 📋 教學大綱 Postman 簡介與概觀 1.1 Postman 是什麼？ 1.2 核心功能總覽 1.3 Postman 平台架構 1.4 版本與授權方案 1.5 與同類工具比較 1.6 適用場景與不適用場景 安裝與環境設定 2.1 桌面應用程式安裝 2.2 網頁版與 VS Code Extension 2.3 帳號註冊與登入 2.4 介面導覽 2.5 企業網路設定（Proxy / SSL） 2.6 團隊初始化設定 核心概念 3.1 Workspaces（工作區） 3.2 Collections（集合） 3.3 Environments 與 Variables 3.4 Authorization（認證與授權） 3.5 Postman Console 發送 API 請求 4.1 建立與發送 HTTP 請求 4.2 Request Body 格式 4.3 Response 檢視與分析 4.4 GraphQL 請求 4.5 gRPC 與 WebSocket 4.6 Cookie 與 Certificate 管理 變數與環境管理 5.1 變數作用域與優先順序 5.2 動態變數 5.3 環境切換策略 5.4 Postman Vault（敏感資料管理） 5.5 資料檔案驅動（CSV / JSON） 腳本開發（Tests & Scripts） 6.1 Pre-request Script 6.2 Post-response Script（測試斷言） 6.3 pm API 完整參考 6.4 Chai Assertion Library 6.5 請求鏈結（Chaining Requests） 6.6 常見測試範例 6.7 可重用腳本（Package Library） Collection Runner 與自動化測試 7.1 Collection Runner 使用 7.2 執行順序控制 7.3 Data-Driven Testing 7.4 效能測試 7.5 整合測試與回歸測試 Postman CLI 與 CI/CD 整合 8.1 Postman CLI 安裝與設定 8.2 命令列執行 Collection 8.3 Newman（傳統 CLI） 8.4 GitHub Actions 整合 8.5 Jenkins / Azure DevOps 整合 API 設計與文件 9.1 Spec Hub（OpenAPI / AsyncAPI） 9.2 Mock Server 設定 9.3 API 文件產生與發布 9.4 版本管理與 Native Git 9.5 SDK Generation（SDK 產生） 9.6 API Catalog（Enterprise） Postman Flows 10.1 Flows 概念與用途 10.2 建立視覺化工作流 10.3 實務案例 AI 功能（Agent Mode） 11.1 Postman AI 功能總覽 11.2 Agent Mode 深度指南 11.3 MCP Server 與 MCP Client 整合 11.4 AI Credits 管理與最佳化 團隊協作 12.1 團隊建立與管理 12.2 角色與權限 12.3 Version Control（Fork / Pull Request / Merge） 12.4 團隊工作區最佳實務 安全治理與 API Governance 13.1 Postman Secret Scanner 13.2 Postman Vault 與第三方整合 13.3 API Governance Rules 13.4 SSO / SCIM / Audit Log 13.5 BYOK 與 Data Residency 監控與效能 14.1 Monitor 設定與排程 14.2 效能指標與告警 14.3 Insights（Enterprise） 整合與擴充 15.1 第三方工具整合 15.2 Postman API 使用 15.3 Webhook 與自訂整合 企業導入策略 16.1 評估與導入路線圖 16.2 方案選擇與團隊培訓 16.3 標準化規範 最佳實務與反模式 17.1 最佳實務 17.2 常見反模式 常見問題與除錯（FAQ） 附錄 19.1 pm API 速查表 19.2 Chai Assertion 速查表 19.3 HTTP Status Code 速查表 19.4 快捷鍵速查表 19.5 新人上手 Checklist 19.6 API 測試 Checklist 19.7 安全性 Checklist 1. Postman 簡介與概觀 1.1 Postman 是什麼？ Postman 是全球領先的 AI 原生 API 平台，為超過 4,000 萬開發者與 50 萬以上的組織提供 API 開發、測試、文件化、監控與協作的統一解決方案。Fortune 500 企業中有 98% 使用 Postman 作為其 API 開發流程的核心工具。根據 2025 年 State of the API 報告，90% 的開發者正在使用 API，74% 已採用 API-First 策略，而 AI 驅動的 API 流量在 2024 年增長了 73%。 ...

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）： ...