政府標案系統開發跟企業案差在哪？多角色權限、稽核軌跡、資安檢核與驗收文件怎麼準備

決標公告下來的那個下午，我們在辦公室把高雄市幼兒園招生系統的需求書重新攤開讀了一遍。跟一般企業案最大的不同，第一頁就出現了：需求書裡沒有「老闆想要什麼」，只有「機關依規定應辦事項」。使用者有三種，家長在外面填表、園所在裡面審件、教育局在上面看報表；每一筆資料誰改過、什麼時候改、改前改後長什麼樣，都要留得住；驗收要拿一疊文件對著契約逐條核，主管點頭沒有用。

如果你是第一次接公部門系統標案的開發團隊，或是打算把系統開發標案外包出去的機關承辦，這篇文章想回答一個很實際的問題：拿到政府標案之後，開發上到底跟企業案差在哪，哪些東西不先準備好，會在期中審查或驗收那天卡住。

先講結論。差別集中在四個地方：角色與權限的顆粒度、稽核軌跡的完整性、資安檢核的法定門檻、驗收文件的形式要求。技術本身沒有比較難，難的是這四件事都寫在法規和契約裡，沒有「先上線再補」的空間。台灣的資通安全管理法自 2019 年施行以來，公務機關委外開發的資通系統就必須依責任等級套用防護基準，而政府採購法對驗收、保固與履約保證金的規定，會直接決定你的收款節奏。

這篇先把公部門案和企業案放在同一張表上對照，再依序拆多角色權限、稽核軌跡、資安檢核表、驗收文件清單四個主題，最後給一張投標前的自我檢查表。整篇對照的是我們實際交付過的兩個公部門案例：高雄市幼兒園招生系統與公文交換檔產生器。

政府標案系統跟企業案差在哪

很多團隊第一次接標案，用企業案的節奏去跑，結果在期中審查被退件。差別可以拆成下面這張表。

其中最容易被低估的是「變更要走程序」這件事。企業案裡老闆一句話就能加欄位，標案裡每一個超出需求書的功能，都要評估是否構成契約變更，否則做了也不算數，甚至驗收時會被問「這功能契約沒寫，為什麼在系統裡」。我們在系統開發流程的七個節點那篇談過需求凍結，在標案裡這件事是強制的。

無障礙是另一個常被跳過的門檻，政府網站已經把 WCAG 當硬性要求，細節請看WCAG 2.2 變政府標案硬門檻，本文不重複。

多角色權限怎麼設計才不會驗收時被打回

以幼兒園招生系統為例，同一個「報名資料」至少被三端碰到：家長在前台填寫並上傳證明文件，園所承辦在後台審核、補件、排序，教育局在最上層看全市統計與抽查個案。三端看到的欄位、能做的動作、能看到的資料範圍都不一樣，而且會隨招生階段改變，例如登記期家長可以改資料，抽籤後就鎖定。

企業案常見的做法是在程式裡寫死「管理員能做全部、一般使用者只能看自己的」。這在標案裡撐不住，原因有三個：機關人員會調動，權限要能由承辦自己調整；上級機關要看得到但不能改；稽核時要能回答「某個帳號在某段時間有哪些權限」。

實務上我們的做法是把「角色」「資料範圍」「階段」三個維度拆開來判斷，任何一個操作都要同時通過三關。這樣承辦要調整權限時，改的是設定不是程式，驗收時也能直接秀出權限矩陣。做法上跟客製化管理系統解決方案裡談的多角色場景是同一套，差別只在標案要多留一層權限異動的紀錄。

稽核軌跡要留什麼、留多久

公部門系統的稽核軌跡（audit log）有兩個用途：一是資安事件發生時能追查，二是民眾申訴或監察調查時能舉證。前者由資通安全管理法的防護基準要求，後者則是機關的行政責任。這兩個用途決定了日誌不能只是「開發人員 debug 用的 log」，而是要能被非技術人員讀懂、能匯出、能證明沒被竄改。

資通系統防護基準把「事件日誌與可歸責性」列為七個構面之一，要求記錄的內容、保存期限與保護方式依系統分級遞增。實務上我們建議至少分成下面四類分開設計，因為它們的讀者、保存期限與查詢方式都不同。

保存期限要看契約與機關的資安責任等級，多數機關會要求日誌至少保存六個月，實務上不少契約直接寫一年以上，投標前先問清楚，因為這會影響儲存成本與備份設計。若機關被分到較高的責任等級，日誌還要送到集中式管理平台，這部分可以參考資通安全管理法責任等級對照。

有一個細節常被忽略：改前值與改後值要一起留。只留「某人在某時改了某筆」在申訴時沒有用，家長主張「我填的是第一志願 A 園」，系統要能拿出當時的值。招生系統的志願序、公文系統的收發文號，都是這種會被拿出來對質的欄位。

