BRD 業務需求文件範本（Business Requirements Document）

參照標準：IIBA BABOK Guide v3 / ISO/IEC/IEEE 29148:2018
文件用途：記錄業務層級需求，作為專案啟動與範圍確認的基礎依據
適用階段：專案啟始階段（Initiation Phase）

📋 章節目錄

1. 文件資訊
2. 業務目的與範圍
3. 業務背景與現況分析
4. 利害關係人分析
5. 業務需求
6. 限制條件與假設
7. 解決方案選項評估
8. 驗收標準
9. 風險評估
10. 附錄

1. 文件資訊

📝 範本

版本歷程

📖 使用說明

• 文件編號：採用組織標準編碼規則，確保唯一性與可追溯性
• 狀態管理：遵循 Draft → Under Review → Approved 的生命週期
• 版本歷程：每次修改必須記錄，符合 ISO/IEC/IEEE 29148 的組態管理要求
• 文件核定後進入基線管理（Baseline），後續修改需走變更控制流程

💡 範例

2. 業務目的與範圍

📝 範本

2.1 業務目的（Business Purpose）

{描述為什麼需要這個專案/系統，要解決什麼業務問題}

2.2 業務目標（Business Objectives）

2.3 專案範圍（Scope）

包含範圍（In Scope）：

• {功能/流程/系統 1}
• {功能/流程/系統 2}

排除範圍（Out of Scope）：

• {明確排除的項目 1}
• {明確排除的項目 2}

📖 使用說明

• 業務目的：以業務語言描述，避免技術術語。應回答「為什麼做」而非「做什麼」
• 業務目標：需符合 SMART 原則（Specific、Measurable、Achievable、Relevant、Time-bound）
• 範圍定義：明確的 In/Out Scope 可避免後期範圍蔓延（Scope Creep）
• 依據 BABOK 6.1 節「Define Business Need」，業務目的應與組織策略目標對齊

💡 範例

2.1 業務目的

目前人力資源管理仍仰賴 Excel 手動作業，導致薪資計算錯誤率達 5%、員工請假審核平均需 3 個工作天。需建置人力資源管理系統以自動化核心人事作業流程，降低人為錯誤並提升行政效率。

2.2 業務目標

2.3 專案範圍

包含範圍：

• 員工基本資料管理
• 出缺勤管理（請假、加班、排班）
• 薪資計算與發放
• 組織架構管理

排除範圍：

• 招募與面試流程（將於 Phase 2 處理）
• 教育訓練管理系統
• 與外部人力銀行介接

3. 業務背景與現況分析

📝 範本

3.1 組織背景

{描述組織現況、業務規模、相關系統環境}

3.2 現行作業流程

{描述目前的作業方式，可搭配流程圖}

現行流程：
[步驟 1] → [步驟 2] → [步驟 3] → [結果]

3.3 痛點分析

📖 使用說明

• 組織背景：提供足夠脈絡讓讀者理解業務環境，但不需過度詳細
• 現行流程：建議使用 BPMN 或簡易流程圖呈現，幫助識別改善點
• 痛點分析：依據 BABOK 5.2 節「Define Current State」，應以事實與數據支撐
• 影響程度評估建議與利害關係人確認，避免主觀判斷

💡 範例

3.1 組織背景

本公司為金融服務業，員工人數約 2,000 人，分布於總部與 15 個分支據點。目前使用自行開發的 COBOL 人事系統（2005 年上線）搭配 Excel 進行人事管理作業。

3.3 痛點分析

4. 利害關係人分析

📝 範本

4.1 利害關係人清單

4.2 溝通策略

📖 使用說明

• 依據 BABOK 2.2 節「Stakeholder Engagement」進行利害關係人分析
• 影響力/參與程度矩陣：高影響力 + 高參與 = 密切管理；高影響力 + 低參與 = 保持滿意
• RACI 定義：R（Responsible 執行）、A（Accountable 當責）、C（Consulted 諮詢）、I（Informed 告知）
• 溝通策略應針對不同群組制定差異化方案

💡 範例

5. 業務需求

