系統開發規格書怎麼寫？老闆該寫哪幾頁、哪些交給廠商

一份兩頁的 Word 檔，寫著「做一套進銷存，要能管庫存、出報表，業務在外面用手機也能查」，寄給三家廠商。一週後回來三份報價，最便宜和最貴的差了好幾倍，三家都說完全符合需求。老闆拿著報價單看不出差在哪，最後挑了中間那家。這種情況在初次洽談時很常見，問題通常不在廠商，而在那兩頁 Word：同一句「要能管庫存」，有人理解成記帳表，有人理解成要接倉庫掃碼和會計系統的營運中樞。

系統開發規格書不需要老闆從頭寫完。完整的軟體需求規格書是工程文件，該由廠商或負責系統分析的人在訪談後整理；老闆要自己寫的是需求說明，內容只有五件事：這次要解決什麼、誰會用、現在怎麼做、有哪些規則與例外、怎樣算做完。其中「規則與例外」和「怎樣算做完」最常被省略，也是報價對不上、驗收起爭執的主要來源。下面依序說明每份文件由誰負責、要寫到多細，以及怎麼把模糊的句子改成可以驗收的寫法。本文引用的標準與公部門文件查證於 2026 年 11 月 9 日。

規格書、需求說明、RFP，先分清楚要寫的是哪一份

老闆該自己寫的是需求說明，軟體需求規格書由廠商或系統分析人員在訪談後整理。

「規格書」在台灣是個被用得很寬的詞。老闆說的規格書、廠商說的規格書、政府標案裡的需求說明書，指的常常不是同一份東西。分清楚之後，就知道哪些該自己寫，哪些可以要求廠商交出來。

1. 老闆寫五件事需求說明
2. 需求訪談
3. 廠商整理工程文件
4. 雙方簽認之後才報價

圖：老闆負責左邊五件事，右邊的工程文件由廠商在訪談後整理，雙方簽認後才報價。

文件	通常誰寫	寫什麼	什麼時候用
需求說明（需求摘要）	老闆或專案窗口	目標、使用者、現況、規則與例外、驗收條件	找廠商、第一次洽談前後
招標需求說明書（RFP）	採購單位	需求說明，加上廠商資格、時程、預算與評選方式	正式比價或政府標案
軟體需求規格書（SRS）	廠商或系統分析人員	功能需求、非功能需求、外部介面、資料、限制與假設	訪談之後、開發之前
功能清單與畫面草圖	廠商	每個功能做什麼、主要畫面長什麼樣子	報價與簽約的依據
驗收清單	廠商擬稿、雙方確認	每項功能用什麼情境測、什麼結果算通過	每個階段驗收

SRS 有國際標準可以參考。早年常見的是 IEEE 830，2011 年由 ISO/IEC/IEEE 29148 取代，目前通行的是 2018 年版，維基百科的 SRS 條目有這段演變的整理。Asana 的軟體需求規格書範本把結構簡化成引言與目的、整體描述、功能需求、非功能需求、外部介面、限制與假設幾個章節，拿來當目錄很方便。只是這套結構是寫給工程團隊讀的，老闆照著填，常卡在「非功能需求」「外部介面」這種看不懂的欄位，最後乾脆留白。

老闆該自己寫的五件事

需求說明可以用口語寫，其中規則與例外和怎樣算做完最常被省略。

每一件都可以用口語寫，不需要表格，也不用懂技術詞。篇幅不必平均，規則與例外那一段通常最長，目標那一段兩句就夠。

目標與範圍：這次要解決什麼，不做什麼

例如「業務報價從 Excel 改到系統上，主管能即時看到每張報價走到哪一步」。比目標更有用的是「這次不做什麼」：會計帳不進系統、先不做給客戶用的網頁、只處理台灣門市。範圍邊界寫出來，廠商才不會把它們當成風險算進報價，驗收時也不會被拿出來爭。

誰會用：角色、人數、誰能看到什麼

列出每種角色每天在系統裡做什麼，以及大概有幾個人。我們做需求訪談時固定會問三個問題：誰輸入、誰審核、誰查看。三個角色一分開，權限該怎麼切就浮出來了，例如業務只能看自己的客戶，主管看得到全部但不能改金額，會計只看已成交的單。人數也要寫，十個人用和兩百個人同時用，架構與主機的考量完全不同。

現在怎麼做：直接附上真實的檔案

現在用的 Excel、紙本表單、LINE 群組裡交辦事情的對話截圖，都是最好的需求文件。不用整理，原樣附上就好，記得把客戶個資遮掉。廠商看到真實的欄位與格式，比讀十段描述更準。試算表轉成資料庫要考慮哪些事，我們在Excel 只是試算表不是資料庫寫過；如果現有的幾套工具之間已經在互相同步，也要一併寫出來，資料打架的常見原因整理在ERP、CRM、官網為何老是打架。

規則與例外：最常漏、也最貴的一段

規則是「正常情況怎麼走」，例外是「不正常的時候怎麼辦」。大部分需求說明只寫了前者。

