需求分析

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 產品願景 簡述本產品/功能的願景，說明為何需要此產品，以及期望達成的長期目標。 ...

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） 本文件定義 {系統名稱} 的功能性與非功能性需求規格，作為系統設計、開發與驗收測試的依據。 ...

使用案例文件範本（Use Case Document Template） 適用標準：ISO/IEC/IEEE 29148:2018、UML 2.5.1（Unified Modeling Language） 適用階段：需求分析階段（Requirements Phase） 負責角色：系統分析師（SA）、業務分析師（BA） 📑 章節目錄 文件資訊 系統範圍與參與者 使用案例圖（Use Case Diagram） 使用案例清單 使用案例規格（逐案詳述） 業務規則 非功能性需求對應 追溯矩陣 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 使用案例文件 文件編號 [專案代碼]-UCD-[版本號] 版本 v[X.Y] 建立日期 [YYYY-MM-DD] 最後更新 [YYYY-MM-DD] 撰寫者 [BA/SA 姓名] 審核者 [技術主管 / 業務主管] 版本歷程 版本 日期 修改人 修改內容 v1.0 [YYYY-MM-DD] [姓名] 初版發布 2. 系統範圍與參與者 2.1 系統邊界 項目 說明 系統名稱 [系統全名] 系統目的 [一句話描述系統核心價值] 系統範圍 [包含/不包含的功能範疇] 2.2 參與者（Actors）清單 參與者 ID 名稱 類型 說明 相關角色/系統 ACT-001 [名稱] [人/系統/時間] [簡述] [實際角色] ACT-002 [名稱] [人/系統/時間] [簡述] [實際角色] 3. 使用案例圖（Use Case Diagram） graph LR subgraph "System Boundary: [系統名稱]" UC1([UC-001: 使用案例名稱]) UC2([UC-002: 使用案例名稱]) UC3([UC-003: 使用案例名稱]) end Actor1[/Actor 1\] --> UC1 Actor1 --> UC2 Actor2[/Actor 2\] --> UC2 Actor2 --> UC3 UC2 -.->|include| UC1 UC3 -.->|extend| UC2 4. 使用案例清單 UC ID 使用案例名稱 主要參與者 優先級 複雜度 狀態 UC-001 [名稱] [Actor] [High/Medium/Low] [High/Medium/Low] [Draft/Review/Approved] UC-002 [名稱] [Actor] [High/Medium/Low] [High/Medium/Low] [Draft/Review/Approved] 5. 使用案例規格（逐案詳述） UC-[NNN]: [使用案例名稱] 項目 內容 Use Case ID UC-[NNN] 名稱 [使用案例名稱] 簡述 [一句話描述目的] 主要參與者 [Primary Actor] 次要參與者 [Secondary Actors，若無填 N/A] 觸發條件 [什麼事件啟動此使用案例] 前置條件 [執行前必須滿足的條件] 後置條件（成功） [成功完成後系統/資料狀態] 後置條件（失敗） [失敗時系統/資料狀態] 優先級 [High / Medium / Low] 頻率 [每日 N 次 / 每週 N 次] 主要流程（Main Flow）： ...

