政府資訊系統開發，為什麼不能只先列功能？
重點結論
資訊系統的開發範圍，很難只從功能名稱判斷。
例如需求規格寫：
「建置案件管理功能。」
實際上可能只是讓承辦人建立、修改與查詢案件；也可能包含民眾線上申請、身分驗證、跨單位分案、主管簽核、補件、通知、進度查詢、統計報表與歷程紀錄。
兩者都叫「案件管理」，開發規模卻完全不同。
因此，在規劃政府資訊系統時，比「有哪些功能」更值得先確認的是：
一件業務從開始到完成，需要經過哪些人、哪些資料與哪些處理流程？
這並不是所有政府機關都必須依照同一套固定開發流程進行，而是資訊系統規劃上的重要原則。
法規依據經濟部水利署（內部規範）《資訊相關系統開發與維護注意事項》
經濟部水利署及所屬機關的現行規範為例，其《資訊相關系統開發與維護注意事項》將資訊系統生命週期分為系統評估、需求與系統分析、系統設計、程式開發、系統測試、教育訓練、系統上線與系統維護八個階段，同時提供需求規格書、需求訪談紀錄、設計規格書、測試計畫書與測試報告等參考格式。該規範是水利署及其所屬機關的內部規範，不能直接泛化為所有政府機關的統一規定，但可以看出需求、設計、測試與上線之間具有前後關聯。
對機關而言，真正需要避免的，就是需求只停留在「功能名稱」，後面的設計與驗收卻沒有共同依據。
政府資訊系統需求規格書，應該先確認哪些內容？
重點結論
需求規格的目的，不是要求承辦單位在開發前把每一個按鈕、畫面與技術都決定完成。
更重要的是先建立系統邊界。
例如規劃線上申請系統時，至少應先釐清：
誰可以提出申請、需要提供什麼資料、是否需要附件、案件送出後由誰處理、是否存在退回或補件、有哪些審查角色、如何通知申請人，以及最後需要保留哪些案件紀錄。
當這些業務需求確認後，開發團隊才能再往下拆成：
使用者流程、功能、權限、資料結構、介面、API 與技術架構。
如果反過來在業務流程尚未確認時，就先指定非常細的系統畫面或技術做法，除了可能增加後續修改，也需要注意政府採購對競爭公平性的要求。
法規依據行政院公共工程委員會政府採購法第二十六條
，供不特定廠商競標的技術規格，應以達成機關所需功能、效益或特性為限，規格不得在目的或效果上造成不當限制競爭。
因此，需求規格寫得「詳細」並不等於寫得「好」。
更重要的是：
該說清楚的業務需求足夠清楚，但不因不必要的技術指定而提前限制解決方案。
需求還沒有完全確定，政府機關可以怎麼進行前期調查？
重點結論
政府資訊系統的特殊之處，在於承辦單位有時知道自己需要解決什麼問題，卻不一定知道市場目前有哪些技術做法，或合理的開發範圍應該怎麼設定。
這時候並不代表只能先自行猜測規格。
法規依據行政院公共工程委員會政府採購法第二十六條
，機關訂定招標文件技術規格時，得依政府採購法第三十四條第一項規定，公開徵求廠商提供參考資料，供機關研議後訂定規格。
換句話說，如果專案仍處於市場、技術或方案不明確的階段，可以依適用採購程序評估使用公開的市場資訊蒐集方式，而不是先把自己不確定的技術答案直接寫進規格。
這一點對資訊系統尤其重要。
因為承辦單位最清楚的通常是：
「現在哪裡不好用。」
而開發廠商比較熟悉的是：
「這個問題有哪些技術解法。」
政府資訊系統前期規劃真正需要完成的工作，就是在維持採購公平性的前提下，逐步把這兩件事接起來。
政府資訊系統委外時，哪些條件應該在招標前說清楚？
重點結論
政府資訊服務採購不只是功能規格。
法規依據行政院公共工程委員會《機關委託資訊服務廠商評選及計費辦法》
依工程會《機關委託資訊服務廠商評選及計費辦法》，招標文件可依個案特性與實際需要載明服務項目與工作範圍、廠商應具備的資源、機關現有資訊作業環境等事項；服務費用的計算也應依資訊服務的類別、性質、規模、工作範圍及工作期限選擇適合的方式。
對資訊系統開發來說，這意味著前期除了功能之外，至少還應盤點：
- 現有資訊環境與部署條件
- 既有系統及資料來源
- 預計串接的外部系統
- 使用者角色與權限
- 資料移轉需求
- 資通安全要求
- 測試與驗收項目
- 上線方式
- 教育訓練或文件交付
- 後續維運與保固需求
不同專案不一定全部需要，但如果其中任何一項會影響廠商投入的人力、技術或時程，就不宜等到開發後才第一次確認。
資通安全不能等到系統完成後才處理
重點結論
對政府資訊系統而言，資安並不是開發完成後「掃描一次」就結束的工作。
法規依據現行法規《資通安全管理法》第十條
，公務機關或特定非公務機關在適用範圍內委外辦理資通系統建置、維運或資通服務時，應選任適當的受託者，要求建立有效的資通安全管理機制並監督其實施，且應以書面契約載明雙方權利義務及違約責任。
法規依據現行法規《資通安全責任等級分級辦法》第十一條
，各機關自行或委外開發的資通系統，應依規定完成資通系統防護需求分級，並依相對應的防護基準執行控制措施。
因此，對需要登入、權限管理、個人資料、敏感資訊或跨系統交換資料的專案來說，資安需求應該在系統架構與需求階段就納入。
例如：
哪些角色可以查看哪些資料、敏感資料如何處理、系統間如何交換資訊，以及需要完成哪些安全檢測，都可能影響系統設計。
如果到驗收前才第一次處理，很可能需要回頭修改的不只是程式，而是整套權限或資料架構。
如果是政府網站或民眾服務入口，還需要考慮網站無障礙
重點結論
如果開發標的是政府網站、線上申辦服務或其他面向民眾的網站服務，除了資訊系統本身，也需要檢視政府網站相關規範。
法規依據數位發展部《政府網站服務管理規範》
網站生命週期整理為網站定位、設計規劃、開發建置、資料移轉、上線準備及維運管理六個執行層面，並在開發建置階段要求確認符合資訊安全與網站服務相關規定，其中包含網站無障礙規範。
數位發展部目前的網站無障礙規範涵蓋可感知、可操作、可理解及相容性等面向，例如鍵盤操作、內容結構、焦點順序、錯誤識別與輔助科技相容性等。
因此，如果專案本身就有無障礙需求，比較合理的方式是在 UI／UX 與前端開發階段就納入，而不是網站完成後才一次修改。
政府資訊系統的預算，為什麼不能只用功能數量估？
重點結論
政府資訊系統的開發成本，通常不只是「有幾個功能」。
例如兩個專案都有：
會員、案件管理、查詢、報表與後台。
其中一個可能只有內部十位人員使用；另一個則需要民眾登入、跨機關資料交換、多層權限、歷史資料移轉、資安測試與對外網站無障礙。
兩者的功能名稱看起來接近，實際開發範圍卻可能差很多。
因此，在預估資訊系統開發範圍時，比較適合拆開檢視：
- 01
業務流程
- 02
使用角色
- 03
功能
- 04
資料
- 05
系統整合
- 06
資安
- 07
設計
- 08
測試
- 09
上線與交付
工程會的資訊服務計費規定也不是單純以功能數量決定費用，而是要求依服務類別、性質、規模、工作範圍及期限等因素選擇適合的計費方式。
因此，如果專案預算有限，與其先做一張很長的功能清單再逐項刪除，更值得先確認：
第一階段至少要完成哪一段可以真正投入使用的服務流程？
政府資訊系統開發過程中，可以修改需求嗎？
重點結論
資訊系統開始進入需求訪談、原型或實際測試後，發現某些流程需要調整並不罕見。
因此真正需要管理的，不是「專案開始後絕對不能改需求」，而是：
修改需求時，範圍、時程、費用與驗收依據要如何一起調整。
例如原本需求是讓承辦人查詢案件，後來新增跨機關分案與自動通知，這已經不只是畫面調整，而可能涉及新的權限、流程與資料交換。
如果沒有明確的變更管理方式，很容易產生：
機關認為只是原功能的一部分，廠商卻認為屬於新增範圍。
因此，在契約、工作說明書及專案管理機制中預先定義需求確認、變更紀錄及影響評估方式，會比要求「所有需求在第一天全部確定」更符合資訊系統實際開發情況。
工程會目前也持續提供「資訊服務採購契約範本」供機關辦理資訊服務採購時參考，實際契約內容仍應依個案需求及最新規定調整。
政府資訊系統驗收，應該從什麼時候開始準備？
重點結論
從需求規劃階段就應該開始想。
因為：
需求規格決定要做什麼，驗收則決定如何確認它真的完成。
例如只寫：
「提供線上申請功能。」
到最後很難判斷什麼才算完成。
如果一開始就把情境說清楚，例如：
- 01
申請人登入
- 02
填寫資料
- 03
上傳附件
- 04
送出
- 05
承辦人審查
- 06
補件
- 07
再審
- 08
完成
- 09
通知結果，
後續就更容易將每個步驟轉成測試情境與驗收項目。
所以政府資訊系統前期規劃時，一個很實際的檢查方式是：
每一項重要需求，有沒有辦法回答「最後怎麼證明它完成了？」
如果不能，就代表需求可能還需要再釐清。
政府資訊系統開發廠商，應該怎麼評估？
重點結論
資訊系統開發不像採購一件規格完全固定的成品，因此不能只看功能數量或最低報價。
法規依據行政院公共工程委員會《機關委託資訊服務廠商評選及計費辦法》
專案計畫管理能力、人力資源規劃、相關能力及其他依案件需要設定的項目納入資訊服務評選制度中；實際評選項目仍應由機關依個案與招標文件設定。
站在資訊系統開發角度，前期可以特別觀察幾件事：
第一，廠商能不能理解業務流程，而不只是照著功能表報價。
看到「案件管理」時，是否會追問案件狀態、角色、例外流程與歷程需求。
第二，能不能主動指出系統邊界。
例如哪些功能屬於本系統、哪些需要外部 API、哪些資料由其他機關提供。
第三，能不能說清楚驗證方式。
除了「做得到」，還能不能說明怎麼測、怎麼確認完成。
第四，資安、部署與後續維運是否被納入架構考量。
這些通常比單純比較「同樣做十個功能，誰的價格最低」更能反映資訊服務的實際履約能力。
政府資訊系統開發的核心，不是把規格寫得越多越好
重點結論
政府資訊系統從需求規劃到正式上線，中間會經過採購、開發、資安、測試與驗收等不同階段。
真正影響這些階段能不能順利銜接的，不是規格書有多少頁，而是三件事情是否一致：
機關真正要解決的問題
↓
廠商實際要開發的系統
↓
最後用來驗收的標準
如果前面說的是「希望縮短民眾申請時間」，需求卻只寫「建置案件管理系統」；最後驗收又只檢查頁面能不能開啟，那麼即使每一份文件都完成，系統仍可能沒有真正解決原本的問題。
因此，比起先決定技術或追求一張最完整的功能清單，政府資訊系統更值得在開發前先把業務流程、使用者、系統邊界、資料、資安與驗收方式整理清楚。
這些條件確認後，技術與開發才有明確的方向。
常見問題
不一定。是否自行開發或委外，仍應依機關資訊能力、專案性質、預算及相關規範評估。工程會現行資訊服務規範將軟體開發、系統整合、資料庫建置等納入資訊服務範圍，但不代表所有資訊系統都必須採取同一種採購或委外方式。
從需求釐清開始，讓資訊系統真正能被開發與使用
當政府或公部門有新的資訊系統、線上服務、網站平台或流程數位化需求時，開發的起點不一定是一份已經完全定案的功能表。
更重要的是先把目前的業務流程、使用者、資料、系統環境與預期成果整理出來，再逐步轉換成可執行的資訊系統需求。
JoinX 哲煜科技提供客製化開發與設計、AI 導入、技術與 AI 顧問服務，可依專案需求參與網站、系統、APP、SaaS 與 AI 應用的規劃與開發。
對政府及公部門資訊系統案件而言，合作仍須依政府採購相關程序與個案招標規定辦理；若為市場資訊蒐集、公開徵求參考資料或正式採購案件，則可依機關所採取的合法程序提供相應的技術與開發資訊。
本文引用之法規與規範
- 《資訊相關系統開發與維護注意事項》經濟部水利署（內部規範）
- 政府採購法第二十六條行政院公共工程委員會
- 《機關委託資訊服務廠商評選及計費辦法》行政院公共工程委員會
- 《資通安全管理法》第十條現行法規
- 《資通安全責任等級分級辦法》第十一條現行法規
- 《政府網站服務管理規範》數位發展部
以上為本文撰寫時引用之法規與規範；法規可能修訂，實際適用請以主管機關最新公告為準。