系統需求規格書範本（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 系統目的

{描述系統存在的理由與欲解決的核心問題}

2.2 系統範圍

項目	說明
包含範圍（In Scope）	{系統包含的功能/模組}
排除範圍（Out of Scope）	{明確不包含的功能}

2.3 利害關係人

利害關係人	角色	關注點
{對象}	{角色}	{關注什麼}

2.4 系統環境圖

{系統與外部系統/使用者的關係圖}

📖 使用說明

系統概述讓所有讀者對系統有全貌理解
範圍定義需明確 In/Out of Scope，避免需求蔓延（Scope Creep）
利害關係人分析確保所有需求來源已識別
系統環境圖呈現系統邊界與外部互動

💡 範例

2.1 系統目的

建置整合性人力資源管理系統，取代現有分散的 Excel 表單與紙本流程，實現員工資料管理、薪資計算、請假管理、報表分析的數位化與自動化。

2.2 系統範圍

項目	說明
In Scope	員工資料管理、薪資計算、請假/加班、組織架構、報表、權限管理
Out of Scope	招募管理（使用既有 ATS）、績效考核（Phase 2）、訓練管理（Phase 2）

2.3 利害關係人

利害關係人	角色	關注點
HR 部門	主要使用者	操作效率、個資保護
財務部	次要使用者	薪資正確性、報表合規
全體員工	終端使用者	自助查詢、請假便利
IT 部門	維運者	系統穩定性、可維護性
管理層	決策者	報表分析、投資效益

3. 系統功能需求

📝 範本

3.1 功能需求列表

需求 ID	功能模組	需求描述	優先級	來源
SRD-F-{xxx}	{模組}	{系統應…（shall）}	MoSCoW	{BRD/利害關係人}

3.2 功能需求詳述

SRD-F-{xxx}: {需求標題}

項目	內容
需求 ID	SRD-F-{xxx}
描述	系統應（shall）{功能描述}
輸入	{觸發條件/輸入資料}
處理	{系統處理邏輯}
輸出	{系統輸出/回應}
業務規則	{適用的業務規則}
例外情況	{異常流程}
優先級	Must / Should / Could / Won’t
驗收條件	{如何驗證此需求已滿足}

📖 使用說明

功能需求使用 “shall” 語法：「系統應（shall）提供…」
優先級使用 MoSCoW：Must（必須）/ Should（應該）/ Could（可以）/ Won’t（不做）
每個需求需可驗證（Verifiable）— 有明確的驗收條件
避免模糊用語：「快速」→ 「3 秒內」；「大量」→ 「10,000 筆以上」

💡 範例

3.1 功能需求列表

需求 ID	功能模組	需求描述	優先級	來源
SRD-F-001	員工管理	系統應提供員工資料 CRUD 功能	Must	BRD-001
SRD-F-002	薪資計算	系統應根據薪資結構自動計算月薪	Must	BRD-003
SRD-F-003	請假管理	系統應支援多層級請假審核流程	Must	BRD-005
SRD-F-004	報表	系統應提供薪資報表匯出（PDF/Excel）	Should	BRD-007
SRD-F-005	通知	系統應支援即時推播通知	Could	利害關係人訪談

3.2 功能需求詳述

SRD-F-002: 薪資自動計算

項目	內容
需求 ID	SRD-F-002
描述	系統應根據員工薪資結構、出缺勤記錄、加班時數，自動計算當月應發薪資
輸入	員工薪資結構（基本薪 + 津貼）、當月出缺勤記錄、加班申請核准記錄
處理	基本薪 + 津貼 + 加班費 - 請假扣款 - 勞健保 - 所得稅預扣
輸出	薪資明細（各項目金額）+ 應發總額 + 實發金額
業務規則	BR-PAY-001（加班費計算公式）、BR-PAY-002（勞健保費率表）
例外情況	新進員工（不足月）按比例計算；留職停薪者不計算
優先級	Must
驗收條件	使用 100 筆測試資料計算結果與 Excel 手算一致，誤差 ≤ ±1 元

4. 系統介面需求

📝 範本

4.1 使用者介面（UI）

