老闆找外包前必備的客製化系統需求書（BRD）完整寫法：8 大關鍵欄位範本、廠商比對表與 30 天採購 SOP

90% 的客製化系統失敗，都不是廠商爛——是需求書爛。

這句話聽起來有點刺，但 Standish Group 追蹤超過五萬個軟體專案的數據就是這麼說的：只有約三成的專案在預算和時程內完成，另外五成超時超預算，兩成直接爛尾。更精確地說，美國軟體工程研究所（SEI）在 IEEE Systems Engineering 系列研究中指出，需求定義不清是軟體專案失敗的頭號原因，佔所有失敗原因的 40% 以上。真正的原因是一開始就沒把「你想要什麼」說清楚，跟技術力不足或廠商偷懶都無關。

老闆去找廠商，通常手上只有一份 PowerPoint 簡報，或者更常見的是——只有一個模糊的想法。「我想做一個系統，讓業務可以快速報價、讓主管可以看數據、讓財務可以出帳單。」這三行字要廠商怎麼估價？怎麼寫合約？怎麼知道三個月後你說「這不是我要的」時，到底是誰的問題？

這篇文章要解決的，正是這個問題。在你花第一塊錢找廠商開發之前，你需要一份像樣的需求書。而「需求書怎麼寫」，是本文的核心——包含 8 大關鍵欄位範本、廠商比對表用法、以及一份 30 天採購前 SOP。

為什麼老闆寫不出好的需求書——3 大盲點

我在恆遠歷年的 6 件系統客製化專案經驗中（涵蓋教育、醫療、製造、電商客戶），每次專案啟動前都會要求客戶先填一份問卷。問卷只有 12 題，大部分老闆填完只有 3-4 題有實質內容。其餘不是空白，就是寫「看廠商建議」。這其實是沒有人告訴他們到底要準備什麼，與老闆本身無關。

盲點一：把「功能清單」當「需求書」

最常見的模式是老闆開一個 Google 試算表，列出「登入功能、報表功能、通知功能、匯出 Excel」，然後說「這就是我的需求」。功能清單是需求書的一部分，但它跳過了最重要的問題：為什麼需要這個功能？誰在用？使用頻率？沒有這些脈絡，廠商只能依照字面意思實作，然後你拿到一個「技術上完全符合功能清單，但完全不符合你工作流程」的系統。

盲點二：以為廠商會幫你想清楚

部分老闆的心態是「我付錢，所以廠商應該問我正確的問題、幫我補全需求」。這個期待在某種程度上是對的——好的廠商確實應該在需求訪談階段協助梳理——但這裡有個時序問題：如果你在需求書一片空白的狀態下就去找廠商開會，你會得到的是廠商「根據自己的系統樣板」做出來的報價，而不是「根據你公司實際流程」做出來的報價。這兩個報價可能差了 50% 以上，並且解決的是完全不同的問題。

盲點三：忽略「驗收標準」的重要性

驗收標準是需求書裡最常被省略的欄位，也是最多糾紛的來源。如果合約裡沒有明確定義「什麼叫完成」，那麼廠商說完成就算完成，老闆說不對廠商就加收變更費用。PMI 的《需求管理與專案成功》研究指出，具備清楚驗收標準的專案，按時交付率比沒有的高出 38%。這個數字背後的邏輯很簡單：有標準才有共識，有共識才有對齊，有對齊才能按計畫走。

BRD、RFP、SOW 三份文件的關係與寫作順序

很多老闆在搜尋「需求書」的時候會遇到三個名詞交替出現：BRD、RFP、SOW。這三個東西不一樣，但很多人把它們混用，結果要廠商回的問題跟廠商能回的問題對不上。

先說清楚定義：

正確的寫作順序是：BRD → RFP → SOW。你先把「你想達成什麼」寫清楚（BRD），再把這份文件發給 3-5 家廠商讓他們提方案（RFP），選定之後再談交付細節（SOW）。很多採購糾紛的根源是直接跳到 SOW，但 BRD 的業務目標從未被清楚定義過。

本文的重點在 BRD——因為這是最前端、最容易被跳過、也最能影響後續所有決策的文件。RFP 和 SOW 等 BRD 完成後再談，否則你在 RFP 裡寫的「功能需求」仍然是空的，廠商收到也只能做假設。

一個有用的比喻：BRD 是建築師手上的「空間需求書」（你想要幾房幾廳、要能停幾台車、預算多少），RFP 是拿著這份需求書去問 5 家設計公司的「方案徵集」，SOW 是跟選定的設計公司簽的「施工說明書」。沒有第一份，後面兩份都是在瞎猜。

需求書 8 大關鍵欄位範本