安全需求清單範本（Security Requirements Checklist） 參照標準：OWASP ASVS 4.0.3（Application Security Verification Standard）/ ISO/IEC 27001:2022 Annex A 文件用途：定義系統應滿足的安全需求，確保設計與開發階段納入安全考量 適用階段：需求分析階段（Requirements Phase）— Security by Design 📋 章節目錄 文件資訊 安全需求概述 認證需求 授權與存取控制 資料保護需求 輸入驗證與輸出編碼 Session 管理 日誌與監控需求 通訊安全 組態安全 合規性需求 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 SR-{專案代碼}-{序號} 文件名稱 {系統名稱} 安全需求清單 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 核定 建立日期 {YYYY-MM-DD} 撰寫者 {姓名/角色} 資安審核者 {資安人員姓名} ASVS Level Level 1 / Level 2 / Level 3 📖 使用說明 依據 OWASP ASVS 4.0.3 標準，安全需求分為三個驗證等級： Level 1：所有應用程式的最低標準 Level 2：處理敏感資料的應用程式 Level 3：最高安全等級（金融、醫療、關鍵基礎設施） 本清單在需求階段制定，貫穿整個 SDLC（設計需遵循、開發需實作、測試需驗證） 💡 範例 項目 內容 文件編號 SR-HRM-001 系統名稱 人力資源管理系統 ASVS Level Level 2（處理員工個資與薪資資料） 2. 安全需求概述 📝 範本 2.1 系統安全分類 項目 評估 資料敏感度 一般 / 敏感 / 高度敏感 系統曝露面 內部 / 外部 / 混合 使用者類型 內部員工 / 外部客戶 / 合作夥伴 法規要求 {適用法規} 安全等級 ASVS Level {1/2/3} 2.2 安全需求追溯矩陣 安全需求 ID 需求描述 ASVS 章節 對應 FRD 優先級 SEC-{xxx} {描述} V{x}.{x} FR-{xxx} 高/中/低 📖 使用說明 安全分類決定應套用的 ASVS Level 追溯矩陣確保每個安全需求可連結到 FRD 需求與 ASVS 標準章節 優先級考量：法規強制 > 高風險 > 一般防護 💡 範例 2.1 系統安全分類 項目 評估 資料敏感度 高度敏感（身分證字號、薪資、銀行帳號） 系統曝露面 混合（內部網路 + VPN 遠端存取） 使用者類型 內部員工（全體） + HR 管理人員 法規要求 個人資料保護法、勞動基準法 安全等級 ASVS Level 2 3. 認證需求（Authentication） 📝 範本 需求 ID 需求描述 ASVS 參照 Level 必須/建議 實作狀態 SEC-AUTH-001 {認證需求描述} V2.{x} L{N} 必須/建議 ☐ SEC-AUTH-002 {認證需求描述} V2.{x} L{N} 必須/建議 ☐ 📖 使用說明 對應 OWASP ASVS V2（Authentication）章節 Level 1：基本密碼安全；Level 2：多因子認證（MFA）；Level 3：硬體認證 認證需求需涵蓋：密碼策略、帳號鎖定、MFA、SSO 💡 範例 需求 ID 需求描述 ASVS 參照 Level 必須/建議 實作狀態 SEC-AUTH-001 密碼長度至少 12 字元 V2.1.1 L1 必須 ☑ SEC-AUTH-002 帳號連續 5 次登入失敗後鎖定 30 分鐘 V2.2.1 L1 必須 ☑ SEC-AUTH-003 管理員帳號啟用多因子認證（MFA） V2.8.1 L2 必須 ☑ SEC-AUTH-004 整合企業 AD 實現 SSO 登入 V2.7.1 L2 必須 ☑ SEC-AUTH-005 密碼不儲存明文，使用 bcrypt/Argon2 雜湊 V2.4.1 L1 必須 ☑ SEC-AUTH-006 Token 過期時間 ≤ 15 分鐘（Access Token） V2.8.5 L2 必須 ☐ 4. 授權與存取控制（Authorization） 📝 範本 需求 ID 需求描述 ASVS 參照 Level 必須/建議 實作狀態 SEC-AUTHZ-001 {授權需求描述} V4.{x} L{N} 必須/建議 ☐ 📖 使用說明 對應 OWASP ASVS V4（Access Control）章節 遵循最小權限原則（Principle of Least Privilege） 需求涵蓋：RBAC/ABAC 模型、水平/垂直權限控制、API 授權 💡 範例 需求 ID 需求描述 ASVS 參照 Level 必須/建議 實作狀態 SEC-AUTHZ-001 實施 RBAC 角色權限控制（Admin/Manager/Employee） V4.1.1 L1 必須 ☑ SEC-AUTHZ-002 使用者僅能存取自己的薪資/假勤資料（水平權限） V4.1.2 L1 必須 ☑ SEC-AUTHZ-003 API 端點實施授權檢查，拒絕未授權請求回傳 403 V4.1.3 L1 必須 ☑ SEC-AUTHZ-004 管理功能（帳號管理、系統設定）限 Admin 角色 V4.2.1 L1 必須 ☑ SEC-AUTHZ-005 所有權限變更需記錄稽核日誌 V4.3.1 L2 必須 ☐ 5. 資料保護需求（Data Protection） 📝 範本 需求 ID 需求描述 ASVS 參照 Level 必須/建議 實作狀態 SEC-DATA-001 {資料保護需求描述} V6.{x}/V8.{x} L{N} 必須/建議 ☐ 敏感資料識別 資料欄位 敏感等級 加密方式 遮罩方式 保留期限 {欄位} 高/中/低 {加密} {遮罩} {期限} 📖 使用說明 對應 OWASP ASVS V6（Stored Cryptography）與 V8（Data Protection） 敏感資料需先識別、再定義保護策略 保護措施包含：傳輸加密、靜態加密、資料遮罩、存取控制、保留/銷毀策略 💡 範例 敏感資料識別 資料欄位 敏感等級 加密方式 遮罩方式 保留期限 身分證字號 高 AES-256 (靜態) A1234****9 離職後 5 年 銀行帳號 高 AES-256 (靜態) --1234 離職後 5 年 薪資金額 高 AES-256 (靜態) 不遮罩（權限控制） 永久 手機號碼 中 無（權限控制） 09xx-xxx-789 離職後 2 年 Email 低 無 無 離職後 2 年 需求 ID 需求描述 ASVS 參照 Level 必須/建議 SEC-DATA-001 個資欄位靜態加密儲存（AES-256） V6.2.1 L2 必須 SEC-DATA-002 所有傳輸使用 TLS 1.2+ V9.1.1 L1 必須 SEC-DATA-003 日誌中禁止記錄敏感資料明文 V8.3.1 L1 必須 SEC-DATA-004 資料庫備份亦需加密 V6.2.3 L2 必須 6. 輸入驗證與輸出編碼 📝 範本 需求 ID 需求描述 ASVS 參照 Level 必須/建議 實作狀態 SEC-INPUT-001 {輸入驗證需求} V5.{x} L{N} 必須/建議 ☐ 📖 使用說明 對應 OWASP ASVS V5（Validation, Sanitization and Encoding） 防禦 OWASP Top 10 中的注入攻擊（SQL Injection、XSS、Command Injection） 原則：永不信任使用者輸入，伺服器端必須驗證 💡 範例 需求 ID 需求描述 ASVS 參照 Level 必須/建議 SEC-INPUT-001 所有使用者輸入在伺服器端進行驗證（白名單） V5.1.1 L1 必須 SEC-INPUT-002 使用參數化查詢防止 SQL Injection V5.3.4 L1 必須 SEC-INPUT-003 HTML 輸出使用 Context-Aware 編碼防止 XSS V5.3.3 L1 必須 SEC-INPUT-004 檔案上傳驗證副檔名、MIME Type、大小限制 V5.1.4 L1 必須 SEC-INPUT-005 API 輸入限制 Content-Length，防止 DoS V5.1.5 L1 必須 7. Session 管理 📝 範本 需求 ID 需求描述 ASVS 參照 Level 必須/建議 實作狀態 SEC-SESS-001 {Session 管理需求} V3.{x} L{N} 必須/建議 ☐ 📖 使用說明 對應 OWASP ASVS V3（Session Management） Session 管理攸關身份劫持風險 需求涵蓋：Session ID 強度、過期設定、Cookie 安全屬性 💡 範例 需求 ID 需求描述 ASVS 參照 Level 必須/建議 SEC-SESS-001 Session ID 長度 ≥ 128 bits，由加密安全亂數產生 V3.2.1 L1 必須 SEC-SESS-002 Cookie 設定 HttpOnly、Secure、SameSite=Strict V3.4.1 L1 必須 SEC-SESS-003 閒置 30 分鐘後自動登出 V3.3.1 L1 必須 SEC-SESS-004 登入後重新產生 Session ID（防 Fixation） V3.2.3 L1 必須 SEC-SESS-005 支援使用者查看與終止其他裝置 Session V3.3.4 L2 建議 8. 日誌與監控需求 📝 範本 需求 ID 需求描述 ASVS 參照 Level 必須/建議 實作狀態 SEC-LOG-001 {日誌監控需求} V7.{x} L{N} 必須/建議 ☐ 稽核事件定義 事件類型 記錄內容 保留期限 {事件} {需記錄的欄位} {期限} 📖 使用說明 對應 OWASP ASVS V7（Error Handling and Logging） 日誌是事後追查與即時偵測的基礎 重點：記什麼、不記什麼（禁止記錄密碼/Token）、保存多久 💡 範例 需求 ID 需求描述 ASVS 參照 Level 必須/建議 SEC-LOG-001 記錄所有認證事件（登入成功/失敗/登出） V7.1.1 L1 必須 SEC-LOG-002 記錄所有授權失敗事件 V7.1.2 L1 必須 SEC-LOG-003 日誌中禁止包含 Session Token、密碼、個資 V7.1.3 L1 必須 SEC-LOG-004 日誌保留 ≥ 90 天，不可竄改 V7.3.1 L2 必須 SEC-LOG-005 連續 5 次認證失敗觸發即時告警 V7.4.1 L2 必須 稽核事件定義 事件類型 記錄內容 保留期限 登入成功 時間、帳號、IP、User-Agent 180 天 登入失敗 時間、帳號、IP、失敗原因 180 天 權限變更 時間、操作者、變更內容 365 天 個資存取 時間、帳號、存取的個資類型 365 天 資料匯出 時間、帳號、匯出範圍、筆數 365 天 9. 通訊安全 📝 範本 需求 ID 需求描述 ASVS 參照 Level 必須/建議 實作狀態 SEC-COMM-001 {通訊安全需求} V9.{x} L{N} 必須/建議 ☐ 📖 使用說明 對應 OWASP ASVS V9（Communication） 保護傳輸中資料不被竊聽或竄改 涵蓋：TLS 版本、憑證管理、HSTS、內部通訊加密 💡 範例 需求 ID 需求描述 ASVS 參照 Level 必須/建議 SEC-COMM-001 所有外部通訊使用 TLS 1.2 以上 V9.1.1 L1 必須 SEC-COMM-002 啟用 HSTS（max-age ≥ 1 年） V9.1.2 L1 必須 SEC-COMM-003 伺服器憑證由受信任 CA 簽發 V9.2.1 L1 必須 SEC-COMM-004 服務間（微服務）通訊使用 mTLS V9.2.2 L2 建議 SEC-COMM-005 禁用 SSL 3.0、TLS 1.0/1.1 V9.1.3 L1 必須 10. 組態安全 📝 範本 需求 ID 需求描述 ASVS 參照 Level 必須/建議 實作狀態 SEC-CFG-001 {組態安全需求} V14.{x} L{N} 必須/建議 ☐ 📖 使用說明 對應 OWASP ASVS V14（Configuration） 安全組態確保系統不因錯誤設定而暴露弱點 涵蓋：預設帳號、除錯模式、HTTP 安全標頭、依賴管理 💡 範例 需求 ID 需求描述 ASVS 參照 Level 必須/建議 SEC-CFG-001 正式環境禁止開啟除錯模式 / 詳細錯誤訊息 V14.1.1 L1 必須 SEC-CFG-002 移除或停用所有預設帳號與密碼 V14.1.2 L1 必須 SEC-CFG-003 設定安全 HTTP Headers（CSP, X-Frame-Options 等） V14.4.1 L1 必須 SEC-CFG-004 第三方依賴無已知 High/Critical CVE V14.2.1 L1 必須 SEC-CFG-005 機敏設定（DB 連線字串、API Key）使用 Secret Manager V14.1.5 L2 必須 11. 合規性需求 📝 範本 法規/標準 適用條款 系統需求對應 實作狀態 {法規名稱} {條款} {系統需滿足的具體需求} ☐ 📖 使用說明 列出系統需遵循的法規、產業標準、企業政策 每條法規要求需轉化為可驗證的技術需求 常見法規：個人資料保護法、GDPR、PCI DSS、ISO 27001 💡 範例 法規/標準 適用條款 系統需求對應 實作狀態 個人資料保護法 第 27 條（安全維護措施） 個資加密儲存、存取控制、稽核日誌 ☑ 個人資料保護法 第 11 條（當事人權利） 提供個資查詢、更正、刪除功能 ☑ ISO 27001:2022 A.8.3（存取控制） RBAC 實作 ☑ ISO 27001:2022 A.8.24（密碼學使用） TLS 1.2+、AES-256 加密 ☑ 公司資安政策 密碼政策 v3.0 12 字元 + 複雜度 + 90 天更換 ☐ 12. 附錄 📝 範本 12.1 安全需求完成度統計 類別 總需求數 已實作 未實作 完成率 認證（AUTH） {N} {N} {N} {%} 授權（AUTHZ） {N} {N} {N} {%} 資料保護（DATA） {N} {N} {N} {%} 輸入驗證（INPUT） {N} {N} {N} {%} Session（SESS） {N} {N} {N} {%} 日誌監控（LOG） {N} {N} {N} {%} 通訊安全（COMM） {N} {N} {N} {%} 組態安全（CFG） {N} {N} {N} {%} 合計 {N} {N} {N} {%} 12.2 OWASP ASVS 對照表 ASVS 章節 主題 本文件對應章節 V2 Authentication 第 3 章 V3 Session Management 第 7 章 V4 Access Control 第 4 章 V5 Validation 第 6 章 V6 Stored Cryptography 第 5 章 V7 Error Handling & Logging 第 8 章 V8 Data Protection 第 5 章 V9 Communication 第 9 章 V14 Configuration 第 10 章 📖 使用說明 完成度統計用於追蹤安全需求落實進度 所有「必須」等級的需求需在上線前 100% 實作 ASVS 對照表協助資安審核人員快速定位驗證範圍 💡 範例 12.1 安全需求完成度統計 類別 總需求數 已實作 未實作 完成率 認證（AUTH） 6 5 1 83% 授權（AUTHZ） 5 4 1 80% 資料保護（DATA） 4 4 0 100% 輸入驗證（INPUT） 5 5 0 100% Session（SESS） 5 4 1 80% 日誌監控（LOG） 5 3 2 60% 通訊安全（COMM） 5 5 0 100% 組態安全（CFG） 5 4 1 80% 合計 40 34 6 85% 📌 範本使用注意事項 ...

