系統開發驗收清單：權限、資料、例外流程與維運

系統開發驗收不是在專案最後巡一次畫面，也不等於測試人員說「功能可以用」。它要用可追溯且可重現的證據，確認需求、資料、權限、整合、例外、安全、移轉與維運準備，足以支持系統進入實際營運。

企業應先凍結本次驗收基線，寫清楚誰執行，使用哪個環境與資料，缺陷如何分級，以及哪些條件會阻擋上線。沒有這些共識，驗收很容易變成口頭感受、新需求與既有缺陷混在一起。

先說結論：系統驗收要回答四個營運問題

• 做對了嗎：已核定需求能否用明確情境與預期結果證明完成。
• 資料可信嗎：移轉、計算、同步與報表結果能否與來源核對。
• 風險可控嗎：權限、例外、安全、備份與回復是否有負責人。
• 能營運嗎：文件、教育、監測、支援與變更責任是否已交接。

系統開發驗收、測試、UAT 與上線核准有何差異？

測試是找出系統是否符合預期，在例外下如何表現；使用者驗收測試（UAT）則由熟悉業務的人，以實際流程判斷系統是否能支援工作。系統開發驗收再往前一步，把核定範圍、缺陷狀態、交付文件與責任納入正式接受判定。

上線核准是營運決策。即使功能驗收通過，若正式環境、資料移轉、回復計畫或支援窗口仍未準備，也不代表適合立即上線。反過來說，是否允許已知低風險缺陷隨版本修正，應依合約、營運風險與事前門檻決定，不宜套用「零缺陷」通則。

系統驗收要檢查哪八個面向？

面向	驗收目的	可保留證據	主要責任
功能	需求與規則可正確執行	案例、結果、截圖與紀錄	業務代表、測試與開發
資料	欄位、計算與移轉可核對	樣本、總筆數、對帳與差異	資料擁有人與開發
權限	角色只能執行被授權動作	角色矩陣與正反向測試	系統負責人與資安
整合	跨系統成功與失敗均可處理	請求、回應、重試與告警	雙方介面負責人
效能	關鍵操作符合約定負載條件	情境、資料量、量測與門檻	技術團隊與業務代表
安全	高風險弱點與敏感操作受控	檢查範圍、結果與處理紀錄	資安與系統負責人
移轉	正式資料可完整轉入並回復	移轉清單、核對與回復演練	資料、營運與技術團隊
維運	上線後有人監測、支援與改善	文件、告警、窗口與服務邊界	營運與維運負責人

八個面向的深度要依系統風險調整。涉及個資、付款或關鍵營運時，還需要適當的資安、法遵與領域專業審查。OWASP ASVS可提供應用程式安全驗證的結構參考，NIST SSDF則提供安全軟體開發實務脈絡；兩者都不是替代契約或法規判斷的通用合格章。

驗收前要準備什麼？先建立共同基線

• 本次納入與排除的需求版本，以及每項需求的負責人。
• 接近實際使用方式的驗收環境、帳號、角色與測試資料。
• 正常、例外、邊界、權限、回歸與復原情境。
• 缺陷嚴重度、回報格式、重測方式與上線阻擋條件。
• 資料移轉範圍、筆數核對、敏感資料處理與回復計畫。
• 簽核人、決策期限、交付文件、教育與上線支援窗口。

需求基線不代表之後不能調整，而是每個變更都能被辨識。若驗收中出現原規格沒有的新想法，應另外記成變更需求，再評估範圍、成本與時程，避免把新需求誤標為缺陷。

驗收案例怎麼寫？讓另一個人也能重現

每個驗收案例至少要有需求編號、前置條件、測試角色、使用資料、操作步驟、預期結果、實際結果、證據與狀態。預期結果應可觀察，例如「只有財務主管能核准退款，核准後保留操作人與時間」，不要只寫「權限正常」或「操作順暢」。

案例要同時涵蓋正向與反向。訂單成立是正常情境；庫存不足、付款逾時、重複通知、未授權角色、資料格式錯誤與外部服務中斷，才會暴露系統如何保護資料與營運。錯誤訊息也應能協助使用者採取下一步，而不是只顯示不明代碼。

缺陷怎麼分級？用影響與替代方案決定