以下 8 個欄位是一份 BRD 的骨架。重點在於每個欄位都要有實質內容（並非每個欄位都要寫滿 5 頁）——哪怕只有 3-5 條，也比空白好。

欄位 1：業務目標（Business Objectives）

這是整份需求書最重要的欄位，卻也是最容易被跳過的。業務目標其實是這個系統要解決的業務問題，遠遠不只是「我要一個系統」這種說法。

範本提示：「目前客服每天收到約 200 則重複性問題，平均回覆時間 4 小時。我們希望在 6 個月內，把重複性問題的自動回覆率拉到 70%，平均回覆時間縮短至 30 分鐘以內。」

這個欄位要回答：現在的痛點是什麼？期望的成果是什麼？有沒有可量化的 KPI？

欄位 2：範圍定義（Scope）

明確寫出「在這次專案裡要做什麼」以及「不做什麼」。「不做什麼」常常比「做什麼」更重要——它防止廠商把你沒說的東西加進去然後加收費用，也防止你事後說「這個功能我以為包含在裡面」。

範本提示：「本次範圍包含：[功能 A]、[功能 B]、[功能 C]。本次範圍不包含：行動 App、多語言界面、第三方 ERP 系統整合。」

欄位 3：使用者角色（User Roles）

這個系統有哪些人要用？每種角色的使用頻率是多少？這關係到 UI 設計方向和技術架構選擇。一個每天要用 8 小時的後台管理員，和一個每個月才用一次的高管審核者，對系統的要求完全不同。

範本提示：整理成一張表——角色名稱、使用頻率（日/週/月）、關鍵操作（3-5 個）、裝置（PC/手機/平板）。

欄位 4：業務流程（Business Processes）

把現有的工作流程畫出來，標出哪些步驟要被系統取代或支援。不需要畫 UML 圖，一個簡單的「步驟 A → 步驟 B → 決策點 → 步驟 C」就夠。重點是：讓廠商知道你的業務是怎麼運作的，他才能設計符合你工作邏輯的系統，而不是讓你的工作邏輯去配合他設計的系統。

欄位 5：資料需求（Data Requirements）

系統會處理哪些資料？這些資料現在在哪裡？要不要遷移舊資料？這個欄位很多老闆會忽略，但它直接影響開發工時。如果你有 10 萬筆歷史訂單資料要從 Excel 遷移進新系統，這是一個獨立的工程，應該在需求書裡明確提出，而不是等簽完合約後才說「對了，我們還有舊資料要搬」。

欄位 6：系統整合（System Integrations）

新系統需要跟哪些現有系統對接？例如：現有的 ERP、CRM、電商平台、金流系統、倉儲系統。每一個整合點都是額外的工程，廠商需要知道才能準確估價。

範本提示：列出現有系統名稱、廠商、是否有 API 文件、對接方向（單向同步 / 雙向同步）。如果不確定，就寫「待確認」，比完全不提要好。

欄位 7：驗收標準（Acceptance Criteria）

這是最容易被跳過但最重要的欄位。每個主要功能都要有對應的驗收條件——具體寫法是「在測試環境輸入 X 資料，系統輸出 Y 結果，誤差在 Z 以內」，遠遠不能只用「功能正常」這種籠統說法帶過。

範本提示：「報表功能驗收：輸入 2025/01-2025/03 的銷售資料，系統應在 5 秒內生成含折線圖與匯出 Excel 按鈕的報表頁面。」

欄位 8：預算與時程（Budget & Timeline）

預算要不要寫進需求書？這是大部分老闆最糾結的問題，後面的 FAQ 會專門回答。這裡先說：預算範圍（例如「200-400 萬台幣」）可以寫，精確數字不用給。時程方面，要寫的是「業務端的硬性死線」（例如：某個展覽、某個法規上路日期），而不是「越快越好」這種沒有意義的表達。

廠商比對表：6 維度評分模型

拿到 3-5 家廠商的提案之後，怎麼比？很多老闆最後的選擇標準變成「最便宜的」或「感覺最順眼的」——這兩個標準都有問題。最便宜的往往是報價最低但後來追加費用最多；「感覺好」是主觀的，在幾百萬的採購決策裡不是一個可靠的依據。

以下 6 維度評分模型，可以讓你把廠商比對從「感覺」變成「可追蹤的決策記錄」：

把每家廠商照這 6 個維度評分，再加上一欄「直覺分（1-5）」做最後微調。這個模型的好處不只是選出最適合的廠商——它同時也是一份採購決策記錄，日後出現爭議時，你可以說「當初我們選擇你的原因是 XX，現在你在 XX 維度沒有達到預期」。

