政府資訊系統需求規格書有固定格式嗎？
重點結論
目前並沒有一份可以直接套用到所有政府機關、所有資訊系統案件的單一需求規格書格式。不同機關仍應依自身規範、採購方式、系統性質與專案需求決定實際內容。
需求規格書真正需要解決的問題，不是「應該套哪一份範本」，而是：
這份文件是否已經清楚到足以讓機關與開發廠商對專案範圍建立共同理解？
法規依據經濟部水利署（內部規範）《資訊相關系統開發與維護注意事項》
經濟部水利署及所屬機關現行《資訊相關系統開發與維護注意事項》為例，其將資訊系統開發與維護分為系統評估、需求與系統分析、系統設計、程式開發、系統測試、教育訓練、系統上線及系統維護等八個生命週期階段，並提供需求規格書、需求訪談紀錄、設計規格書、測試計畫書與測試報告書等參考格式。該規範最近一次修正為 2024 年 8 月 21 日。
但這是經濟部水利署及所屬機關的管理規範，不能直接寫成所有政府機關都必須採用相同格式或流程。
真正值得參考的是它背後的邏輯：
需求不是一份孤立的招標文件，而是後續設計、開發、測試與上線的起點。
為什麼需求不能只從功能清單開始？
重點結論
「案件管理」、「線上申請」、「會員管理」只能說明系統大概要有什麼功能，還不足以界定真正的開發範圍。
假設需求規格只有一句「建置線上申請功能」，從業務角度看，需求似乎已經很清楚。但從系統開發角度，仍然有很多問題沒有答案：
- 申請人是否需要登入？
- 使用什麼方式驗證身分？
- 需要填寫哪些資料與附件？
- 案件送出後由誰受理？
- 是否需要主管審核？
- 資料錯誤時是退件還是補件？
- 補件後回到哪一個流程？
- 申請人是否可以查詢進度？
- 審核結果透過什麼方式通知？
- 承辦人需要哪些統計與報表？
這些內容沒有改變「線上申請」這個功能名稱，卻可能讓系統開發範圍產生非常大的差異。
因此，需求不能只問「系統需要哪些功能？」，更應該問：誰，在什麼情況下，需要透過系統完成什麼工作？完成後會產生什麼結果？
例如，與其只寫「系統應提供案件查詢功能」，可以進一步描述：承辦人登入後，可依案件編號、申請人、申請日期及案件狀態查詢所屬單位案件，並檢視案件基本資料與處理歷程。
這時候開發團隊才能進一步辨識登入、角色權限、條件查詢、案件資料、歷程紀錄等真正需要開發的內容。
政府資訊系統需求規格書應該先確認哪些內容？
重點結論
政府資訊系統需求可以先從「目的、角色、流程、功能、資料、整合、非功能需求、驗收」8 個面向確認，重點是把系統邊界說清楚，而不是追求功能數量。
不同專案的規模與要求不同，但從系統開發角度，至少可以先檢查以下八個面向。
1. 專案目的
為什麼需要這套系統？目前的工作方式遇到什麼問題？建置之後希望改善什麼？
例如真正的需求可能不是「需要案件管理系統」，而是目前案件散落在 Email、Excel 與紙本之間，導致跨單位查詢困難、處理進度無法掌握。
2. 使用者與角色
哪些人會使用系統？民眾、承辦人、主管、系統管理者或其他機關，各自需要完成什麼工作？不同角色能看到、修改與處理哪些資料？
3. 業務流程
一件工作從開始到完成會經過哪些步驟？除了正常流程之外，還有哪些退件、補件、取消、重新送審或跨單位處理等例外情況？
4. 功能需求
不同角色分別需要透過系統完成哪些操作？功能應盡可能連回實際流程，而不是單獨列出功能名稱。
5. 資料需求
系統需要建立、查詢、保存、匯入、匯出或交換哪些資料？是否需要將既有資料移轉到新系統？
6. 系統整合
是否需要與既有帳號、資料庫、其他政府資訊系統或第三方 API 串接？資料由誰提供？透過什麼方式交換？
7. 非功能與資安需求
除了「做什麼」之外，還應考慮使用量、效能、相容性、權限、安全性與適用的資通安全要求。
8. 測試與驗收
每一項重要功能完成後，要怎麼確認它符合原本需求？哪些條件代表系統可以正式交付？
| 檢查面向 | 可以先問的問題 |
|---|---|
| 專案目的 | 為什麼要建這套系統？現在最大的問題是什麼？ |
| 使用者 | 有哪些角色？不同角色可以做什麼？ |
| 流程 | 一件工作從開始到完成怎麼走？ |
| 功能 | 每個流程需要哪些系統操作？ |
| 資料 | 資料從哪裡來？需要保存或移轉什麼？ |
| 整合 | 是否需要串接既有系統、帳號或 API？ |
| 限制 | 有哪些既有環境、資安、效能或相容性要求？ |
| 驗收 | 最後如何證明需求確實完成？ |
這八項不是所有政府案件依法必須使用的固定章節，而是一套協助確認開發需求是否已經形成完整系統邊界的規劃方式。
功能需求到底應該寫到多細？
重點結論
功能需求應該詳細到廠商可以理解使用情境與開發範圍，但不代表在沒有必要的情況下，要先把所有 UI、技術架構與實作方式指定完成。
例如只寫「系統提供權限管理功能」，仍然很難估計真正工作量。進一步寫成：一般承辦人僅能查詢與處理所屬單位案件；單位主管可以檢視所屬單位案件並執行指定審核；系統管理者可以管理帳號與系統設定。開發團隊就能理解角色與資料存取之間的關係。
但另一方面，如果真正需求只是確保系統達到特定功能與效益，是否有必要指定某一種程式語言、資料庫品牌或特定套件，就需要另外判斷。
法規依據行政院公共工程委員會《政府採購法第二十六條執行注意事項》
，供不特定廠商競標的技術規格，應以達成機關在功能、效益或特性等需求所必須者為限；是否構成限制競爭，也應判斷該規格是否超出機關真正需要。
因此，需求規格的核心不是「我能不能把技術寫得越細越好？」，而是「哪些條件是機關真正需要，而且廠商必須知道的？」
法規依據行政院公共工程委員會政府採購法第三十四條第一項
如果專案尚未確定市場上有哪些適合的技術方案，工程會的現行注意事項也載明，機關訂定技術規格時，除依相關公開閱覽制度辦理者外，得依政府採購法第三十四條第一項公開徵求廠商提供參考資料，以供研議後訂定。
這也代表：業務需求與技術解決方案，不一定需要在需求規劃的第一天就同時全部決定。
哪些容易漏掉的需求，會直接影響開發範圍？
重點結論
真正讓專案報價、架構與時程產生差異的，很多時候不是主要功能，而是資料、使用量、權限、整合、資安與既有環境。
例如兩套系統都叫「案件管理系統」。其中一套只提供十位內部人員使用；另一套則需要提供大量民眾線上申請與查詢。兩者功能名稱可能很像，但在帳號管理、流量、系統容量、資料安全與基礎架構上的需求可能完全不同。
資料移轉也是一樣。如果新系統啟用後需要保留多年歷史案件，需求就不只是「開發一套新的案件系統」，而是同時需要處理資料盤點、格式整理、欄位對應、資料轉換、驗證與新舊系統切換。
另外，如果需要串接既有系統，也不應只寫「系統應提供 API 串接」，還要確認：
- 串接哪個系統？
- 由誰提供介面？
- 交換哪些資料？
- 多久交換一次？
- 如果交換失敗怎麼處理？
- 有哪些權限與安全限制？
以水利署現行內部規範為例，其需求規格注意項目就包含資料年成長量、主要與尖峰使用人數、尖峰時段、網路流量、伺服器容量、既有應用系統與第三方元件相容性、資料相容性，以及資訊安全防護需求等分析。
這再次說明，功能數量不是判斷系統開發規模的唯一依據。也因此，如果不同廠商收到同一份需求卻報出差異很大的價格，不一定只是誰比較貴，也可能是大家其實在估算不同的開發範圍。
資安為什麼也應該在需求階段確認？
對政府資訊系統而言，資安不是等系統做完後再補做一次檢測。
法規依據現行法規《資通安全管理法》第十條
，公務機關或特定非公務機關在適用範圍內委外辦理資通系統建置、維運或資通服務時，應選任適當受託者、要求建立有效的資通安全管理機制並監督實施，且應以書面契約載明雙方權利義務與違約責任。
法規依據現行法規《資通安全責任等級分級辦法》第十一條
2026 年 1 月 7 日發布的現行《資通安全責任等級分級辦法》第十一條，也規定各機關自行或委外開發之資通系統，應依附表九完成資通系統防護需求分級，並依附表十所定防護基準執行控制措施。
因此，如果系統涉及登入、權限、個人資料、敏感資訊或跨系統資料交換，相關要求可能直接影響系統架構與開發方式。需求階段越早確認，越能降低後期才發現系統需要大幅修改的風險。
需求規格如何一路連到測試與驗收？
重點結論
好的需求不只回答「系統要做什麼」，還應該能回答「最後怎麼證明它完成了」。需求越能轉換成可測試的情境，後續驗收越容易建立共同標準。
假設需求寫「民眾可以查詢案件辦理進度」，真正進入測試時，可以進一步確認：
- 民眾是否可以依規定方式查詢？
- 不同案件狀態是否正確呈現？
- 沒有權限的人是否無法查看案件？
- 案件不存在時系統如何回應？
如果原始需求只有一句模糊的「提供案件查詢」，到了驗收階段才開始討論這些條件，就很容易產生「機關認為這本來就包含」與「廠商認為原需求沒有這項內容」之間的落差。
以水利署現行資訊系統開發與維護規範為例，其系統測試階段會依計畫說明、需求規格與設計相關文件進行功能測試，測試結果不符合需求規格與設計預期時則應進一步處理。同樣地，這是水利署及所屬機關的制度，並非所有機關統一採用的驗收方式，但它呈現了一個很重要的系統開發原則：需求、設計、測試與驗收不應該彼此分離。
因此，在需求規格完成後，可以逐項檢查：
- 這個需求由誰使用？
- 什麼條件下觸發？
- 預期結果是什麼？
- 失敗或例外時怎麼處理？
- 最後如何驗證？
如果一項重要需求無法回答最後一題，通常代表它還需要進一步釐清。
什麼情況代表需求已經可以進入下一階段？
重點結論
需求不一定要把每個畫面與技術細節全部決定完成才算準備好；更重要的是，專案的問題、使用者、流程、資料、主要功能、限制條件與驗收方向已經足夠清楚。
可以先用以下幾個問題判斷：
需求是否已經可以被理解？
不同的人閱讀需求後，對「這套系統要解決什麼」是否會得到大致一致的答案？
系統邊界是否已經形成？
知道哪些功能屬於本專案，哪些需要外部系統、其他單位或第三方服務配合？
主要流程是否已經完整？
不只知道正常流程，也開始知道退件、補件、取消、異常或權限不足時怎麼處理？
重要資料是否已經被盤點？
知道哪些資料需要建立、保存、移轉或交換？
開發限制是否已經被揭露？
例如既有環境、部署方式、資訊安全、相容性或其他專案必要條件。
驗收方向是否能被描述？
至少可以說明重要功能完成後，預期透過什麼情境確認成果。
如果這些問題大致都能回答，就代表需求已經從「我們想做一套系統」，往前走到「我們知道這套系統主要要解決什麼，而且可以開始進一步評估怎麼做」。
反過來，如果現在仍只有「想把流程數位化」、「想做一個案件管理平台」、「希望導入線上申請」這類方向，也不代表專案不能開始。這時候更適合先進行：
- 01
現行流程盤點
- 02
使用者與需求訪談
- 03
資料與既有環境盤點
- 04
系統邊界整理
- 05
功能與技術評估
再逐步形成正式的開發需求。
常見問題
不一定。目前沒有適用所有政府資訊系統案件的通用規定要求招標前必須完成所有 UI 畫面。是否需要 Wireframe、流程圖、畫面示意或其他文件，仍應依個案與機關規範決定。從開發角度而言，前期更重要的是先確認使用者、流程、功能、資料與系統邊界。
本文引用之法規與規範
- 《資訊相關系統開發與維護注意事項》經濟部水利署（內部規範）
- 《政府採購法第二十六條執行注意事項》行政院公共工程委員會
- 政府採購法第三十四條第一項行政院公共工程委員會
- 《資通安全管理法》第十條現行法規
- 《資通安全責任等級分級辦法》第十一條現行法規
以上為本文撰寫時引用之法規與規範；法規可能修訂，實際適用請以主管機關最新公告為準。