需求 ID	描述	規格
SRD-UI-{xxx}	{UI 需求}	{規格/標準}

4.2 外部系統介面

介面 ID	外部系統	方向	協定	資料格式	頻率
SRD-IF-{xxx}	{系統名}	入/出/雙向	{協定}	{格式}	{頻率}

4.3 硬體介面

需求 ID	描述	規格
SRD-HW-{xxx}	{硬體介面需求}	{規格}

📖 使用說明

UI 需求定義使用者介面的技術規格（非視覺設計）
外部系統介面是整合設計的關鍵輸入
介面需定義：方向（誰呼叫誰）、協定、資料格式、頻率、錯誤處理

💡 範例

4.1 使用者介面

需求 ID	描述	規格
SRD-UI-001	系統應支援響應式設計（RWD）	支援 1024px ~ 1920px 寬度
SRD-UI-002	系統應符合 WCAG 2.1 AA 無障礙標準	色彩對比 ≥ 4.5:1
SRD-UI-003	系統應支援繁體中文、English 雙語系	i18n 架構

4.2 外部系統介面

介面 ID	外部系統	方向	協定	資料格式	頻率
SRD-IF-001	Active Directory	入	LDAPS	LDAP Query	即時（登入時）
SRD-IF-002	薪轉銀行 API	出	REST/HTTPS	JSON (ISO 20022)	每月 1 次
SRD-IF-003	打卡系統	入	SFTP	CSV	每日批次
SRD-IF-004	Email Server	出	SMTP/TLS	MIME	事件驅動

5. 效能需求

📝 範本

需求 ID	指標	目標值	測量條件	優先級
SRD-P-{xxx}	{效能指標}	{目標}	{條件}	Must/Should

📖 使用說明

效能需求需可量測（有數字、有條件、有量測方法）
常見指標：回應時間、吞吐量、並發數、資料處理量
目標值需基於業務需求（如員工數、尖峰時段）
效能需求是壓力測試/效能測試的驗收標準

💡 範例

需求 ID	指標	目標值	測量條件	優先級
SRD-P-001	頁面載入時間	≤ 2 秒	4G 網路、首次載入	Must
SRD-P-002	API 回應時間 (P95)	≤ 500ms	200 concurrent users	Must
SRD-P-003	薪資批次計算	≤ 5 分鐘	10,000 筆員工資料	Must
SRD-P-004	報表匯出	≤ 30 秒	5,000 筆 Excel 匯出	Should
SRD-P-005	系統同時在線	≥ 500 users	不影響 P-001/P-002	Must
SRD-P-006	日交易量	≥ 50,000 TXN/day	含查詢+寫入	Should

6. 安全需求摘要

📝 範本

需求 ID	安全領域	需求描述	對應標準	優先級
SRD-S-{xxx}	{領域}	{描述}	{標準章節}	Must/Should

📎 完整安全需求詳見：《安全需求清單》(SecurityRequirements_Template)

📖 使用說明

SRD 中的安全需求為摘要層級，完整內容在安全需求清單
摘要確保系統設計階段不會遺漏安全考量
安全領域涵蓋：認證、授權、加密、日誌、通訊

💡 範例

需求 ID	安全領域	需求描述	對應標準	優先級
SRD-S-001	認證	系統應支援 MFA 多因子認證	OWASP ASVS V2.8	Must
SRD-S-002	授權	系統應實施 RBAC 角色權限控制	OWASP ASVS V4.1	Must
SRD-S-003	加密	個資欄位應使用 AES-256 加密儲存	OWASP ASVS V6.2	Must
SRD-S-004	通訊	所有傳輸應使用 TLS 1.2+	OWASP ASVS V9.1	Must
SRD-S-005	日誌	系統應記錄所有安全事件（認證/授權）	OWASP ASVS V7.1	Must

7. 可靠性與可用性

📝 範本

需求 ID	指標	目標值	說明
SRD-R-{xxx}	{可靠性/可用性指標}	{目標}	{說明}

📖 使用說明

