同一個案子找三家廠商報價，拿到三十萬、八十萬、一百五十萬三個數字，這種事我們聽過太多次。客戶的第一反應是「到底誰在亂報」，但多數時候三家都沒亂報，他們只是各自想像了一套不同的系統。需求規格書（常簡稱規格書或 SRS）就是用來消除這種想像落差的文件：它把一套系統要給誰用、要完成哪些事、做到什麼程度算完成寫成文字，作為報價、開發與驗收的共同依據。這篇講的是非技術背景的業主怎麼把它寫到「夠用」。
重點摘要
- 需求規格書的目的是讓不同廠商對同一套系統有相同的理解，報價才能互相比較，驗收才有依據。
- 業主不需要寫技術規格，但要寫清楚使用角色、每個功能的目的與驗收條件、資料來源與例外情況。
- 最常漏掉的是例外流程、後台權限、既有資料轉移與上線後的維護，這些也是追加費用的主要來源。
- 需求真的講不清楚時，先付費做需求訪談或規劃階段，比直接簽總價合約安全。
需求規格書要寫到多細才夠？
細到「一位沒參加過會議的工程師讀完，做出來的東西不會讓你嚇一跳」。這個標準聽起來主觀，實際上很好檢驗：把文件拿給公司裡沒參與討論的同事讀，請他講一遍系統怎麼運作，講不出來或講錯的地方，就是還要補的地方。
不需要寫的東西也要講明白。用什麼程式語言、資料表怎麼設計、畫面要用哪種按鈕，這些是廠商的專業，業主寫了反而綁手綁腳。業主負責講清楚「要解決什麼問題、誰來用、怎樣算完成」，廠商負責提出「怎麼做」。一份十到二十頁、寫對重點的規格書，比一百頁的畫面截圖有用。
一份夠用的規格書有哪些章節？
七個章節就能涵蓋大部分的中小型專案。下表右欄是我們實際看過的後果，可以用來判斷哪一章你最不能省。
| 章節 | 要寫什麼 | 沒寫的後果 |
|---|---|---|
| 背景與目標 | 現在怎麼做、痛在哪、做完要改善什麼 | 廠商只照字面做，解不到真正的問題 |
| 使用角色 | 有哪幾種人會用、各自能看與能改什麼 | 權限事後補，動到整個架構 |
| 流程 | 主要流程的步驟圖，含退回與取消 | 只做了順利的那條路 |
| 功能清單 | 每項功能的描述、優先順序、驗收條件 | 驗收時各說各話 |
| 資料與串接 | 舊資料要不要搬、要接哪些外部系統 | 上線前才發現金流、發票、POS 接不起來 |
| 非功能需求 | 使用人數、速度、裝置、備份、資安要求 | 功能都有，但慢到不能用 |
| 範圍外事項 | 這一期明確不做的東西 | 雙方對「應該有包含」認知不同 |
最後一章「範圍外事項」是最被低估的一章。把「本期不含 App、不含多語系、不含與會計系統串接」明寫出來，能擋掉一大半的爭議。
功能該怎麼描述，廠商才看得懂？
用「誰、要做什麼、為了什麼」三段式寫，再補上驗收條件。這個寫法在軟體業叫使用者故事，英國政府的數位服務手冊有一頁很精簡的 使用者故事寫法說明，其中特別強調「為了什麼」是三段裡最重要的一段，因為它決定了你是不是在解對的問題。
舉個例子。「要有訂單查詢功能」這句話幾乎沒有資訊量。改寫成：「門市人員要能用客人的手機號碼查到他最近的訂單，為了在客人來電時三十秒內回答出貨進度。」廠商馬上知道查詢條件是手機、使用者是門市人員、速度很重要。接著補驗收條件：輸入手機號碼後列出最近十筆訂單；每筆顯示狀態與物流單號；查不到時顯示「查無資料」而不是空白頁；門市人員只看得到自己門市的訂單。
驗收條件要寫成可以打勾的句子，不要寫形容詞。「操作要流暢」「介面要直覺」沒有人能驗收；「列表在三秒內載入」「手機直式畫面不需要左右捲動」才可以。每個功能再標上優先順序（一定要、最好有、以後再說），預算不夠時才知道從哪裡砍。
哪些需求最容易漏掉？
例外情況、後台與舊資料，這三類幾乎每個案子都會漏。業主在想系統的時候，腦中跑的是一切順利的畫面：客人下單、付款、出貨。但真正吃掉工時的是不順利的時候：付款失敗怎麼辦、訂單成立後要改地址、出貨後要部分退款、兩個人同時改同一筆資料。規格書上每一條流程，都值得多問一句「如果這一步失敗或反悔呢」。
後台是第二個黑洞。前台畫面大家都會想，但誰來上架商品、誰能改價格、誰能匯出名單、報表要看哪些數字，常常到開發中期才被提起。舊資料則是第三個：現有的 Excel 或舊系統裡的會員與訂單要不要搬進新系統、格式乾不乾淨、誰負責整理，這件事的工作量有時不亞於開發一個模組。會員相關的系統可以對照 會員系統該有哪些功能 逐層檢查。
常見錯誤：只丟一句話，或只丟一疊畫面
兩個極端都會出事。一句話型的需求像是「做一個類似某某平台的系統」，問題在於那個平台背後是幾十人做了好幾年的成果，廠商只能猜你要的是其中哪百分之五，於是報價天差地遠。這不是廠商不專業，是資訊不足時每個人補上的假設不同。
畫面型的需求看起來認真得多，業主自己用簡報畫了二十頁畫面。但畫面只說了「長什麼樣」，沒說「按下去之後發生什麼」。按鈕背後的規則、資料從哪來、誰有權限按，全都不在圖上。我們遇過的典型情況是：畫面上有一個「匯出報表」按鈕，業主心裡想的是十二種可自訂欄位的報表，廠商估的是一份固定格式的 Excel。畫面可以當輔助，規則一定要用文字寫。
自己真的寫不出來怎麼辦？
把「寫規格」本身當成一個獨立的小案子來發包。也就是先付一筆相對小的費用，請顧問或開發商做需求訪談、流程整理與規格撰寫，產出的文件歸你所有，之後可以拿去給任何廠商報價。這個階段通常兩到四週，費用占整體開發的一小部分，卻能大幅降低後面追加與重做的機率。
我們不建議的做法是：需求還模糊，就為了趕時程先簽一個總價合約。總價是根據當下的理解報的，理解一變，不是廠商吸收成本後品質下降，就是業主不斷被追加。如果連要不要自己開發都還沒確定，可以先讀 客製系統 vs SaaS 訂閱，有時候答案是根本不用寫這份規格。
規格書寫完之後要怎麼用？
它有三個用途：比價的基準、合約的附件、變更的對照。比價時把同一份文件發給每家廠商，並請他們列出「哪些項目有疑問」與「哪些假設」，回覆的品質本身就是很好的篩選依據，問題問得越具體的廠商通常越可靠。
簽約時把規格書列為附件，驗收就以它為準。開發過程中一定會有新想法，這很正常，重點是每一次變更都留下紀錄：改了什麼、影響多少時程與費用、雙方誰確認的。口頭說好的變更是日後爭議最大的來源。合約裡關於維護與原始碼的條款同樣要在這個階段談定，細節整理在 系統維護合約與原始碼歸屬。
規格書送出前的自我檢查：
- 沒參與討論的同事讀完，能正確說出系統的主要流程嗎？
- 每一種使用角色能看什麼、能改什麼，都列出來了嗎？
- 每個功能都有可以打勾的驗收條件，而不是形容詞嗎？
- 每條流程的失敗、取消、退回情況有寫到嗎？
- 舊資料要不要轉移、由誰整理，決定了嗎？
- 要串接的外部系統（金流、發票、LINE、POS）有列出名稱與版本嗎？
- 預計的使用人數與尖峰時段寫了嗎？
- 「這一期不做」的項目有明列嗎？
常見問題
需求規格書應該由業主寫還是廠商寫？
業務內容由業主提供，文件可以由廠商或顧問執筆。只有業主清楚自己的流程與規則，這部分沒有人能代勞；但把它整理成結構化文件是專業工作，交給有經驗的人寫會更完整。不論誰寫，最後都要由業主逐條確認。
規格還沒完全確定，可以先請廠商報價嗎？
可以，但請把它當成粗估而不是承諾。需求模糊時拿到的報價通常是一個區間，適合用來判斷預算等級。要簽總價合約之前，還是需要一份雙方確認過的規格，否則後續追加幾乎無法避免。
規格書需要附上畫面設計稿嗎？
不需要正式設計稿，簡單的線框草圖就有幫助。草圖的用途是讓雙方確認每個畫面有哪些資訊與操作，視覺設計是開發階段的工作。如果手邊有喜歡的參考網站或 App，附上連結並說明喜歡哪一點即可。