系統需求規格書範本（System Requirements Document, SRD） 參照標準：ISO/IEC/IEEE 29148:2018（Systems and Software Engineering — Requirements Engineering） 文件用途：定義系統層級的完整需求（功能、效能、安全、介面），作為設計與驗證的基準 適用階段：需求分析階段（Requirements Phase）— System-Level Requirements 📋 章節目錄 文件資訊 系統概述 系統功能需求 系統介面需求 效能需求 安全需求摘要 可靠性與可用性 限制條件 需求追溯矩陣 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 SRD-{專案代碼}-{版本} 文件名稱 {系統名稱} 系統需求規格書 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 基線化 建立日期 {YYYY-MM-DD} 撰寫者 {系統分析師} 審核者 {Tech Lead / 架構師} 核准者 {PM / 產品負責人} 基線版本 {基線化日期，變更需走 CR 流程} 📖 使用說明 SRD 位於需求文件階層的中間層： BRD（商業需求）→ SRD（系統需求） → FRD（功能需求） SRD 將商業需求轉化為系統可實作的技術需求 「基線化」後的變更需經正式變更控制流程（Change Request） 依 ISO/IEC/IEEE 29148:2018 Section 6.2（System Requirements Specification） 💡 範例 項目 內容 文件編號 SRD-HRM-v1.0 系統名稱 人力資源管理系統（HRMS） 版本 v1.0 基線版本 2026-04-01（Sprint 10 結束） 2. 系統概述 📝 範本 2.1 系統目的 {描述系統存在的理由與欲解決的核心問題} ...