可用性（Availability）：系統可正常使用的時間比例
可靠性（Reliability）：系統不發生故障的能力
MTBF（Mean Time Between Failures）：平均故障間隔
RTO（Recovery Time Objective）：恢復時間目標
RPO（Recovery Point Objective）：恢復點目標（可接受的資料丟失量）

💡 範例

需求 ID	指標	目標值	說明
SRD-R-001	系統可用性	≥ 99.5%（月度）	排除計畫性維護窗口
SRD-R-002	RTO	≤ 30 分鐘	災難發生後恢復服務的時間
SRD-R-003	RPO	≤ 1 小時	最多可接受丟失 1 小時的資料
SRD-R-004	MTBF	≥ 720 小時	平均每月少於 1 次非計畫停機
SRD-R-005	計畫維護窗口	每月 1 次，≤ 2 小時	週六 02:00-04:00

8. 限制條件

📝 範本

8.1 技術限制

限制 ID	描述	原因
SRD-C-{xxx}	{技術限制}	{原因}

8.2 業務限制

限制 ID	描述	原因
SRD-CB-{xxx}	{業務限制}	{原因}

8.3 假設

假設 ID	描述	風險（若假設不成立）
SRD-A-{xxx}	{假設}	{風險}

📖 使用說明

限制條件限定了系統設計的自由度（必須遵守）
技術限制：企業既有技術棧、第三方系統版本
業務限制：預算、時程、法規
假設需要明確列出，若假設失效，需重新評估需求

💡 範例

8.1 技術限制

限制 ID	描述	原因
SRD-C-001	後端使用 .NET 8 開發	企業技術標準
SRD-C-002	資料庫使用 PostgreSQL	授權成本考量
SRD-C-003	部署於 Azure AKS (Kubernetes)	企業雲端策略
SRD-C-004	需整合既有 AD 認證	企業 SSO 策略

8.2 業務限制

限制 ID	描述	原因
SRD-CB-001	第一版需在 6 個月內上線	合約期限
SRD-CB-002	預算上限 500 萬	年度 IT 預算
SRD-CB-003	需符合個人資料保護法	法規要求

8.3 假設

假設 ID	描述	風險（若假設不成立）
SRD-A-001	AD 支援 LDAPS 查詢	需改用其他認證方式，增加 2 週工期
SRD-A-002	員工資料量 ≤ 15,000 筆	超過需重新評估架構與效能目標
SRD-A-003	使用者皆使用 Chrome/Edge 瀏覽器	需增加跨瀏覽器測試（增加成本）

9. 需求追溯矩陣

📝 範本

SRD 需求 ID	BRD 來源	設計文件	測試案例	狀態
SRD-{x}-{xxx}	BRD-{xxx}	SAD §{x.x}	TC-{xxx}	核定/變更/取消

📖 使用說明

追溯矩陣確保需求的向前追溯（→ 設計 → 測試）與向後追溯（← BRD）
ISO/IEC/IEEE 29148:2018 強調 Bidirectional Traceability
每個需求都需有對應的驗證方法（測試/審查/分析/演示）
未追溯的需求 = 可能未實作或未測試 = 風險

💡 範例

SRD 需求 ID	BRD 來源	設計文件	測試案例	狀態
SRD-F-001	BRD-001	SAD §4.1	TC-EMP-001~010	核定
SRD-F-002	BRD-003	SAD §4.3	TC-PAY-001~025	核定
SRD-F-003	BRD-005	SAD §4.4	TC-LEV-001~015	核定
SRD-P-001	BRD-008 (NFR)	SAD §6.1	TC-PERF-001	核定
SRD-S-001	BRD-009 (SEC)	SAD §5.1	TC-SEC-001~005	核定

10. 附錄

📝 範本

10.1 術語表

術語	定義
{術語}	{定義}

10.2 參考文件

文件	用途
ISO/IEC/IEEE 29148:2018	需求工程標準
BRD-HRM-v1.0	商業需求文件
{其他}	{用途}

10.3 簽核

角色	姓名	日期	簽核
系統分析師	{姓名}	{日期}	☐
架構師	{姓名}	{日期}	☐
PM	{姓名}	{日期}	☐
產品負責人	{姓名}	{日期}	☐

📖 使用說明