延伸閱讀：如果你的採購需求是 AI 系統，可以參考AI 顧問 vs AI 系統開發商分工指南，了解「你需要的到底是顧問還是開發商」這個更前端的決策節點。

30 天採購前準備 SOP（Week 1-4 行動清單）

「30 天」不是隨便設的時間軸。根據PMI 的專案管理基準研究，需求定義階段每多投入一個小時，可以在後期節省約 10 個小時的返工時間。30 天的準備期，在整個系統開發週期（通常 3-12 個月）裡，是值得的前置投資。

Week 1：現況盤點（第 1-7 天）

• 列出現有的工作流程（把「現在怎麼做的」全部寫下來，不管多醜）
• 統計現在用什麼工具：Excel？Line？手寫？白板？各別找出它的使用量和痛點
• 訪談 3-5 位最頻繁使用流程的員工，問他們「最花時間的步驟是哪三個」
• 收集現有資料：有哪些 Excel 表、資料庫、系統，裡面有哪些資料，資料品質如何
• 確認 IT 環境：現有的伺服器、雲端帳號、既有系統清單（這影響技術選型）

Week 2：需求草稿（第 8-14 天）

• 用第一周的盤點結果填寫 BRD 欄位 1-4（業務目標、範圍、使用者角色、業務流程）
• 初步列出功能清單——從「最痛的流程」開始，不要一開始就想做最大最完整的版本
• 確定預算範圍（建議方法：查詢同類系統的市場行情，設定心理預算區間）
• 確定時程硬線（有沒有某個外部死線？展覽、法規、合作夥伴要求？）
• 初步整理整合需求：現有系統清單 + 哪些需要對接

Week 3：需求審查（第 15-21 天）

• 把 BRD 草稿分給 2-3 位內部利害關係人（財務、IT、業務主管）審閱
• 開一場 1.5 小時的「需求確認會議」，逐欄討論，紀錄所有歧異點
• 特別確認驗收標準（欄位 7）——這通常是最難達成共識的一欄
• 確認 NDA 簽署時序（詢價前 or 詢價後？——詳見 FAQ）
• 準備廠商短名單：詢問同行推薦、查 Google 評價、看 portfolio 案例，初步列出 5-8 家

Week 4：詢價準備（第 22-30 天）

• 把 BRD 轉成 RFP（加上「請廠商回覆的問題清單」和「提案格式要求」）
• 將廠商短名單縮減至 3-5 家（這是詢價的合理數量，太多容易比較疲勞）
• 發出 RFP，設定回覆截止日（建議給廠商 10-14 天的回覆時間）
• 準備廠商比對表（用上面的 6 維度模型建立評分表格）
• 安排廠商簡報：收到提案後，安排 30-45 分鐘的線上簡報，深問 2-3 個你最在意的問題

需求書防呆檢核：10 個寫完必問自己的問題

在把需求書發給廠商之前，過一遍這份自問清單。每一個問題背後都有真實的採購糾紛案例。

• 業務目標有沒有量化指標？「提高效率」不算，「把某個流程從 40 分鐘縮短到 5 分鐘以內」才算。
• 範圍有沒有「不做什麼」的清單？缺少這一欄，後期追加費用的爭議至少多 50%。
• 每個使用者角色都有對應的關鍵操作描述嗎？少了這個，UI 設計方向就是在猜。
• 業務流程有沒有標出「系統要介入的步驟」？不是每個步驟都要系統做，標出來才能讓廠商知道邊界。
• 舊資料遷移的需求有沒有說清楚？資料遷移常常是報價後才被加進來的大頭，要事前說清楚。
• 整合清單有沒有包含「這個系統是否有 API 文件」的資訊？沒有 API 文件的舊系統整合，廠商通常需要多算 20-40% 的費用。
• 每個主要功能都有可測試的驗收條件嗎？「功能正常」不是驗收條件，「輸入 X 得到 Y」才是。
• 預算範圍的設定是根據市場行情，還是心中隨機想的數字？如果沒有概念，先問 2-3 家廠商做大概的市場行情了解，再定預算。
• 有沒有列出時程的硬性限制和彈性空間？「越快越好」不是時程，「2026/09/01 前要上線因為有展覽」才是。
• 這份需求書，你能解釋給一個從來沒見過你業務的人聽嗎？能的話，廠商就能看懂；不能的話，廠商只能猜。

需求書交出去後：如何讀廠商的問題回函

一份好的需求書發出去後，好的廠商不會直接給你報價——他們會先回一份「澄清問題清單」（Clarification Questions）。這份清單是判斷廠商水準的最直接指標。

怎麼讀這份清單？

問題的深度代表理解度

