112 地方特考三等 資訊處理類科 資訊管理 考古題詳解

核心觀念

本題考查系統開發生命週期中，瀑布模型的三個前期階段：需求分析、系統分析、系統設計。答題時要區分三個層次：

• 需求分析：確認利害關係人需要什麼。
• 系統分析：把需求整理成完整、一致且可驗證的系統規格。
• 系統設計：決定系統如何實作，以符合分析規格。

以縣政府線上申辦網站為例，需求可能包含民眾線上填表、上傳附件、查詢案件進度，以及承辦人員受理、審核與通知等服務。

（1）三階段的工作內容

需求分析階段：確認問題與需求

此階段與民眾、承辦人員、主管及資訊人員等利害關係人溝通，釐清建置系統的目的、範圍與使用情境，並蒐集、分析及確認需求。

主要工作包括：

• 確認系統服務對象、使用者角色及系統範圍。
• 蒐集功能需求，例如線上填寫申請、上傳文件、送出申請、查詢進度、承辦人審核及通知結果。
• 蒐集非功能需求，例如資訊安全、個人資料保護、易用性、可用性、效能、可維護性及無障礙需求。
• 確認限制條件與外部介接需求，例如既有身分驗證服務、政府共用平台或資料庫。
• 與使用者確認需求，處理歧異並排定優先順序。

主要產出是經確認的需求文件或需求規格，說明系統應提供的服務與品質要求。此階段重點在「要解決什麼問題、使用者需要什麼」，不先決定程式架構或資料庫技術。

系統分析階段：建立系統規格與行為模型

此階段將已確認的需求進一步整理、分解並建模，界定系統邊界及各項功能如何運作，使需求具備一致性、完整性與可驗證性。

主要工作包括：

• 分析使用者與系統的互動，可用個案、流程圖或情境描述呈現。
• 分析申辦流程，例如填表、資料檢核、送件、受理、補件、審核、核准或駁回、通知及結案。
• 定義輸入、處理、輸出、例外情況及權限規則。
• 分析資料需求與資料關係，例如申請案件、申請人、附件、承辦紀錄及審核結果。
• 檢查需求間是否一致，並定義可供驗收的條件。

主要產出是系統需求規格及分析模型，例如流程模型、資料模型、個案描述與功能規格。此階段回答「系統必須如何表現、如何處理各種情況」，但仍著重於邏輯規格，不必先指定實際的程式語言或伺服器設備。

系統設計階段：規劃實作方式

此階段依據分析規格，設計可實際建置的系統方案，將邏輯需求轉為技術與實作層面的規劃。

主要工作包括：

核心觀念

本題考查資訊安全的 CIA 三要素，並要求將抽象原則落實到市立醫院的病患資料、電子病歷及醫療資訊系統：

• 機密性（Confidentiality）：只有經授權的人員，才能讀取病患與病歷資料。
• 完整性（Integrity）：資料必須正確、完整，且任何新增、修改或刪除都能由適當授權者執行並留下紀錄。
• 可用性（Availability）：經授權的醫療人員在需要時，能及時、安全地使用系統與資料。

醫療資料兼具高度隱私性與即時醫療用途。資安措施因此須同時保護個人隱私、維持病歷正確，並確保診療不中斷。

解題方法

依 CIA 三要素分段作答，每一項都以「安全目標 → 醫院情境中的威脅 → 可執行的控制措施」展開。措施應涵蓋人員、制度與技術，並兼顧急診、手術及災害復原等醫療作業需求。

（一）機密性：防止未授權讀取或洩漏

病歷包含身分、病史、檢查結果、診斷及用藥等敏感資料，應依職務與照護關係限制存取。