需求異動申請表範本（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 緊急程度 一般 範例：變更描述 變更標題： 新增「彈性工時」假別類型與計算邏輯 ...

BDD 行為驅動開發使用教學手冊 📘 手冊說明 本手冊專為系統分析師（SA）、業務分析師（BA）、開發人員與測試人員設計,旨在協助團隊成員: 理解 BDD 的核心概念與價值 掌握 Gherkin 語法與規格撰寫 學會將業務需求轉換為可執行的行為規格 建立 BDD 協作開發流程 實踐 BDD 自動化測試 適用對象: 新進系統分析師 想導入 BDD 的開發團隊 需要強化需求溝通的專案經理 負責驗收測試的 QA 人員 使用方式: 循序閱讀各章節,建立完整概念 參考實務案例,模擬實際場景 使用附錄的模板與檢查清單 在專案中逐步導入與實踐 📑 目錄 第一章　認識 BDD:行為驅動開發的核心理念 1.1 什麼是 BDD 1.2 BDD 與 TDD、ATDD 的差異 1.3 為什麼要導入 BDD 1.4 BDD 的價值與應用場景 1.5 BDD 在軟體開發生命週期(SDLC)中的位置 第二章　BDD 的三大支柱 2.1 Discovery(需求探索) 2.2 Formulation(範例定義) 2.3 Automation(自動化驗證) 第三章　BDD 的核心語法:Gherkin 3.1 Gherkin 語法結構與規則 3.2 Feature、Scenario、Scenario Outline 進階應用 3.3 範例:從需求敘述轉為 Gherkin 規格 3.4 常見錯誤與最佳實務 第四章　BDD 與系統分析的整合應用 4.1 如何將業務需求轉化為可執行行為 4.2 與利害關係人共創範例(Example Mapping) 4.3 User Story 與 BDD 的結合方式 4.4 Acceptance Criteria(驗收準則)的撰寫指引 4.5 從 BDD 到 Use Case 的對應關係 第五章　BDD 開發流程與角色分工 5.1 BDD 工作流(Workflow)全貌 5.2 三方會談(Three Amigos:BA/SA、Dev、QA) 5.3 SA 在 BDD 流程中的責任與產出 5.4 實務文件產出範例 5.5 維護與版本控管實務 第六章　BDD 自動化測試實作 6.1 常見 BDD 工具比較 6.2 環境安裝與專案結構 6.3 Feature 與 Step Definitions 的關聯 6.4 CI/CD 整合實務 6.5 測試報告與追蹤機制 第七章　BDD 實戰案例 7.1 案例一:Web 登入驗證流程 7.2 案例二:銀行轉帳業務流程 7.3 案例三:批次系統業務規則驗證 7.4 案例四:API 行為測試 7.5 案例回顧與行為重構 第八章　導入策略與組織落地 8.1 組織 BDD 成熟度評估 8.2 BDD 導入計畫範本 8.3 克服導入 BDD 的常見障礙 8.4 建立 BDD 協作文化 8.5 成功導入的關鍵因素 第九章　高階應用與延伸 9.1 AI 輔助 BDD 實踐 9.2 BDD 與 Specification by Example (SBE) 整合 9.3 微服務架構下的 BDD 挑戰 9.4 BDD 的未來趨勢 第十章　附錄 10.1 Gherkin 語法速查表 10.2 BDD 文件模板 10.3 常見 BDD 工具與插件 10.4 推薦學習資源 10.5 BDD 完整檢查清單 第一章　認識 BDD:行為驅動開發的核心理念 1.1 什麼是 BDD BDD (Behavior-Driven Development,行為驅動開發) 是一種軟體開發方法論,強調: ...

