109 司法特考三等 檢察事務官電子資訊組 系統分析 考古題詳解

核心觀念

本題考查資訊系統規劃階段的可行性分析，以及如何依分析結果調整系統需求與設計。可行性不是只問「技術做不做得到」，而是要評估系統能否在實際作業中被採用、能否以合理技術建置，以及是否符合法律與基本權保障。

題目所述 APP 涉及人潮資訊、近距離接觸警示、感染者接觸通知，以及逐日累積的人際接觸史。這些功能會處理位置、接觸對象、時間與感染狀態等敏感資訊，故法律可行性是核心；即使技術可行，也不代表可以不受限制地蒐集、保存或揭露資料。

**法規時點：**以下以命題當年（民國 109 年）法規為準。個人資料保護法及傳染病防治法後續已有修正，實際適用應另依現行法判斷；本題仍按民國 109 年法制精神作答。

解題方法

依題目指定的三個層面逐項檢核：

1. **操作（作業）可行性：**使用者、企業及公衛機關能否配合新作業流程，且系統提供的資訊是否足以支援實際決策。
2. **技術可行性：**感測、辨識、資料交換與通知是否能達到所需正確度、即時性、可用性及安全性。
3. **法律可行性：**蒐集目的、法律依據、資料範圍、利用方式、保存期間及當事人權利是否符合規範。

結論應將可行性分析落到設計建議：保留能達成防疫目的的功能，同時減少個資處理、明確管理資料生命週期，並避免把系統訊號當成確診或接觸事實的唯一判定。

（一）作業、技術與法律可行性

1. 操作（作業）可行性

**有利條件：**APP 可協助使用者掌握人潮及近距離接觸風險，並在曾與確診者接觸時及早採取行動。若操作簡單、警示清楚且通知及時，可提升防疫資訊傳遞效率，減輕人工追蹤負擔。

限制與風險：

• 防疫效果仰賴一定比例民眾安裝、啟用並持續使用；未持有智慧型手機者、未開啟藍牙或定位者，以及不熟悉操作的使用者，均會形成追蹤缺口。
• 使用者須理解警示的意義並配合後續措施。過度頻繁或不準確的警報會造成警報疲乏，降低信任與使用意願。
• 「與確診者接觸」的通知需要可信且及時的確診資訊來源及跨機關作業流程。若通報延遲、資料錯置，或確診者未完成授權或登錄，通知效用便會降低。
• 若 APP 被誤認為確診、接觸或風險的正式認定工具，可能造成不當隔離、歧視或恐慌；警示應明確標示為風險提示，並引導使用者依主管機關指示處理。

**評估：**作業上有公共衛生效益，但依賴使用者信任、足夠採用率、明確的跨機關流程及妥善的錯誤處理機制。須同步規劃人工替代服務及申訴、查詢管道。

2. 技術可行性

可使用的技術：

• 藍牙低功耗（BLE）可估計裝置間的近距離接觸；GPS 或基地台資訊可估算位置、人潮或移動軌跡；伺服器可負責疫情資料比對與推播通知。
• 透過雜湊、代碼化、加密及存取控制，可降低資料外洩後直接辨識個人的風險。

技術限制與風險：

• 藍牙訊號強度會受牆壁、人體、手機型號及環境干擾，距離估計不等於實際社交距離；GPS 在室內或密集街區也有精度限制。
• 人潮推估受裝置攜帶率與資料回報率影響，不能代表現場所有人；定位與接觸資料也可能因網路中斷、手機未開機或背景程式受限而不完整。
• 「與確診者接觸」須先有可靠的確診資料、明確的比對規則及快速更新流程。系統也須防止偽造確診憑證、冒用身分、未授權查詢、重複或錯誤警報。
• 集中保存所有人的完整接觸史會提高伺服器遭入侵、內部濫用及資料關聯再識別的風險；加密雖能降低風險，並不會使個人資料自動成為匿名資料。
• 長期運作還須負擔系統維護、容量擴充、弱點修補、資安監控與資料刪除等成本。

**評估：**相關功能在技術上可建置，但位置及距離訊號只能作風險估計，不能保證完整、精確的接觸判定。系統應揭露其限制，並採取資料最小化、資安防護、稽核及故障處理措施。

3. 法律可行性

本題涉及可識別個人的位置、行蹤、社交關係及健康狀態，應先判斷是否構成個人資料及特種個人資料，再檢視蒐集與利用的依據、目的和範圍。將姓名改成代碼或加密，不必然排除個人資料保護法的適用；只要仍可合理連結或辨識個人，仍須依法保護。

（1）歐盟 GDPR 的立法精神

• **目的限制與資料最小化：**僅能為明確、正當的防疫目的處理必要資料，不應因技術上可以蒐集而累積所有人的完整人際接觸史。

核心觀念

本題考的是**系統發展生命週期（SDLC）**與政府資訊委外管理。資訊部門雖因人力不足而委外，但仍須負責需求把關、方案評估、採購規格、履約監督、驗收及後續維運安排；不能把「外包」等同於把資訊系統的責任一併交給廠商。