我們替元智大學終身教育部做排課系統時，起點是一份教師課表 Excel。真正花時間的不是畫課表的格子，而是把每一格背後的條件找出來：老師同一時段在別班已經有課、教室被佔用、排到國定假日、七天內上課天數不夠。這些條件最後依嚴重程度分成阻擋、警告、提醒三級，系統各用不同方式處理。老師的條件又有兩種講法，有人說「週三不行」，有人說「只能排週六」。只支援其中一種，系統也跑得動，但承辦人就得把另一種硬轉過去，很容易出錯，所以兩種我們都做了。完整過程寫在元智大學排課系統案例。

這一段可以用「如果……就……」的句型逐條列：如果客戶超過信用額度，訂單要主管核准；如果退貨超過七天，只能換貨不能退款。寫到一半發現說不清楚的規則，正好是需求訪談時要優先問的地方，不用等想清楚才交出去。

• 如果客戶超過信用額度訂單要主管核准
• 如果退貨超過七天只能換貨不能退款

用「如果……就……」的句型逐條列出規則與例外

怎樣算完成：寫成可以測的句子

「系統要好用」「速度要快」沒辦法驗收。改成「業務在手機上可以建立一張含五個品項的報價單，送出後主管馬上收到通知」，雙方手上就有同一把尺。Asana 的範本也把「可測試」列為需求的基本條件，也就是能用具體測試驗證是否達成。驗收條件寫得越早，估價越準，因為每一句都直接對應到要做、要測的工作。

需求說明的完成條件，要寫成可以測的句子

寫不清楚會出什麼事：公部門稽核點名的規格缺失

工程會整理的資訊服務採購缺失，有好幾種民間公司找廠商做系統時一樣會踩到。

政府的資訊服務採購有一整套作業規範，規格問題還是年年被稽核挑出來。行政院公共工程委員會 2024 年 1 月發給各機關的〈採購稽核發現缺失類型及案例：資訊服務採購缺失類型〉整理了 14 種缺失，其中好幾種，民間公司找廠商做系統時一樣會踩到。

• 需求寫得籠統，沒有具體基準。

  文件舉的例子是要求服務「維持系統瀏覽順暢」這類描述，稽核意見認為機關因此難以要求履約品質，應訂明成果要達到的標準與數據。

• 現有系統資訊寫太少。

  有個維護擴充案只寫了系統放在哪個資料中心、用虛擬主機建置，稽核認為原廠商以外的廠商不容易備標。民間的版本是：舊系統用什麼做的、資料有多少筆、原始碼在誰手上，沒寫出來，新廠商只能保守估價。

• 服務水準沒有寫。

  文件建議載明的項目包括正常運作時間百分比、修復時間、系統反應時間、錯誤率、跨平台與跨瀏覽器支援程度。

• 把維護修理和保固混在一起。

  文件引用資訊服務採購契約範本第 13 條：保固從驗收合格日起算，期限內發現瑕疵由廠商免費改正；新增功能、技術諮詢屬於維護服務，不是保固。

工程會點名的資訊服務採購規格缺失中，民間找廠商做系統也會踩到的幾種

最後一條值得多看一眼。有機關在招標文件寫「新增功能的程式在總程式支數 15% 範圍內不另付費」，稽核指出這不屬於保固範圍，而且遠高於契約範本第 3 條的做法：功能數調整達 5% 以上，才就超過的部分按比例增減價金。民間合約沒有範本可以套，道理卻相同：功能變更怎麼算錢，要在規格與合約裡先講好，不要塞進保固裡讓其中一方吃虧。

• 15%有機關寫新增功能在總程式支數這個範圍內不另付費稽核指出不屬於保固
• 5%以上的功能數調整，才就超過的部分按比例增減價金契約範本第 3 條

功能變更怎麼算錢：招標文件寫法與資訊服務採購契約範本的差距

模糊寫法改成可驗收寫法：一張對照表

可以驗收的需求寫法，要從「想要」寫到怎麼確認做到了。

下面是需求說明裡最常見的幾種句子。左欄不是錯，只是停在「想要」，還沒寫到「怎麼確認做到了」。

常見寫法	問題在哪	改成這樣
系統要快	沒有基準，誰都能說有達到	指定動作與資料量，例如一千筆訂單以內的查詢，幾秒內要出結果
手機也能用	不知道是哪些功能、哪些裝置	列出手機上要能做的動作，例如查庫存、建立報價；註明用瀏覽器開，或是要裝 App
報表要能匯出	哪張報表、什麼欄位、什麼格式都沒說	附上現在用的報表樣本，指定匯出成 Excel 或 PDF
權限要分清楚	角色和動作沒有對應	列一張角色對動作的表：誰能新增、修改、刪除、查看
要串接會計系統	系統名稱、有沒有 API 都不知道	寫出系統名稱與版本、目前怎麼匯出資料、誰能提供測試帳號
介面要好看	主觀，驗收時各說各話	附兩三個喜歡的參考畫面，說明喜歡的是哪裡
資料要安全	範圍太大，沒辦法估工	寫出哪些是敏感資料、哪些人不能看、要不要保留操作紀錄