BDD 行為驅動開發使用教學手冊 📘 手冊說明 本手冊專為系統分析師（SA）、業務分析師（BA）、開發人員與測試人員設計,旨在協助團隊成員: 理解 BDD 的核心概念與價值 掌握 Gherkin 語法與規格撰寫 學會將業務需求轉換為可執行的行為規格 建立 BDD 協作開發流程 實踐 BDD 自動化測試 適用對象: 新進系統分析師 想導入 BDD 的開發團隊 需要強化需求溝通的專案經理 負責驗收測試的 QA 人員 使用方式: 循序閱讀各章節,建立完整概念 參考實務案例,模擬實際場景 使用附錄的模板與檢查清單 在專案中逐步導入與實踐 📑 目錄 第一章　認識 BDD:行為驅動開發的核心理念 1.1 什麼是 BDD 1.2 BDD 與 TDD、ATDD 的差異 1.3 為什麼要導入 BDD 1.4 BDD 的價值與應用場景 1.5 BDD 在軟體開發生命週期(SDLC)中的位置 第二章　BDD 的三大支柱 2.1 Discovery(需求探索) 2.2 Formulation(範例定義) 2.3 Automation(自動化驗證) 第三章　BDD 的核心語法:Gherkin 3.1 Gherkin 語法結構與規則 3.2 Feature、Scenario、Scenario Outline 進階應用 3.3 範例:從需求敘述轉為 Gherkin 規格 3.4 常見錯誤與最佳實務 第四章　BDD 與系統分析的整合應用 4.1 如何將業務需求轉化為可執行行為 4.2 與利害關係人共創範例(Example Mapping) 4.3 User Story 與 BDD 的結合方式 4.4 Acceptance Criteria(驗收準則)的撰寫指引 4.5 從 BDD 到 Use Case 的對應關係 第五章　BDD 開發流程與角色分工 5.1 BDD 工作流(Workflow)全貌 5.2 三方會談(Three Amigos:BA/SA、Dev、QA) 5.3 SA 在 BDD 流程中的責任與產出 5.4 實務文件產出範例 5.5 維護與版本控管實務 第六章　BDD 自動化測試實作 6.1 常見 BDD 工具比較 6.2 環境安裝與專案結構 6.3 Feature 與 Step Definitions 的關聯 6.4 CI/CD 整合實務 6.5 測試報告與追蹤機制 第七章　BDD 實戰案例 7.1 案例一:Web 登入驗證流程 7.2 案例二:銀行轉帳業務流程 7.3 案例三:批次系統業務規則驗證 7.4 案例四:API 行為測試 7.5 案例回顧與行為重構 第八章　導入策略與組織落地 8.1 組織 BDD 成熟度評估 8.2 BDD 導入計畫範本 8.3 克服導入 BDD 的常見障礙 8.4 建立 BDD 協作文化 8.5 成功導入的關鍵因素 第九章　高階應用與延伸 9.1 AI 輔助 BDD 實踐 9.2 BDD 與 Specification by Example (SBE) 整合 9.3 微服務架構下的 BDD 挑戰 9.4 BDD 的未來趨勢 第十章　附錄 10.1 Gherkin 語法速查表 10.2 BDD 文件模板 10.3 常見 BDD 工具與插件 10.4 推薦學習資源 10.5 BDD 完整檢查清單 第一章　認識 BDD:行為驅動開發的核心理念 1.1 什麼是 BDD BDD (Behavior-Driven Development,行為驅動開發) 是一種軟體開發方法論,強調: ...