節省公帑的重點，是先確認業務需求與公共效益，再評估能否沿用既有系統、共用服務或採購成熟產品，避免重複建置；並透過明確規格、分階段驗收與全生命週期成本管理，減少變更、重工及維運支出。題目未要求特定法條，以下依系統生命週期及政府資訊委外的一般管理原則作答。

解題方法

依系統生命週期由前至後說明資訊部門的角色，並在各階段交代三件事：如何協助業務單位、如何管理受託廠商、如何控制成本與品質。常見階段可分為規劃、需求分析、系統設計、建置與測試、導入、維運及退場。

各生命週期階段之資訊部門角色

一、規劃與可行性評估

資訊部門應與業務部門共同釐清問題、服務對象、預期效益及績效指標，例如民眾使用率、服務完成時間、錯誤率及可用性；確認建置 APP 是否確為解決問題的必要方式，並盤點現有網站、APP、身分驗證、支付或訊息服務等資源，評估擴充、共用、改版或採購成熟產品的可行性。

另應評估技術、資安、個資、法遵、期程及經費可行性，估算建置、授權、雲端服務、維護、改版與退場等全生命週期成本，再與預期效益比較。若既有服務可滿足需求，優先採用或整合，避免重複開發。

二、需求分析與採購準備

資訊部門協助業務部門把需求轉成可驗收的規格，區分必要功能與加值功能，描述使用情境、服務流程、資料項目、介接需求、效能、可用性、無障礙、相容性、資安及個資保護要求。需求應避免指定不必要的特定品牌或技術，以利公平競爭並降低廠商綁定。

採購文件須明訂交付成果、里程碑、測試及驗收方式、缺失改善期限、保固與維護服務水準、變更管理、資安事件通報、資料與原始碼／文件交付、智慧財產權及契約終止後的移轉安排。以明確需求與驗收基準降低履約爭議和追加費用。

三、系統分析與設計

資訊部門審查廠商提出的系統架構、資料流程、介面設計及技術方案，確認其符合機關既有資訊架構、介接標準、資安政策及容量需求；同時檢視權限控管、加密、日誌、備份、弱點管理與個資最小化等設計。

設計階段即納入可維護性、可擴充性、跨平台支援及資料可攜性，要求產出系統設計文件、資料字典、介接規格及操作維護文件，避免日後只能由原廠維護而形成高額依賴。

四、系統建置與測試

核心觀念

本題考查物件導向分析中的使用案例圖（Use Case Diagram），重點是辨認系統外部角色、系統提供的功能，以及使用案例之間的關係。題目未要求特定 UML 版本；圖中依標準使用案例圖表示即可。

• 參與者（Actor）：與系統互動、提供服務或接受服務的外部角色。
• 使用案例（Use Case）：系統提供的一項可辨識功能，以橢圓表示。
• <<include>>：基礎使用案例每次執行都必須包含另一使用案例。
• <<extend>>：在特定條件成立時，才由擴充使用案例補充基礎使用案例的行為；箭頭由擴充案例指向基礎案例。

本題沒有涉及法規或法條。

解題方法

先找出系統邊界，再辨識角色與功能：

1. 系統邊界：建立「外來者防疫檢疫資訊系統」，邊界內放置由系統支援的使用案例；邊界外放置參與者。
2. 參與者：

• 外來者：接受篩檢、檢查並繳費。
• 醫師：執行病毒篩檢及必要時的 $\gamma$ 檢查。
• 移民局官員：調查過去 14 天的旅遊史。
• 檢疫帳務人員：辦理檢疫費用繳納。

3. 一般化病毒篩檢：以「執行病毒篩檢」作為共同使用案例，再由「執行 $\alpha$ 病毒篩檢」及「執行 $\beta$ 病毒篩檢」專門化。特定 $X$ 地區外來者使用 $\alpha$，其他地區外來者使用 $\beta$。
4. 必做與條件式功能：

• 每位外來者都要調查旅遊史、接受一種病毒篩檢，並在檢查完成後繳費，屬必要程序。
• 停留國外超過 $Y$ 日才加做 $\gamma$ 檢查，因此以條件式擴充表示。

5. 連結角色與功能：醫師連結病毒篩檢及 $\gamma$ 檢查；移民局官員連結旅遊史調查；檢疫帳務人員連結繳費。外來者連結其接受的各項程序。

使用案例圖

核心觀念

本題考查以兩組獨立測試人員發現錯誤的捕獲－再捕獲估計法（capture–recapture，也稱 Lincoln–Petersen 估計法），用重複發現的錯誤數推估程式中尚未被發現的錯誤。

估計時假設：兩隊測試能力相當、獨立測試，且每個錯誤被任一隊發現的機率大致相同。若 $N$ 為錯誤總數，則兩隊發現集合的重疊比例可近似為：

解題方法

令 $X$ 隊發現的錯誤集合為 $A$，$Y$ 隊發現的錯誤集合為 $B$。題目給定：

• $|A|=15$
• $|B|=18$
• $|A\cap B|=9$

依捕獲－再捕獲估計法：

代入數值：