等級	典型影響	處理方式	上線判斷
阻斷	關鍵流程無法完成，資料出現嚴重錯誤，或存在高風險安全問題	停止相關驗收，修正後完整重測	通常阻擋上線
重大	主要功能失常，替代方式不可接受或會造成顯著營運風險	優先修正並執行回歸測試	依事前門檻決定
一般	部分功能偏離預期，但有可管理的替代方式	記錄影響、責任與修正版本	由風險擁有人核准
輕微	文字、排版或低影響一致性問題	排入後續版本並保留追蹤	不宜自動視為阻擋
變更需求	原基線未承諾的新功能或規則	另走變更評估與核准	不與既有缺陷混算

分級名稱可以依團隊調整，但定義要在執行前確認。同一個畫面問題，可能對內部查詢是輕微，對付款或醫療決策卻是重大；不能只用外觀或修正工時判斷嚴重度。

從驗收計畫到正式上線的七個步驟

1. 確認基線：鎖定需求、環境、資料、角色與門檻。
2. 設計案例：把需求轉成可重現的正常與例外情境。
3. 準備環境：建立帳號、測試資料、整合端點與證據格式。
4. 執行並記錄：照案例操作，保留結果，不用口頭印象代替。
5. 處理缺陷：分級、釐清、修正，再重測受影響範圍。
6. 完成簽核：列出通過項目、已知風險、未完成責任與期限。
7. 核准上線：確認移轉、回復、監測、支援與變更計畫。

若還沒建立需求基線，可先參考系統開發需求規格書整理可驗證條件；若仍在供應商評選，則應先看系統開發公司怎麼選，把驗收、文件與移轉責任寫進合作範圍。

系統開發驗收常見錯誤

• 只測正常流程：沒有驗證失敗、重複、逾時與復原。
• 直接使用正式敏感資料：未先確認遮蔽、權限與保留規則。
• 把展示當驗收：由開發者操作成功，不代表實際角色能完成工作。
• 口頭同意上線：沒有留下已知缺陷、風險擁有人與期限。
• 沒有回復計畫：資料移轉或整合失敗時，只能臨時處理。
• 驗收後才談維運：文件、帳號、監測與支援責任沒有交接。

用訂單流程看驗收證據如何串起來

假設系統要讓客服建立訂單，主管核准折扣，付款結果回寫，再由倉儲出貨。驗收不只逐頁點按，而要確認未授權人員不能核准，重複付款通知不會重複入帳，失敗訂單能被找到與重送，庫存與訂單狀態一致，而且每個關鍵動作都有可追查紀錄。

這個中性示例不代表每個專案都需要相同設計。實際情境仍要回到系統開發流程與核定需求，逐案確認驗收範圍、交付物、保固與上線責任。

內文精華總結

• 驗收不只看功能：資料、權限、整合、安全、移轉與維運都要納入。
• 先建立基線：需求、環境、案例、缺陷標準與簽核責任要事前確認。
• 證據要可重現：每個案例留下前置、步驟、預期、結果與證據。
• 缺陷不等於新需求：兩者分流，才能管理範圍與上線風險。
• 上線是營運決策：已知風險、回復、監測與支援都要有人承擔。

系統開發驗收常見問題

驗收應由開發公司還是客戶負責？

雙方都有責任，但角色不同。開發方應提供可測版本、文件與缺陷處理；客戶的業務代表與決策者要確認流程是否可用，風險是否接受。具體分工以合約與驗收計畫為準。

UAT 通過就等於可以上線嗎？

不一定。UAT 通過主要代表業務情境符合預期；正式環境、資料移轉、安全、回復、監測與支援仍要通過上線門檻。

系統一定要零缺陷才能驗收嗎？

沒有適用每個專案的通則。企業應依缺陷影響、替代方案、合約條件與風險擁有人決定；阻斷或不可接受風險通常應先修正。

驗收中發現新需求怎麼辦？

先確認是否偏離已核定需求。若是新想法，應另列變更需求，評估價值、範圍、成本與時程，不要直接當成既有缺陷要求處理。

資料移轉要怎麼驗收？

先定義來源、轉換規則、總筆數、關鍵欄位與抽樣方式，再核對缺漏、重複、計算與關聯。正式移轉前還要演練失敗時的回復。

系統驗收通常要多久？

取決於範圍、風險、角色、資料、整合與缺陷數量，不能用固定天數概括。較可靠的做法是先估案例量、執行資源、重測輪次與決策期限。

下一步可先把需求、角色、資料與上線風險整理成一頁摘要，再交由合作團隊確認驗收邊界與證據。即站力的實際系統開發、驗收交付、保固與時程均需依專案逐案評估。