串接那一列最容易被低估。舊系統沒有 API 時，要嘛改寫，要嘛用畫面自動化去接，兩種做法的取捨在沒有 API 的老舊系統，重寫還是畫面自動化串接有比較。光是確認舊系統能不能吐出資料，有時就要花上幾次往返，越早寫進需求說明越好。

交給廠商寫的部分，老闆要怎麼檢查

檢查廠商交回的規格文件，最有效的方式是拿上個月的真實單據走一遍。

訪談之後，廠商應該交回幾份東西：功能清單、關鍵畫面草圖、資料欄位、串接規格、分階段時程與驗收清單。我們自己的流程也是這個順序，先交需求摘要，再交功能清單、關鍵畫面草圖、分階段時程與驗收清單，最後才是報價。順序反過來、先給數字再談內容的報價，通常只是估個大概。

1. 需求摘要
2. 功能清單
3. 畫面草圖關鍵畫面
4. 時程與驗收清單分階段
5. 報價

這些文件不必逐字讀懂。最有效的檢查方式是拿上個月的真實單據走一遍：挑十張狀況不同的訂單，包括被退貨的、改過價的、拆單出貨的，一張一張問「這張在新系統裡怎麼處理」。功能清單或畫面草圖找不到答案的，就是漏掉的需求。

另外留意清單有沒有寫「這次不做什麼」，以及驗收清單是不是每一條都能用操作測出來。報價單上的項目怎麼對回功能清單，可以參考報價單怎麼看，那篇以網站為例，比對方法一樣適用於系統。

規格要寫多細，看系統是哪一種

規格書要寫多細，看系統出錯的代價有多大，以及要接多少既有系統。

不是每個系統都需要厚厚一本規格書。判斷依據有兩個：系統出錯的代價有多大，以及要接多少既有系統。

部門內的小工具

例如活動報名、內部表單、簡單的預約。一兩頁需求說明加上現有的 Excel 樣本就夠，畫面草圖確認後就能開工。這種規模也值得先問一句：現成的 SaaS 是不是已經能解決。

跨部門的營運系統

例如進銷存、CRM、排程派工。需要完整的功能清單、角色權限表和驗收清單，建議把需求訪談與規劃當成獨立的第一階段，規劃完再決定開發範圍。我們在客製化系統開發的做法也是先規劃、再分階段開發，每一階段驗收過才往下做。要買現成還是客製，台灣中小企業 CRM 怎麼選用 HubSpot、Salesforce 和客製系統做過比較。

取代舊系統，或要串接好幾套系統

規格裡要多一份現況盤點：舊系統的資料表、新舊欄位對照、資料量，以及目前誰在用哪些功能。資料搬遷常常比開發新功能還花時間，報價落差也多半出在這裡，費用由哪些項目組成，可以看客製化系統開發費用怎麼算的拆解。

公司如果有自己的工程師，規格書的分工又不一樣，內部人員可以直接寫 SRS，廠商只負責其中一段。外包和自建怎麼取捨，整理在系統要外包還是自己養工程師。

規格書寫完之後：放進合約，變更要留紀錄

系統規格書最後要成為合約的附件，開發中改規格要雙方確認後才動工。

規格書最後要成為合約的附件，否則寫得再好也只是參考。合約裡要寫清楚規格的版本、驗收方式，以及開發中要改規格時怎麼處理：提出變更、評估對時程與費用的影響、雙方確認後才動工。原始碼與著作權歸屬、保固和維護的分界，外包合約要注意什麼有逐條說明。

1. 提出變更
2. 評估影響時程與費用
3. 雙方確認
4. 動工

規格書也不是簽完就封存。開發中一定會改，每改一次就更新版本、記下為什麼改。這份文件像是系統的病歷，上線兩三年後要擴充功能，不管是原本的團隊還是新接手的人，都靠它判斷哪裡能動、哪裡不能碰。從聊需求到上線大致會經過哪些階段，可以對照網站製作要多久，系統專案的階段相同，只是訪談與驗收的份量更重。

回到開頭那三份差了好幾倍的報價。要讓它們比得出差別，用不著去找一份更厚的範本，先把五件事寫下來，再要求每家廠商交回功能清單與驗收清單。哪一家交得出來、交出來的東西能讓上個月的單據一張張走得通，比報價高低更能說明對方懂不懂這門生意。

資料來源與查證日期

• 行政院公共工程委員會：採購稽核發現缺失類型及案例（資訊服務採購），113 年 1 月 26 日工程稽字第 1121300303 號函附件
• Asana：軟體需求規格書範本與撰寫方式
• Wikipedia：Software requirements specification（IEEE 830 與 ISO/IEC/IEEE 29148 的沿革）

以上資料查證於 2026 年 11 月 9 日，公部門規範如有修訂，以工程會最新公告為準。

延伸閱讀

• 客製化系統開發費用怎麼算？中小企業預算與低價陷阱指南
• 網站外包合約要注意什麼？著作權、原始碼、驗收與付款怎麼寫
• 系統要外包還是自己養工程師？中小企業的成本與風險比較
• Laravel 企業級客製開發完整指南：SaaS 撐不住之後，系統該怎麼做