資安檢核表：投標前就要知道驗收會測什麼

政府標案的資安要求通常寫在需求書的「資通安全需求」章節，並引用資通系統防護基準。它會被當成驗收條件逐項檢查。下面這張表把防護基準的七個構面對應到開發時實際要做的事，方便你在報價階段就把工時算進去。

弱點掃描與滲透測試的差別、法定頻率與台灣行情，弱點掃描、滲透測試、壓力測試差在哪那篇整理得很細。這裡只提醒一件事：多數標案要求「驗收前完成弱掃與滲透測試且高風險項目全數修補」，這代表測試要排在驗收前至少三到四週，留出修補與複測的時間。把它排在驗收前一週，幾乎一定會延期。

另一個常見盲點是第三方套件。機關會要求提供系統使用的套件清單與已知弱點狀態，若系統用了停止維護的套件，驗收時會被要求更換。所以選型時就要避開沒人維護的函式庫，這在企業案是建議，在標案是必要。

驗收文件清單：沒有這些，功能做完也過不了

標案驗收的邏輯是「文件對契約」，功能做得順手只是基本。承辦要拿著契約與需求書逐條核對，每一條都要有對應的文件或測試紀錄。下面是我們交付公部門案時實際準備的文件清單，數量會依契約增減，但這九份幾乎每案都有。

其中「系統需求追溯表」是最值得早做的一份。它逼你在開發第一週就把需求書逐條編號，之後每個功能、每個測試案例都掛回需求編號，驗收時承辦一眼就能對上。我們在SOW、規格書與合約的驗收里程碑談過企業案的驗收里程碑，標案只是把這件事變成契約義務。

原始碼與部署文件這一項，很多團隊到驗收前一天才發現「只有我們的機器跑得起來」。機關通常會要求在指定環境重新部署一次，或至少要求文件能讓第三方廠商接手，這也是合約撤退條款與資料返還裡談的可移轉性在公部門的版本。

跨機關介接與公文交換是另一種驗收條件

公部門系統很少是孤島，常見的介接包括與機關既有的公文系統交換文件、與戶政或教育資料庫查驗身分、與繳費平台對帳。這些介接各有自己的規格與測試環境，申請測試帳號往往要跑公文流程，時間常常比開發本身還長。

以公文電子交換為例，機關對外發文要產生符合公文交換格式的 di 檔與 sw 檔，格式細節與常見錯誤我們在民間公司要跟政府電子交換公文，di 檔和 sw 檔怎麼產生拆過。這類需求如果需求書有寫，就要在專案第一週把介接規格與測試環境申請下來，而且要把「對方系統回應時間」寫進測試計畫，否則驗收時對方環境不穩，責任會落在你身上。

如果你的系統要對外發公文，或機關要求交付物包含合規的交換檔，公文交換檔產生器是我們為這件事做的工具，開網頁就能產出合規的檔案，不用另外裝元件。整體介接的架構選擇，可以搭配系統整合的六種場景與三種架構一起看。

報價與時程：把法定門檻的工時算進去

我們的判斷是，公部門系統標案的成本結構跟企業案不同，文件與檢核大約佔總工時的兩到三成，而多數第一次投標的團隊只算了功能開發。這也是為什麼標案常出現「得標價比想像低、交付時卻虧錢」的狀況。下面是我們建議在報價時分開列的工時項目。

• 需求追溯與文件撰寫：需求追溯表、設計文件、手冊、教育訓練，約佔 15% 到 20%
• 資安檢核：日誌設計、弱掃修補、滲透測試配合與複測，約佔 10% 到 15%
• 介接與測試環境申請：跨機關介接、公文交換、繳費平台，依案件差異很大
• 驗收與保固：現場驗收、缺失改善、保固期內的回應，通常保固一年
• 履約保證金與分期付款的資金成本：契約常見期中與驗收後才付款，要算進現金流

時程上，弱掃與滲透測試、教育訓練、驗收這三件事要從契約的驗收日往回推排，而不是從開發完成日往後排。如果你在評估要不要投標，或機關端在準備需求書，如何選軟體開發公司與軟體外包 Kickoff Meeting 該對齊的事項兩篇可以拿來當雙方對齊的起點。

如果你是機關承辦，正在準備把系統開發標案發包，或是團隊第一次接公部門案想找有交付經驗的夥伴一起做，可以跟我們聊聊，我們可以先幫你看需求書裡哪些條款會影響時程與報價。招生、報名、審核這類多角色系統，高雄市幼兒園招生系統是我們以準用最有利標得標並完成交付的案例，家長、園所、教育局三端都在同一套系統上作業。