需求規格書是系統或 APP 外包前，用來說明「要做什麼、給誰用、做到什麼程度才算完成」的文件，也是廠商估價、開發與驗收的共同依據。寫法的重點不在篇幅，而在每一條需求都能被檢驗：先交代專案目的與範圍，再列出使用角色、功能需求與非功能需求，附上流程圖與畫面草圖，再替每項功能寫下驗收條件。就算只完成精簡版，也能讓不同廠商在同一個基礎上報價。
動筆前先釐清：目的、範圍與使用角色
需求規格書不是功能願望清單。動筆前先用幾句話回答三件事，後面的章節才有依據：
- 專案目的：要解決什麼問題，例如訂單靠人工對帳容易出錯、客戶查不到處理進度。目的寫清楚，廠商才能判斷哪些功能是必要的。
- 範圍邊界：這次要做哪些、不做哪些，以及要沿用或串接哪些既有系統。「不做」的項目也要寫，避免估價時各自想像。
- 使用角色：列出會操作系統的人，例如顧客、客服、主管、系統管理員，以及各自能看、能改哪些資料。
建議讓實際使用者參與訪談，把現行作業走一遍，記下每個步驟用什麼表單、誰確認、哪裡常出錯，這些紀錄就是功能需求的原料。
需求規格書的章節架構
各團隊的格式不一，下面是外包專案常用的章節順序，可依規模增減：
- 專案概述：背景、目的、範圍與名詞定義。
- 使用角色與權限：角色清單，以及每個角色可以執行的動作。
- 作業流程：現行流程與導入後的流程，各附一張流程圖。
- 功能需求：依模組分節，每項功能有編號、說明、優先順序與驗收條件。
- 非功能需求：效能、資安、相容性、無障礙與維運要求。
- 資料與介接：主要資料欄位、資料來源、要串接的外部系統與匯入匯出格式。
- 畫面草圖：主要頁面的線框圖與操作順序。
- 時程、交付物與驗收方式：分階段交付的內容、測試方式與驗收文件。
每項需求給固定編號，報價、測試紀錄與變更單都引用同一個編號，日後追查就不必翻找會議紀錄。
功能需求怎麼寫：一句一事、可以檢驗
美國航太總署（NASA）系統工程手冊的需求撰寫檢核清單，有幾條可以直接套用在功能需求上：每一句只表達一件事；寫「需要什麼」，不寫「怎麼做」；避免「等」「適當的」「及／或」這類範圍不明的字眼；不用「好用」「快速」「足夠」這類無法驗證的形容詞；並附上需求的理由與前提。
寫法上可以先用使用者故事描述情境，再補驗收條件。敏捷聯盟（Agile Alliance）整理的使用者故事格式是「身為某角色，我想要做某件事，以便達成某個目的」；驗收測試則可用 Given、When、Then 三段，分別寫出前提情境、執行的動作與可觀察的結果。以下是一則需求規格書範例：
- 需求：身為客服人員，我想要依訂單編號查詢出貨狀態，以便回覆顧客詢問。
- 驗收條件：在訂單已出貨的前提下，客服輸入完整訂單編號並查詢時，畫面顯示物流單號與出貨日期；輸入不存在的編號時，顯示查無資料的提示。
非功能需求：效能、資安、相容與無障礙
非功能需求描述系統「做得多好」，外包時若沒寫，上線後可能才發現速度慢、權限太寬或手機無法操作。建議涵蓋以下面向，並同樣寫成可以檢驗的條件：
- 效能：預估同時使用的人數、資料量與尖峰時段，以及查詢或頁面載入可接受的等待時間。
- 資安與權限：登入方式、是否需要多重要素驗證、密碼規則、操作紀錄要記哪些事件與保存多久。
- 相容性：要支援的瀏覽器、作業系統與裝置，以及 APP 要上架的平台。
- 無障礙：對外的網頁可參考全球資訊網協會的網頁內容無障礙指引（WCAG），它的成功準則分為 A、AA、AAA 三個等級，規格書中可指定要符合的等級。
- 維運：備份頻率、還原方式、主機與網域由誰持有，以及上線後的保固與維護範圍。
系統若會蒐集姓名、聯絡方式等資料，這些屬於個人資料保護法第二條所稱的個人資料，規格書要寫明蒐集哪些欄位、用途、誰能查看與保存期間，相關義務請以主管機關公告或專業意見為準。
流程圖、畫面草圖與資料欄位
文字描述容易各自解讀，關鍵流程與畫面建議用圖補充：
- 流程圖：畫出從申請、審核到結案的每個步驟與判斷分支，退件、取消、逾時這類例外也要畫進去，符號用法可參考系統開發流程圖的畫法。
- 畫面草圖：用線框圖表達頁面上的欄位、按鈕與資訊順序，不必講究配色，重點是讓雙方對操作步驟有同樣的想像，可參考線框圖的用途與畫法。
- 資料欄位表：列出主要資料的欄位名稱、格式、是否必填、預設值與資料來源，例如訂單、會員、商品。
- 狀態定義：訂單、工單這類會流轉的資料，要列出所有狀態，以及狀態之間的轉換條件。
附圖時標上對應的需求編號，並註明草圖只表達功能與資訊架構，視覺設計另行確認。
套用軟體需求規格書範本的注意事項
網路上的軟體需求規格書範本可以當作章節提醒，但直接照填可能出現兩種問題：一是為了填滿欄位，寫進和專案無關的內容；二是範本沒有的項目就被忽略。使用範本時建議：
- 先刪掉不適用的章節，例如沒有硬體介面的專案，就不必保留硬體需求。
- 補上範本缺少但專案需要的內容，例如舊資料轉移、與既有系統的串接、上線切換方式。
- 名詞定義統一放在前面，同一個東西全文只用一個名稱，「客戶」「會員」「用戶」不要混用。
- 每次修改都記錄版本、日期與修改人，送給廠商的版本另存一份，報價與驗收都以該版本為準。
規模小的專案，可以先把目的與範圍、使用角色、功能清單與驗收條件、畫面草圖這四個部分寫完整，再逐步補齊其他章節。
交給廠商前的檢查與常見缺漏
送出前，請一位沒參與撰寫的同事讀一次，用以下問題檢查：
- 每項功能都有驗收條件嗎？有沒有「方便」「快速」這類無法量測的字眼？
- 例外情況寫了嗎？例如付款失敗、重複送出、資料被刪除後的處理方式。
- 後台管理功能有列入嗎？例如資料維護、權限設定與報表匯出。
- 要串接的外部系統，有沒有列出對方能提供的資料與限制？規劃方式可參考API 串接的規劃流程。
- 通知信、簡訊或推播的內容與觸發時機寫了嗎？
廠商讀完後提出的問題，就是規格需要補充的地方，回答後要更新回規格書，不要只留在通訊軟體裡。
常見問題
需求規格書應該由誰來寫？
由業主端熟悉作業流程的人主筆，資訊或專案負責人整理格式。廠商可以協助訪談與補充技術細節，但業務規則、例外情況與驗收條件需要業主確認。
需求規格書和功能規格書一樣嗎？
用法因團隊而異。常見的區分是需求規格書描述要解決的問題與要達成的條件，功能規格書由開發端依需求寫出系統如何實現，包含畫面、欄位與邏輯細節。外包時雙方先對名稱達成共識即可。
規格書寫完之後還能修改嗎？
可以，但要走變更程序：記錄要改什麼、原因、影響的功能與時程，雙方確認後更新版本。開發中途的修改可能影響報價與交期，合約中可以事先約定變更的處理方式。
沒有技術背景也寫得出來嗎？
可以。業主端只要把流程、角色、資料與驗收情境用一般用語寫清楚即可，技術架構與資料庫設計可以交由開發團隊提出，再由雙方對照需求確認。
規格書要寫多詳細才夠？
可以用兩個標準檢查：不同廠商讀完能估出相近的範圍，驗收時能逐條判斷是否完成。篇幅不必長，但每項功能的情境、例外與驗收條件都要寫到。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
想直接討論你自己的網站狀況，或需要一份初步的搜尋機會評估？
相關主題
下一步
建議先寫出目的、範圍、使用角色與功能清單，再逐項補上驗收條件。京采的網頁設計服務可以協助需求訪談、整理規格書與畫面草圖，並進行客製後台或 API 串接開發；想先確認規格是否寫得夠清楚，歡迎與我們聯繫。