📝 範本

5.1 業務需求清單

5.2 業務規則（Business Rules）

5.3 業務流程需求（To-Be Process）

改善後流程：
[步驟 1] → [步驟 2] → [步驟 3] → [結果]

📖 使用說明

• 優先級：採用 MoSCoW 方法（Must have / Should have / Could have / Won’t have）
• 需求描述：使用「{角色} 需要 {功能} 以便 {效益}」的格式撰寫
• 業務規則：記錄政策、法規、組織規範等約束條件
• 依據 ISO/IEC/IEEE 29148 第 5.2.4 節，每條需求應具備：唯一性、可驗證性、一致性、可追溯性
• 避免在 BRD 中描述技術解決方案，保持在業務層級

💡 範例

5.1 業務需求清單

5.2 業務規則

6. 限制條件與假設

📝 範本

6.1 限制條件（Constraints）

6.2 假設條件（Assumptions）

6.3 依賴關係（Dependencies）

📖 使用說明

• 限制條件：不可改變的外部約束（預算、法規、技術環境等）
• 假設條件：視為真但未經驗證的前提，需定期檢視。依 BABOK 6.3 節建議，每個假設應有對應的風險
• 依賴關係：識別外部依賴有助於專案計畫的時程規劃
• 限制與假設會直接影響解決方案的選擇，需與利害關係人確認

💡 範例

6.1 限制條件

6.2 假設條件

7. 解決方案選項評估

📝 範本

7.1 方案選項

7.2 評估矩陣

7.3 建議方案

{說明推薦方案及理由}

📖 使用說明

• 依據 BABOK 7.1 節「Define Solution Scope」，至少提供 2-3 個可行方案供決策
• 評估項目常見維度：成本、時程、技術風險、維護性、擴充性、合規性
• 評估矩陣採用加權評分法，權重需與利害關係人討論後決定
• 建議方案需明確說明推薦理由，並揭露已知風險

💡 範例

7.1 方案選項

7.3 建議方案

建議採用 方案 C（套裝軟體 + 客製化），理由如下：

1. 可在預算 500 萬內完成，符合限制條件 C-01
2. 導入時程約 6 個月，可達成 2026 年 12 月上線目標
3. 核心功能已驗證穩定，僅需針對業務規則進行客製

8. 驗收標準

📝 範本

8.1 業務驗收標準

8.2 專案成功標準

📖 使用說明

• 驗收標準需與第 5 節業務需求一一對應，確保需求可追溯性
• 依據 ISO/IEC/IEEE 29148 第 5.2.8 節，驗收標準必須是可測量、可觀察的
• 建議採用「Given-When-Then」格式描述驗收條件
• 專案成功標準應在上線後特定時間點（如 3 個月、6 個月）進行衡量

💡 範例

8.1 業務驗收標準

8.2 專案成功標準

9. 風險評估

📝 範本

📖 使用說明

• 風險等級 = 發生機率 × 影響程度，可用數值（1-5）量化
• 緩解措施分四類：迴避（Avoid）、轉移（Transfer）、減輕（Mitigate）、接受（Accept）
• 高風險項目需有詳細的應變計畫（Contingency Plan）
• 風險登記冊應在專案期間持續更新

💡 範例

10. 附錄

📝 範本

10.1 參考文件

10.2 術語定義

10.3 附件清單

• 現行流程圖
• 利害關係人訪談記錄
• 方案評估簡報
• {其他相關文件}

📖 使用說明

• 參考文件列出所有與本 BRD 相關的既有文件
• 術語定義確保所有讀者對專有名詞有一致理解
• 附件清單列出支持本文件的輔助資料

💡 範例

10.1 參考文件

📌 範本使用注意事項

1. 本範本依據 IIBA BABOK Guide v3 與 ISO/IEC/IEEE 29148:2018 標準編製
2. 各章節可依專案規模增刪，但核心章節（2、4、5、8）不建議省略
3. BRD 完成後應進入正式審核流程，取得利害關係人簽核
4. BRD 核定後作為後續 FRD（功能需求文件）的輸入依據