BRD（Business Requirements Document）是專案啟動前用來定義「為什麼做、要達成什麼業務目標」的正式文件。這篇文章完整拆解 BRD 的標準架構、五步驟撰寫流程、常見錯誤與品質檢查清單，讓你從零寫出一份能對齊跨部門共識的業務需求文件。
BRD 是什麼？業務需求文件的核心定義
BRD，全名 Business Requirements Document，中文常譯為「業務需求文件」或「商業需求規劃書」。簡單來說，它是一份在專案正式啟動前，用來回答「我們為什麼要做這件事？做完之後要達成什麼業務目標？」的正式文件。
BRD 不是技術規格書，也不是功能清單。它聚焦在業務層面——描述現有流程的痛點、期望達成的商業成果、以及專案的範疇邊界。
BRD 解決的三個核心痛點：
- 需求不清導致專案失焦：沒有 BRD，開發團隊只能靠口頭溝通理解需求，三個月後才發現做出來的東西不是業務要的
- 跨部門認知落差：業務部門想的是「提升客戶滿意度」，IT 部門理解的是「加一個客服聊天機器人」——兩邊根本在講不同的事
- 資源浪費與範疇蔓延：沒有白紙黑字的範疇定義，需求會像滾雪球一樣越滾越大
舉個實際例子：一家電商公司要導入新的訂單管理系統。業務部門希望「處理速度更快」，倉儲部門要「即時庫存同步」，財務部門需要「自動對帳」。如果 PM 沒有先寫一份 BRD 把這些需求整理清楚、排出優先順序，專案很容易變成各部門許願池，最後什麼都做、什麼都做不好。
BRD 的適用情境包括：新產品開發、企業系統導入（ERP、CRM）、內部流程改造、以及業務擴張計畫。只要是需要跨部門協作、投入一定資源的專案，都建議先產出 BRD。
一句話定義： BRD 是企業在啟動專案前，用來描述業務目標、現況痛點與專案範疇的正式文件，確保所有利害關係人對「為什麼做」和「做到什麼程度」有一致共識。
如果你正在準備寫 BRD，建議先熟悉企劃書的基本架構，兩者在邏輯上有不少共通之處。
BRD、MRD、PRD 三份文件的差異與使用時機
在產品開發或專案管理的流程中，BRD 並不是唯一的需求文件。它通常會和 MRD（Market Requirements Document，市場需求文件）與 PRD（Product Requirements Document，產品需求文件）搭配使用。三份文件各自回答不同層次的問題：
- BRD → 業務層：「為什麼做？要達成什麼商業目標？」由業務主管或 PM 主導撰寫，讀者是高層決策者與跨部門主管
- MRD → 市場層：「市場機會在哪裡？目標客群是誰？競爭對手在做什麼？」由產品行銷或市場研究團隊主導，讀者是產品團隊與行銷團隊
- PRD → 產品層：「要做什麼功能？規格是什麼？驗收標準為何？」由產品經理主導，讀者是工程師、設計師與 QA 團隊
| 比較項目 | BRD 業務需求文件 | MRD 市場需求文件 | PRD 產品需求文件 |
|---|---|---|---|
| 核心問題 | 為什麼做？目標是什麼？ | 市場在哪？客群是誰？ | 做什麼功能？規格為何？ |
| 主要撰寫者 | PM / 業務主管 | 產品行銷 / 市場研究 | 產品經理 |
| 主要讀者 | 高層決策者、跨部門主管 | 產品團隊、行銷團隊 | 工程師、設計師、QA |
| 抽象程度 | 高（業務語言） | 中（市場數據） | 低（技術規格） |
| 典型篇幅 | 5–20 頁 | 10–30 頁 | 20–50 頁以上 |
三者的時序關係
在傳統瀑布式開發中，三份文件有明確的先後順序：先確認業務目標（BRD），再分析市場機會（MRD），最後定義產品規格（PRD）。但在敏捷環境下，這三份文件的界線會變得模糊——有些團隊會把 BRD 和 MRD 合併成一份「產品願景文件」，再用 Epic 和 User Story 取代傳統 PRD。
台灣中小企業的常見狀況
坦白說，我們接觸過的台灣中小企業，很少會完整產出三份文件。常見的做法是：
- 新創公司（< 20 人）：BRD + PRD 合一，MRD 以市場調查簡報取代。重點是速度，文件精簡即可
- 傳統製造業導入 ERP：BRD 非常重要（因為跨部門利害關係人多），MRD 通常省略，PRD 由系統整合商提供
- 軟體公司做新產品：三份文件都需要，但 MRD 可能以商業模式分析的形式呈現
判斷原則： 如果你的專案涉及跨部門協作且預算超過 NT$500,000，至少要有 BRD。如果產品面向外部市場，加上 MRD。如果有工程開發，加上 PRD。
最常見的混淆
「BRD 不是功能規格書」——這是我們看過最多人犯的錯。BRD 應該寫「訂單處理時間需從 48 小時縮短至 24 小時」，而不是「系統需要一個批次處理功能，支援每秒 1000 筆交易」。後者是 PRD 的內容。
BRD 應該包含哪些內容？九大標準架構拆解
一份完整的 BRD 通常包含以下九個章節。每個章節我會說明「寫什麼」、「為什麼重要」以及「常見錯誤」。
1. 執行摘要（Executive Summary）
寫什麼： 用一頁以內的篇幅，讓高層決策者快速掌握專案全局——為什麼要做、預期效益、大致時程與預算。
為什麼重要： 高層通常沒時間讀完整份文件。執行摘要是他們決定「要不要繼續看下去」的關鍵。
常見錯誤： 把執行摘要寫成目錄或前言。執行摘要應該是「讀完這一頁就能做決策」的濃縮版，不是「本文件共分為九個章節」的導讀。
2. 業務目標與成功指標
寫什麼： 用 SMART 原則定義具體、可衡量的業務目標。
為什麼重要： 沒有明確目標，專案結束時無法判斷「成功了沒有」。
| 模糊目標（❌） | SMART 目標（✅） |
|---|---|
| 提升營運效率 | 將訂單處理時間從 48 小時縮短至 24 小時 |
| 改善客戶體驗 | 將客戶滿意度（NPS）從 32 分提升至 50 分 |
| 降低成本 | 每月人工作業成本從 NT$120,000 降至 NT$60,000 |
常見錯誤： 目標太多且沒有優先順序。建議主要目標不超過 3 個，每個目標都要有對應的量化指標。如果你對目標設定框架不熟悉，可以參考 OKR 框架的設定方法，用 Objective 對應業務目標、Key Results 對應成功指標。
3. 問題陳述與現況分析
寫什麼： 描述現有流程的痛點，最好附上數據佐證。例如：「目前訂單從接單到出貨平均需要 48 小時，其中 60% 的時間花在人工核對庫存。」
為什麼重要： 讓所有人理解「為什麼現狀不能繼續」，建立變革的急迫感。
常見錯誤： 只描述感受（「大家都覺得很慢」），沒有數據支撐。即使是粗略的數據，也比純主觀描述有說服力。
4. 範疇定義（Scope）
寫什麼： 明確列出專案「包含什麼」與「不包含什麼」。
為什麼重要： 範疇定義是防止需求蔓延的第一道防線。沒有它，專案會不斷被塞入新需求，直到時程爆炸。
常見錯誤： 只寫「包含」，不寫「不包含」。明確寫出「本專案不包含行動 App 開發」比什麼都不寫更能避免後續爭議。
5. 利害關係人清單
寫什麼： 列出所有與專案相關的人員，標明他們的角色（決策者、使用者、被告知者）與關注點。
為什麼重要： 漏掉關鍵利害關係人，等於埋下一顆定時炸彈。我們曾遇過一個案例：ERP 導入專案沒有把倉儲主管列入利害關係人，結果系統上線後倉儲流程完全不合用，整個模組重做。
常見錯誤： 只列名字和職稱，沒有標明每個人的「關注點」和「影響力等級」。
6. 業務需求清單
寫什麼： 將需求分為功能性需求（系統要能做什麼）與非功能性需求（效能、安全性、可用性等）。每條需求要有唯一編號、優先等級和驗收標準。
常見錯誤： 把實作方式寫進需求。BRD 應該寫「系統需支援多幣別結算」，而不是「使用 API 串接第三方匯率服務」。
7. 限制條件與假設
寫什麼： 預算上限、時程限制、技術限制、法規要求，以及撰寫 BRD 時的假設前提。
常見錯誤： 假設沒有被明確記錄。例如「假設現有伺服器能承受新系統的負載」——如果這個假設錯了，整個專案計畫都要調整。
8. 風險與依賴關係
寫什麼： 初步識別主要風險（發生機率、影響程度、應對策略），以及專案對外部因素的依賴（例如第三方系統整合、法規審批）。
常見錯誤： 風險描述太籠統。「可能會延遲」不是風險描述，「供應商 API 文件尚未提供，可能導致整合階段延遲 2–4 週」才是。
9. 附錄
寫什麼： 詞彙表（確保所有人對專業術語的理解一致）、參考文件、訪談紀錄摘要。
以下是各章節的建議篇幅：
| 章節 | 核心問題 | 建議篇幅 |
|---|---|---|
| 執行摘要 | 這個專案值得投資嗎？ | 1 頁 |
| 業務目標與成功指標 | 做完要達成什麼？ | 1–2 頁 |
| 問題陳述與現況分析 | 現在有什麼問題？ | 1–2 頁 |
| 範疇定義 | 做什麼、不做什麼？ | 1–2 頁 |
| 利害關係人清單 | 誰會被影響？ | 1 頁 |
| 業務需求清單 | 具體要滿足哪些需求？ | 3–5 頁 |
| 限制條件與假設 | 有哪些限制？ | 1 頁 |
| 風險與依賴關係 | 可能出什麼問題？ | 1–2 頁 |
| 附錄 | 補充資料 | 視需要 |
BRD 怎麼寫？五步驟實作流程
了解了 BRD 的架構之後，接下來是實際撰寫的流程。我們團隊在實務中歸納出五個步驟，從資訊蒐集到版本管理，每個步驟都有明確的產出物。
Step 1：需求訪談與資訊蒐集
BRD 的品質取決於你蒐集到的資訊品質。第一步是找對人、問對問題。
訪談對象清單：
- 業務主管：了解策略方向與預期效益
- 終端使用者：了解實際操作痛點
- IT 部門：了解技術限制與現有系統架構
- 財務部門：了解預算限制與 ROI 期望
實用訪談問題範例：
| 訪談對象 | 問題範例 |
|---|---|
| 業務主管 | 「這個專案如果成功，半年後你希望看到什麼改變？」 |
| 終端使用者 | 「目前工作流程中，最花時間的步驟是哪個？」 |
| IT 部門 | 「現有系統有哪些整合限制是我們必須考慮的？」 |
| 財務部門 | 「這個專案的預算上限是多少？ROI 期望是多少？」 |
訪談不是隨便聊聊。建議每場訪談控制在 45–60 分鐘，事先準備問題大綱，訪談後 24 小時內整理紀錄並請受訪者確認。如果你想深入了解需求訪談的技巧，可以參考我們的問卷設計教學，裡面的問題設計原則同樣適用於訪談。
產出物： 訪談紀錄摘要、初步需求清單
Step 2：定義業務目標與成功指標
把訪談中蒐集到的模糊期望，轉化為具體、可衡量的業務目標。
實作方法： 使用 OKR 或 KPI 框架。以零售業 POS 系統升級為例：
- Objective（業務目標）： 提升門市結帳效率，減少顧客等待時間
- Key Result 1： 平均結帳時間從 3 分鐘縮短至 1.5 分鐘
- Key Result 2： 尖峰時段排隊人數從平均 8 人降至 4 人以下
- Key Result 3： 收銀員操作錯誤率從 5% 降至 1% 以下
這個步驟最關鍵的是「量化」。如果業務主管說「我要更快」，你的工作是追問「多快算快？現在多慢？」直到得到一個可衡量的數字。
我們團隊在定義目標時，會用 ClickUp 的 OKR 範本 把目標拆解成可追蹤的指標，這樣後續專案執行時可以直接對照驗收。
產出物： 業務目標清單（含量化指標）
Step 3：起草文件結構
不要一開始就埋頭寫內容。先用大綱確認利害關係人對文件結構的共識，再填寫細節。
建議流程： 1. 先建立九大章節的大綱骨架 2. 在每個章節下列出 3–5 個要點 3. 將大綱發給主要利害關係人（決策者 + 專案發起人）確認 4. 確認後再開始填寫詳細內容
這個「先確認大綱」的步驟看似多此一舉，但能避免你花兩週寫完整份文件後，才發現方向根本不對。
在工具選擇上，小型團隊用 Google Docs 就夠了。如果團隊超過 10 人、需要版本控制與跨部門協作，建議使用 Notion 的知識庫功能，可以把 BRD 的每個章節做成獨立頁面，方便不同人同時編輯。
產出物： BRD 初稿
Step 4：利害關係人審查與簽核
BRD 初稿完成後，需要經過正式的審查流程。這個步驟的目的不只是「讓大家看過」，而是要取得書面共識。
審查會議準備：
- 提前 3–5 天將文件發給所有審查者
- 會議時間控制在 90 分鐘以內
- 準備一份「待決議事項清單」，針對有爭議的需求逐一討論
處理衝突需求的方法：
當業務部門要 A、IT 部門說做不到時，不要急著妥協。先釐清： 1. 業務需求背後的真正目的是什麼？（也許有替代方案能達成同樣目的） 2. IT 的限制是技術上不可能，還是時程或預算不夠？（如果是後者，可以分階段實作） 3. 如果必須取捨，由誰做最終決策？（這就是利害關係人清單中「決策者」的作用）
BRD 作為跨部門溝通的基準文件：
簽核完成的 BRD 不只是一份文件，它是整個專案的「共識基準線」。後續任何需求變更，都應該回到 BRD 來評估影響。我們建議把簽核後的 BRD 存放在團隊都能存取的知識庫中，讓它成為組織知識的一部分，而不是存在某個人的電腦裡。這對數位轉型中的知識管理尤其重要。
產出物： 經簽核的 BRD 正式版（含簽核紀錄）
Step 5：版本管理與維護
BRD 不是一次性文件。專案執行過程中，業務環境可能改變、利害關係人可能異動、需求可能調整。
何時需要更新 BRD：
- 業務目標或成功指標發生變更
- 專案範疇有重大調整（新增或移除需求）
- 關鍵利害關係人異動（例如專案發起人離職）
- 重要里程碑完成後的回顧
版本命名規則建議：
- v0.1 ~ v0.9： 草稿階段，內部討論用
- v1.0： 正式簽核版本
- v1.1、v1.2： 小幅修訂（文字修正、細節補充）
- v2.0： 重大變更（範疇調整、目標改變），需重新簽核
每次更新都應在文件開頭的「版本紀錄表」中記錄：版本號、修改日期、修改內容摘要、修改者。
產出物： 版本更新紀錄、最新版 BRD
BRD 範本架構與填寫說明
以下是一份可直接套用的 BRD 範本架構。我們提供兩種版本：適合瀑布式專案的完整版，以及適合敏捷環境的精簡版。
通用 BRD 範本架構
| 章節 | 填寫內容 | 範例文字 |
|---|---|---|
| 文件資訊 | 專案名稱、版本號、撰寫者、日期、簽核者 | 專案名稱：訂單管理系統升級 / v1.0 / 撰寫者：王小明 |
| 執行摘要 | 一段話說明專案背景、目標與預期效益 | 「因應訂單量年增 40%，現有系統已無法負荷，本專案目標為導入新訂單管理系統，將處理時間縮短 50%。」 |
| 業務目標 | 2–3 個 SMART 目標，含量化指標 | 目標 1：訂單處理時間從 48 小時縮短至 24 小時（上線後 3 個月內達成） |
| 問題陳述 | 現況描述 + 數據佐證 | 「目前 60% 的訂單處理時間花在人工核對庫存，每月因庫存不同步導致的退貨約 150 筆。」 |
| 範疇定義 | 「包含」與「不包含」清單 | 包含：訂單建立、庫存同步、出貨通知 / 不包含：行動 App、客戶自助查詢 |
| 利害關係人 | 姓名、部門、角色、關注點 | 張經理 / 業務部 / 決策者 / 關注出貨速度與客戶滿意度 |
| 業務需求 | 需求編號、描述、優先等級、驗收標準 | BR-001 / 系統需支援即時庫存同步 / 高 / 庫存數據延遲不超過 5 分鐘 |
| 限制與假設 | 預算、時程、技術限制、假設前提 | 預算上限 NT$3,000,000 / 假設現有網路頻寬足以支撐即時同步 |
| 風險 | 風險描述、機率、影響、應對策略 | 供應商 API 整合延遲 / 中 / 高 / 預留 2 週緩衝時間 |
瀑布式 vs. 敏捷 BRD 的差異
| 比較項目 | 瀑布式 BRD（完整版） | 敏捷 BRD（精簡版） |
|---|---|---|
| 篇幅 | 10–20 頁 | 3–5 頁 |
| 需求描述方式 | 詳細的業務需求清單（含編號與驗收標準） | 聚焦業務目標 + Epic 層級的需求描述 |
| 範疇定義 | 嚴格的「包含/不包含」清單 | 以 MVP（最小可行產品）定義初始範疇 |
| 更新頻率 | 重大變更時才更新 | 每個 Sprint 回顧後可能微調 |
| 簽核流程 | 正式書面簽核 | 口頭確認 + 會議紀錄 |
| 適用情境 | 大型系統導入、合規專案、政府標案 | 新產品開發、內部工具、快速迭代專案 |
敏捷環境下的替代做法： 在跑 Scrum 的團隊中，BRD 的角色通常由「產品願景文件」+ Epic 描述來取代。BRD 定義「為什麼做」和「大方向」，然後拆解成多個 Epic，每個 Epic 再拆成 User Story。這樣既保留了業務層面的共識文件，又不會因為過度詳細的前期規劃而拖慢開發節奏。
依產業情境的範本變體
不同產業的 BRD 側重點不同：
- IT 系統導入（ERP / CRM）： 強調現有系統整合需求、資料遷移範疇、使用者培訓計畫。篇幅通常 15–20 頁
- 合規專案（金融、醫療）： 必須加入法規要求章節、稽核追蹤需求、資料安全與隱私規範。篇幅可能超過 20 頁
- 新產品開發： 側重市場機會描述（可與 MRD 合併）、競品分析、商業模式假設。篇幅 8–12 頁
BRD 要寫多長？ 沒有標準答案，但有個簡單的判斷原則：專案預算每增加 NT$1,000,000，BRD 大約增加 3–5 頁。一個 NT$500,000 的內部流程改善專案，5 頁精簡版就夠了；一個 NT$5,000,000 的 ERP 導入專案，15–20 頁是合理的。
撰寫與管理 BRD 的推薦工具
選對工具能讓 BRD 的撰寫與維護效率大幅提升。以下是我們根據團隊規模整理的推薦組合。
專案管理工具比較
選擇 2-4 個工具，即時對比功能與價格
工具比較表
| 工具 | 適用規模 | 月費（NT$/人） | BRD 相關功能 | 優點 | 缺點 |
|---|---|---|---|---|---|
| monday.com | 5–200 人 | 免費方案可用，付費約 NT$288 起 | WorkDocs 文件協作、自動化通知、看板追蹤需求狀態 | BRD 與專案執行無縫銜接，審查流程可自動化 | 純文件撰寫功能不如專業文字處理工具 |
| Notion | 1–50 人 | 免費方案可用，Plus 約 NT$480 | 知識庫、版本歷史、模板系統、資料庫關聯 | 文件結構彈性高，適合知識管理 | 大型團隊的權限管理較弱 |
| ClickUp | 5–100 人 | 免費方案可用，付費約 NT$220 起 | Docs 文件、任務關聯、自訂欄位、Sprint 整合 | BRD 需求可直接轉為任務追蹤 | 功能太多，學習曲線較陡 |
| Google Docs | 1–10 人 | 免費 | 即時協作、留言、建議模式 | 零門檻、所有人都會用 | 無版本控制、無任務追蹤整合 |
我們團隊實際的做法是：用 monday.com 的 WorkDocs 撰寫 BRD，因為寫完之後可以直接在同一個平台上建立專案看板，把 BRD 中的每條需求轉成可追蹤的任務。PM 設定了一條自動化規則：當需求狀態從「待審查」變成「已核准」時，自動建立對應的開發任務並通知負責人。這個設定讓我們的 BRD 不再只是一份靜態文件，而是真正驅動專案執行的起點。免費方案不需要信用卡，可以直接試用。
用 AI 生成 BRD 初稿：提示詞範例與注意事項
AI 工具（ChatGPT、Claude）可以加速 BRD 初稿的產出，但絕對不能取代需求訪談和利害關係人確認。以下是三個實用的提示詞範例：
提示詞 1：生成 BRD 大綱
「我是一家 50 人電商公司的 PM，要導入新的訂單管理系統。請幫我生成一份 BRD 的大綱，包含執行摘要、業務目標、問題陳述、範疇定義、利害關係人、業務需求、限制條件、風險分析。每個章節列出 3-5 個需要填寫的要點。」
提示詞 2：將模糊需求轉化為 SMART 目標
「以下是業務主管在訪談中提到的需求：『出貨要更快、錯誤要更少、客戶不要一直打電話來問進度』。請將這些需求轉化為 3 個 SMART 格式的業務目標，包含具體的量化指標。」
提示詞 3：生成風險清單
「我們要從舊的 ERP 系統遷移到新系統，團隊 15 人，預算 NT$3,000,000，時程 6 個月。請列出 8 個可能的風險，每個風險包含：描述、發生機率（高/中/低）、影響程度（高/中/低）、建議應對策略。」
注意事項： AI 生成的內容是「起點」不是「終點」。你需要根據實際訪談結果修改每一條內容，尤其是業務目標和範疇定義——這些必須來自真實的利害關係人共識，不能由 AI 代勞。
如果你的團隊偏技術導向、習慣跑 Scrum，ClickUp 的 Docs 功能可以讓你在同一個平台上撰寫 BRD 並直接拆解成 Sprint 任務，省去跨工具複製貼上的麻煩。
BRD 常見錯誤與品質檢查清單
我們審查過上百份 BRD，以下是最常見的五大錯誤，每個都附上具體的修正方式。
錯誤 1：目標過於模糊，無法衡量
症狀： 業務目標寫成「提升效率」、「改善體驗」、「降低成本」，沒有任何數字。
修正方式： 對每個目標追問「多少？多快？跟現在比差多少？」直到得到可量化的指標。如果真的無法量化，至少要有明確的驗收標準（例如「使用者完成操作不需要查閱手冊」）。
錯誤 2：範疇未明確定義，導致後期需求膨脹
症狀： BRD 只寫了「要做什麼」，沒有寫「不做什麼」。專案執行到一半，不斷有人說「這個也要加」。
修正方式： 在範疇定義章節，強制自己寫出至少 5 條「不包含」項目。這些通常是利害關係人「想要但這次不做」的需求。
案例： 一家製造業公司導入 ERP 系統，BRD 的範疇只寫了「包含生產管理、庫存管理、採購管理」。專案執行到第三個月，財務部門突然說「我以為也包含會計模組」，結果追加預算 NT$800,000、時程延後兩個月。如果一開始就在 BRD 中明確寫出「不包含：會計模組、人資模組、CRM 模組」，這個問題就不會發生。
錯誤 3：缺少利害關係人簽核
症狀： BRD 寫完後用 email 發出去，沒有人正式回覆「我同意」。三個月後需求變更時，各方開始互相推諉。
修正方式： 建立正式的簽核流程。至少需要專案發起人、業務主管、IT 主管三方簽核。可以用電子簽核工具，重點是要有書面紀錄。
錯誤 4：把 BRD 寫成技術規格書
症狀： BRD 裡出現「使用 RESTful API」、「資料庫採用 PostgreSQL」、「前端用 React 框架」這類技術細節。
修正方式： BRD 只描述「要達成什麼」，不描述「怎麼做」。技術實作方式是 PRD 和技術架構文件的範疇。如果你發現自己在 BRD 裡寫技術規格，停下來問自己：「業務主管看得懂這段嗎？」如果看不懂，就不該出現在 BRD 裡。
錯誤 5：文件完成後從未更新，與實際執行脫節
症狀： BRD 簽核後就被束之高閣。專案執行過程中需求已經改了好幾次，但 BRD 還是最初的版本。新加入的團隊成員讀了 BRD，反而被過時的資訊誤導。
修正方式： 在每個重要里程碑（需求凍結、UAT 開始、上線前）回顧 BRD，確認文件內容與實際執行一致。如果有差異，更新文件並記錄變更原因。把 BRD 視為「活文件」，整合進團隊的知識管理流程中。善用流程圖來視覺化 BRD 的更新觸發條件，能幫助團隊建立更新的習慣。
BRD 品質檢查清單
在送出 BRD 進行審查之前，用這份清單逐項確認：
| 檢查項目 | 狀態 |
|---|---|
| ☐ 每個業務目標都有量化的成功指標 | |
| ☐ 範疇定義同時包含「包含」與「不包含」 | |
| ☐ 所有利害關係人都已列出，且標明角色與關注點 | |
| ☐ 業務需求與技術實作方式明確區分 | |
| ☐ 每條需求都有唯一編號和優先等級 | |
| ☐ 限制條件和假設已明確記錄 | |
| ☐ 風險清單包含機率、影響和應對策略 | |
| ☐ 執行摘要能在一頁內讓決策者掌握全局 | |
| ☐ 文件已設定版本命名規則和更新觸發條件 | |
| ☐ 所有專業術語在附錄詞彙表中有定義 |
這份清單也可以用在審查會議中——讓每位審查者針對這 10 個項目逐一確認，能大幅提升審查效率。如果你習慣用艾森豪矩陣來排優先順序，也可以用同樣的邏輯來決定 BRD 中哪些需求是「重要且緊急」、哪些可以放到下一期。
結論
撰寫 BRD 不是為了產出一份漂亮的文件，而是為了在專案啟動前，讓所有利害關係人對「為什麼做」和「做到什麼程度」達成共識。以下是本文的重點摘要：
- BRD 聚焦業務層面：描述目標、痛點與範疇，不涉及技術實作細節。與 MRD（市場層）和 PRD（產品層）各司其職
- 九大標準章節缺一不可：執行摘要、業務目標、問題陳述、範疇定義、利害關係人、需求清單、限制條件、風險分析、附錄
- 五步驟撰寫流程：需求訪談 → 定義目標 → 起草結構 → 審查簽核 → 版本管理
- 範疇定義是最關鍵的章節：明確寫出「不包含」比「包含」更重要，這是防止需求蔓延的第一道防線
- BRD 是活文件：簽核後不是結束，而是專案執行的基準線，需要隨專案進展持續更新
你的下一步行動：
如果你正準備啟動一個新專案，現在就可以開始。在 monday.com 上建立一個新的 WorkDocs，套用本文的九大章節架構，先把大綱骨架建好。接著安排第一場需求訪談，用我們提供的訪談問題範例來蒐集資訊。整個過程從建立文件到完成初稿，一個中型專案大約需要 2–3 週。
（推薦試試 monday.com 的免費方案，我們團隊實際使用後，BRD 從撰寫到簽核的流程時間縮短了約 40%，主要省在自動化通知和版本追蹤上。）
BRD 業務需求文件常見問題
BRD 和 PRD 有什麼差別？
BRD 描述「為什麼做」和「要達成什麼業務目標」，讀者是業務主管和決策者；PRD 描述「要做什麼功能」和「技術規格」，讀者是工程師和設計師。BRD 用業務語言撰寫，PRD 用技術語言撰寫。兩者是上下游關係：BRD 確認方向後，PRD 才定義細節。
誰應該負責撰寫 BRD？
通常由專案經理（PM）或業務分析師（BA）主導撰寫，但內容需要來自多方利害關係人的輸入。PM 負責整合業務主管的策略方向、終端使用者的操作需求、IT 的技術限制，以及財務的預算框架。最終文件需要專案發起人簽核。
BRD 要寫多詳細、多長？
視專案規模而定。NT$500,000 以下的小型專案，3–5 頁精簡版即可；NT$1,000,000–5,000,000 的中型專案，10–15 頁；超過 NT$5,000,000 的大型專案或合規專案，15–20 頁以上。重點不是頁數，而是每個章節都有足夠的資訊讓利害關係人做決策。
小公司或新創也需要寫 BRD 嗎？
需要，但可以大幅精簡。新創公司的 BRD 可以只保留四個核心章節：業務目標、問題陳述、範疇定義、成功指標。用一頁 A4 就能寫完。重點是讓團隊對「我們要解決什麼問題」和「怎樣算成功」有共識，避免每個人各做各的。
BRD 完成後如何與開發團隊交接？
BRD 簽核後，PM 應召開一場「需求交接會議」，向開發團隊逐一說明業務目標和需求清單。開發團隊根據 BRD 產出 PRD（或 User Story），再由 PM 確認 PRD 的內容是否正確反映 BRD 的意圖。建議使用專案管理工具（如 monday.com 或 ClickUp）將 BRD 需求直接轉為可追蹤的任務，確保每條需求都有對應的開發項目。