1. 身分驗證與最小權限：每位醫護及行政人員使用個人帳號，採用多因素驗證；依職務設定角色權限，僅提供執行業務所需的資料。例如，醫師可查看照護病患的病歷，非照護關係人員不得任意查閱。
2. 依情境控管存取：可依病患照護關係、工作職責、登入地點及時段限制資料存取。緊急情況設置「緊急破窗」機制，要求填寫理由並事後稽核。
3. 加密與安全傳輸：病歷在資料庫、備份媒體及行動裝置中加密；系統間傳輸採加密通道，避免資料遭竊聽或截取。金鑰應妥善保管並定期輪替。
4. 防止外洩並管理人員行為：限制大量下載、列印、複製及以未核准的個人裝置儲存資料；對異常查詢或大量匯出設定警示。員工離職或職務異動時，應即時停用或調整權限，並定期進行隱私與資安教育。

（二）完整性：確保病歷正確、未遭不當變更

錯誤或遭竄改的病歷可能導致誤診、錯誤用藥或延誤治療，因此必須控制資料變更並保留可追溯紀錄。

1. 權限與流程控管：依職務授予新增、修改及核准權限；重要醫囑、檢驗結果或病歷更正可採覆核或雙人確認。病歷修改應保留原始內容，不應無痕覆寫。
2. 稽核軌跡：記錄使用者、時間、病患資料項目、操作類型及變更前後內容；

核心觀念

決策支援系統（Decision Support System, DSS）運用資料、分析模型與人機互動，協助管理者處理半結構化或非結構化問題。題目要比較兩種 DSS，並將它們放進智慧城市的具體情境說明：

• 資料導向 DSS（Data-Oriented DSS）：以大量、整合且可查詢的資料為核心，協助使用者掌握現況、發現趨勢與異常。常見技術包括資料倉儲、線上分析處理（OLAP）、資料探勘、儀表板與即時資料串流分析。
• 模式導向 DSS（Model-Oriented DSS）：以數學、統計、最佳化、模擬或人工智慧模型為核心，將資料代入模型，評估方案、預測結果或找出較佳決策。常見技術包括預測模型、排程與最佳化、模擬、地理資訊模型及數位分身。

兩者的重點不同：資料導向系統著重「從資料了解狀況」，模式導向系統著重「透過模型比較與選擇行動」。實務上通常會整合使用。

解題方法

可依「資料蒐集與分析」及「模型推演與決策」兩條主軸作答，再分別套用到交通、能源、災害等智慧城市應用。每個例子都要交代：

1. 系統使用哪些資料或模型；
2. 系統協助管理者回答什麼問題；
3. 分析結果如何支援決策。

只列出「大數據、人工智慧、物聯網」等技術名稱，未說明它們如何支援決策，無法完整呈現 DSS 的用途。

智慧城市應用舉例

核心觀念

資料探勘是從大量資料中找出有用的模式、關聯或預測資訊。依分析時是否有已知的目標答案，可分為非監督式與監督式：

• 非監督式資料探勘：資料沒有事先標記的答案或類別，演算法自行尋找資料內部的結構與規律，常見任務包括分群、關聯分析及降維。
• 監督式資料探勘：資料具有已知結果標籤，透過含有「輸入資料與正確答案」的訓練資料建立模型，再用模型預測新資料。常見任務包括分類與迴歸。

解題方法

作答時可抓住「有沒有已知標籤」這個核心差異，再分別說明模型的目的及客戶購買資料的應用。非監督式是從資料中發現未知結構；監督式則是利用過去已知結果學習預測規則。

兩者差異

例如，若資料只有「顧客買了哪些商品」，沒有顧客類型標籤，就可採非監督式分析；若歷史資料另有「顧客是否回購」的標記，就可用監督式方法預測新顧客的回購情形。

客戶購買資料的運用

非監督式：找出客群與商品關聯

1. 客戶分群 依顧客購買的品項、金額、頻率、季節及折扣使用情形分群。例如，分析後發現一群顧客常買低價基本款、購買頻率高；另一群顧客偏好新品與高單價商品。店家可據此設計不同的促銷活動、商品組合或會員服務。