UI/UX 設計指引範本 Prompt 目標 指導 AI 進行用戶體驗和使用者介面設計，建立以使用者為中心的設計規範和原型。 角色設定 你是一位資深 UI/UX 設計師，具備豐富的使用者體驗設計經驗，熟悉設計思維、使用者研究方法和現代化介面設計原則。 任務描述 請協助我完成 {專案名稱} 的 UI/UX 設計工作。 專案設計背景 專案名稱: {填入專案名稱} 產品類型: {填入產品類型，如：Web應用、Mobile App、桌面應用} 目標使用者: {填入主要使用者群體} 使用情境: {填入主要使用場景} 設計風格偏好: {填入設計風格，如：簡約、現代、傳統} 品牌色彩: {填入品牌主色調} UI/UX 設計要求 請按照以下結構進行設計： 1. 使用者研究 使用者角色建立 使用者旅程地圖 痛點分析 需求優先級排序 2. 資訊架構設計 內容結構規劃 導航系統設計 資訊層級設計 搜尋和篩選機制 3. 互動設計 使用者流程設計 互動原型設計 微互動設計 回饋機制設計 4. 視覺設計 設計系統建立 色彩配置方案 字體系統設計 圖示和插圖風格 5. 響應式設計 多裝置適配策略 斷點設計規劃 彈性佈局設計 觸控優化設計 6. 無障礙設計 可及性標準遵循 色彩對比度檢查 鍵盤導航支援 螢幕閱讀器相容 輸出格式 # {專案名稱} UI/UX 設計規格 ## 1. 使用者研究 ### 1.1 使用者角色 (Personas) #### 主要使用者角色: [角色名稱] **基本資訊:** - 年齡: [年齡範圍] - 職業: [職業類型] - 技術熟悉度: [初級/中級/高級] - 使用裝置: [主要使用的裝置] **目標和需求:** - 主要目標: [使用者想要達成的目標] - 次要需求: [附加需求清單] - 成功指標: [如何衡量目標達成] **行為特徵:** - 使用習慣: [典型的使用模式] - 偏好: [介面和功能偏好] - 挫折點: [常見的困擾] **情境描述:** "[一段描述使用者在什麼情況下會使用這個產品的情境故事]" ### 1.2 使用者旅程地圖 #### 旅程階段1: 發現階段 **使用者行為:** [使用者在此階段的行為] **想法和感受:** [使用者的心理狀態] **觸點:** [與產品的接觸點] **痛點:** [遇到的問題] **機會點:** [改善的機會] #### 旅程階段2: 探索階段 **使用者行為:** [行為描述] **想法和感受:** [心理狀態] **觸點:** [接觸點] **痛點:** [問題點] **機會點:** [改善機會] #### 旅程階段3: 使用階段 **使用者行為:** [行為描述] **想法和感受:** [心理狀態] **觸點:** [接觸點] **痛點:** [問題點] **機會點:** [改善機會] ### 1.3 痛點分析矩陣 | 痛點 | 頻率 | 嚴重性 | 影響範圍 | 解決優先級 | |------|------|--------|----------|------------| | [痛點1] | [高/中/低] | [高/中/低] | [影響的使用者比例] | [高/中/低] | | [痛點2] | [高/中/低] | [高/中/低] | [影響的使用者比例] | [高/中/低] | ## 2. 資訊架構設計 ### 2.1 網站地圖 首頁 ├── 產品/服務 │ ├── 產品分類A │ ├── 產品分類B │ └── 產品詳細頁 ├── 關於我們 │ ├── 公司介紹 │ ├── 團隊介紹 │ └── 聯絡我們 ├── 支援中心 │ ├── 常見問題 │ ├── 使用指南 │ └── 技術支援 └── 使用者帳戶 ├── 個人資料 ├── 訂單記錄 └── 設定 ...