問「登入功能要支援幾種角色？」是基本盡職，代表廠商有看文件。問「欄位 4 第三個流程步驟裡，您提到『主管審核』——這個審核結果是否需要通知申請人？通知方式要 email 還是系統內訊息？」這種細節問題，代表廠商真的理解你的業務流程，而不只是在套樣板。

問的問題類型代表技術取向

如果廠商的問題集中在「技術架構選型」（用哪種資料庫、要不要容器化、監控方案用什麼），代表他們在認真思考長期維護性。如果問題都集中在「前端 UI 設計風格」，可能代表這家公司是以設計見長而不是以工程見長——這跟你要做的系統屬性是否匹配？

沒有問題也是資訊

如果一家廠商收到你的 RFP 後直接給你報價，完全沒有澄清問題——這是一個警訊。可能代表：他們有固定樣板，你的需求書對他們來說是「參考用」而不是「設計依據」；也可能代表他們對你的行業完全不了解，但假裝了解。

建議在收到廠商提案後，安排一場 30-45 分鐘的「提案深問會」，問 2-3 個你最在意的技術或流程問題，觀察廠商如何當場回應。這比看書面提案更能判斷廠商的真實能力。如果是 AI 系統開發的需求，可以先參考找外包做 AI 專案的完整報價框架，了解不同類型 AI 專案的估時方法和合約紅線。

真實案例：教育產業客戶的需求書從 3 頁到 12 頁，開發週期省 40%

在恆遠的 6 件系統客製化專案中，有一件是替教育業客戶開發補課系統（見我們的 portfolio）。這個案例展示了完善需求書對開發效率的實際影響。

這家教育業客戶第一次來找我們時，帶的是一份 3 頁的 Word 文件，內容主要是：「希望有學生補課申請、老師確認、家長通知、繳費記錄四個功能」。就這樣。沒有業務目標、沒有使用者角色細分、沒有現有流程說明、沒有驗收標準。

我們沒有接受這份需求書直接開估價單。我們花了 4 次需求訪談、共約 6 小時，把這 3 頁文件擴展成 12 頁的完整 BRD，新增了：

• 使用者角色細分（學生、家長、授課老師、行政人員——各自的操作需求完全不同）
• 現有流程痛點（舊流程用 Line 群組加 Excel 管理，每學期有約 15% 的申請錯誤率）
• 驗收標準（申請流程不得超過 3 步操作、通知在 5 分鐘內送達）
• 整合需求（需對接既有的繳費金流系統）
• 資料需求（現有 3 年的學生資料要遷移進新系統）

最後的開發結果：從第一版 BRD 確認到系統上線，花了 4 個月。後來客戶自己說，「如果一開始沒有把流程想清楚，這個專案大概會多拖 2 個月」——這正是 40% 的開發週期節省從哪裡來的。

這個案例最讓我們印象深刻的環節，其實是需求訪談的過程本身，而非最後的技術成果。第三次訪談時，行政人員才說出「我們其實有一個紙本紀錄表，每個老師的補課費率都不一樣，這個要進系統嗎？」——這個細節在第一份 3 頁文件裡完全沒有提到，但它直接影響了後端計費邏輯的設計。晚一個月才發現，估計要多花 3 週返工。

如果你的需求是 BI 報表或數據 Dashboard 系統，可以參考客製化 BI 報表與資料 Dashboard 系統開發指南，了解資料需求欄位的詳細展開方式。

常見問題 FAQ

延伸閱讀：這篇的互補文章

這篇文章專注在「老闆採購前的準備——需求書怎麼寫」。如果你還在評估其他面向，以下四篇文章各自補足不同的切角：

• 客製化 SaaS 軟體即服務開發完整指南（#518）— 廠商實作角度：SaaS 架構怎麼選、6 個關鍵技術決策
• 找外包做 AI 專案完整報價框架（#505）— 預算與估時角度：6 種 AI 專案類型的報價區間與合約紅線
• 找外包做 AI 系統的 7 個坑（#418）— 踩坑角度：從 POC 到上線最常出問題的 7 個節點
• AI 顧問 vs AI 系統開發商分工指南（#544）— 角色分工角度：你的 AI 需求應該找顧問還是開發商

如果你的系統需求涉及 CRM，也可以參考CRM 系統客製化完整指南；如果涉及派工或工單管理，可以參考客製化派工/工單系統開發完整指南。

看到這裡，如果你正在準備找廠商開發客製化系統，可以先把今天學到的 8 大欄位框架填個初稿——哪怕只有 30% 完整，也比一片空白的「我要一個系統」要好很多倍。填完之後，把你的初稿丟給我們看看，我們可以幫你找出最關鍵的補強點，告訴你這個規模的系統大概是什麼量級，從哪裡開始最划算。