SRD 基線化需經所有利害關係人簽核
基線化後的變更需走正式 CR（Change Request）流程
術語表確保文件中的專業用語有統一定義

💡 範例

10.3 簽核

角色	姓名	日期	簽核
系統分析師	李分析	2026-03-28	☑
架構師	張架構	2026-03-29	☑
PM	林專案	2026-03-30	☑
產品負責人	王 HR 主管	2026-04-01	☑

📌 範本使用注意事項
本範本依據 ISO/IEC/IEEE 29148:2018 Section 6.2（System Requirements Specification）編製
SRD 介於 BRD（商業需求）與 FRD（功能需求）之間，定義系統層級需求
搭配「BRD 範本」使用 — SRD 的需求需可追溯至 BRD
搭配「SAD 範本」使用 — 架構設計需滿足 SRD 中的所有需求
搭配「測試計畫範本」使用 — 每個 SRD 需求需有對應的測試案例
需求撰寫原則：明確（Unambiguous）、可驗證（Verifiable）、可追溯（Traceable）

系統需求規格書範本（System Requirements Document, SRD）#

📋 章節目錄#

1. 文件資訊#

📝 範本#

📖 使用說明#

💡 範例#

2. 系統概述#

📝 範本#

2.1 系統目的#

2.2 系統範圍#

2.3 利害關係人#

2.4 系統環境圖#

📖 使用說明#

💡 範例#

2.1 系統目的#

2.2 系統範圍#

2.3 利害關係人#

3. 系統功能需求#

📝 範本#

3.1 功能需求列表#

3.2 功能需求詳述#

📖 使用說明#

💡 範例#

3.1 功能需求列表#

3.2 功能需求詳述#

4. 系統介面需求#

📝 範本#

4.1 使用者介面（UI）#

4.2 外部系統介面#

4.3 硬體介面#

📖 使用說明#

💡 範例#

4.1 使用者介面#

4.2 外部系統介面#

5. 效能需求#

📝 範本#

📖 使用說明#

💡 範例#

6. 安全需求摘要#

📝 範本#

📖 使用說明#

💡 範例#

7. 可靠性與可用性#

📝 範本#

📖 使用說明#

💡 範例#

8. 限制條件#

📝 範本#

8.1 技術限制#

8.2 業務限制#

8.3 假設#

📖 使用說明#

💡 範例#

8.1 技術限制#

8.2 業務限制#

8.3 假設#

9. 需求追溯矩陣#

📝 範本#

📖 使用說明#

💡 範例#

10. 附錄#

📝 範本#

10.1 術語表#

10.2 參考文件#

10.3 簽核#

📖 使用說明#

💡 範例#

10.3 簽核#

系統需求規格書範本（System Requirements Document, SRD）

📋 章節目錄

1. 文件資訊

📝 範本

📖 使用說明

💡 範例

2. 系統概述

📝 範本

2.1 系統目的

2.2 系統範圍

2.3 利害關係人

2.4 系統環境圖

📖 使用說明

💡 範例

2.1 系統目的

2.2 系統範圍

2.3 利害關係人

3. 系統功能需求

📝 範本

3.1 功能需求列表

3.2 功能需求詳述

📖 使用說明

💡 範例

3.1 功能需求列表

3.2 功能需求詳述

4. 系統介面需求

📝 範本

4.1 使用者介面（UI）

4.2 外部系統介面

4.3 硬體介面

📖 使用說明

💡 範例

4.1 使用者介面

4.2 外部系統介面

5. 效能需求

📝 範本

📖 使用說明

💡 範例

6. 安全需求摘要

📝 範本

📖 使用說明

💡 範例

7. 可靠性與可用性

📝 範本

📖 使用說明

💡 範例

8. 限制條件

📝 範本

8.1 技術限制

8.2 業務限制

8.3 假設

📖 使用說明

💡 範例

8.1 技術限制

8.2 業務限制

8.3 假設

9. 需求追溯矩陣

📝 範本

📖 使用說明

💡 範例

10. 附錄

📝 範本

10.1 術語表

10.2 參考文件

10.3 簽核

📖 使用說明

💡 範例

10.3 簽核