114 調查局特考三等 資訊科學組 系統分析與設計 考古題詳解

核心觀念

本題考查系統開發生命週期（System Development Life Cycle, SDLC）的階段、各階段應處理的工作與文件產出，以及如何將生命週期概念套用到一個具體資訊系統。題目已指定流程為「目標需求分析 → 系統設計 → 系統建置 → 測試 → 部署 → 維護」，作答時應依序說明每階段的工作內容、主要產出及高鐵訂票系統的應用。

SDLC 是系統從需求形成、設計與實作，到交付使用及持續維護的管理架構。各階段會使用前一階段的成果作為輸入，並形成可供下一階段使用或審查的文件。不同機關或專案的文件名稱可能略有差異，重點在於文件能留下可追溯的需求、設計、測試與維運依據。

解題方法

以題目指定的六階段為主軸，逐階段回答三件事：

1. 處理內容：該階段要解決什麼問題、執行哪些工作。
2. 文件產出：將決策與成果記錄為何種文件。
3. 案例應用：將訂票、查詢、取消三種功能具體化，並呈現其由需求逐步轉成設計、程式、測試與維運工作的過程。

案例應維持題目限定範圍，不額外擴充付款、會員、取票等功能。訂票、查詢與取消所共用的資料，如車次、座位、訂位紀錄及訂位代碼，則可作為必要的系統資料範圍說明。

各階段內容、文件產出與高鐵訂票系統案例

一、目標需求分析

**處理內容：**確認系統的目標、使用者與利害關係人、現行作業問題、功能需求及非功能需求，並界定專案範圍。需求應具體、可理解、可驗證，避免只寫「系統要方便」等無法驗收的描述；同時確認需求的優先順序、限制與驗收條件。

主要文件產出：

• 專案章程或專案範圍說明書
• 需求規格書（SRS）
• 使用案例圖、使用案例描述或需求流程圖
• 需求追溯矩陣及需求確認紀錄

**高鐵案例：**訪談旅客、客服與訂位系統管理人員，界定本系統只處理訂票、查詢及取消。

• **訂票需求：**旅客輸入乘車日期、起訖站及車次等條件後，系統檢查班次與座位狀況；訂票成功時建立訂位紀錄，產生訂位代碼並回覆結果。
• **查詢需求：**旅客可依訂位代碼等指定條件查詢訂位內容及目前狀態。
• **取消需求：**旅客提出取消請求後，系統核對訂位資料及取消資格；符合規則時更新訂位狀態並釋出座位。
• **非功能需求：**明訂可用性、回應時間、資料正確性、存取控制、操作紀錄與尖峰負載等要求。訂位與座位狀態更新須避免同一座位被重複分配。

二、系統設計

**處理內容：**將需求轉換為可實作的系統藍圖，決定系統架構、模組、資料結構、介面、流程、權限及安全控制。設計須能追溯至需求，並考量效能、可靠性、備援與資料一致性。

主要文件產出：

• 系統設計規格書（含架構、模組及介面設計）
• 資料庫設計文件，如 ERD、資料字典及資料表定義
• 程式規格或詳細設計文件
• 畫面原型、介面規格、權限與安全設計文件

**高鐵案例：**將系統劃分為訂票、查詢、取消及共用資料存取等模組。設計訂位紀錄、車次、座位與訂位狀態等資料結構；規劃訂票時如何檢查並鎖定座位，避免併發請求造成重複訂位；規劃查詢條件及結果畫面，以及取消時的資格驗證、狀態更新與座位釋出流程。

三、系統建置

**處理內容：**依設計文件開發程式、資料庫及介面，完成必要的組態設定與程式碼檢查，並將程式及建置方式納入版本管理。建置過程應保留可重複部署及後續維護所需的紀錄。

主要文件產出：

• 程式原始碼、建置與部署腳本
• 資料庫建立及資料轉換腳本
• 程式註解、模組文件及組態文件
• 程式碼審查紀錄與版本紀錄

核心觀念

本題考查軟體測試的四種觀點：黑箱測試與白箱測試著重測試依據不同；壓力測試與滲透測試則分別著重系統負載能力與安全弱點。作答時應先說明定義，再以同一個中醫診所線上約診系統，分別列出測試情境、操作方式及預期結果。

題目未提供系統規格，以下假設系統具有病患登入、診次與名額管理、預約紀錄及權限控管；每個診次有預定名額，同一病患不得重複預約同一診次。

解題方法

依測試目的切入：

1. 黑箱測試：不查看程式內部，從輸入、操作及輸出驗證功能是否符合需求。
2. 白箱測試：依程式邏輯、控制流程及資料處理路徑設計測試，檢查重要分支是否執行正確。
3. 壓力測試：施加高於一般預期的使用負載，觀察效能、穩定性及資源耗用。
4. 滲透測試：以受控的攻擊手法檢查安全弱點，確認未授權者能否存取資料或執行操作。

黑箱測試

**定義：**黑箱測試不檢視程式碼或內部實作，只根據需求規格輸入測試資料，再比對系統輸出是否符合預期。常用方法包括等價分割、邊界值分析及狀態轉換測試。

約診系統範例：

• **預約成功：**選擇尚有名額的診次並送出預約。預期系統建立預約紀錄、顯示成功訊息，且診次剩餘名額減一。
• **名額已滿：**對額滿診次送出預約。預期系統拒絕預約，顯示額滿訊息，不產生有效預約紀錄。
• **重複預約：**同一病患對同一診次再次送出預約。預期系統依規格拒絕重複預約，且不重複扣減名額。
• **取消預約：**病患取消一筆尚可取消的預約。預期預約狀態改為已取消，診次名額依規格釋出；若已超過取消期限，則顯示不可取消。
• **查詢預約：**病患查詢自己的預約。預期只顯示該病患的預約及正確狀態、日期、時段與診別。

白箱測試

**定義：**白箱測試檢視程式結構與邏輯，依控制流程、條件分支、迴圈及資料處理路徑設計案例。常見衡量方式包括陳述覆蓋、分支覆蓋與條件覆蓋。

約診系統範例：

以「預約」程式流程為例，檢查下列分支是否都被測試：

• 使用者未登入：程式應導向登入或拒絕操作。
• 使用者已登入，但診次不存在或已停診：應拒絕預約。
• 診次存在且尚有名額，但使用者已有相同診次的有效預約：應拒絕重複預約。
• 診次存在、尚有名額且沒有重複預約：應建立預約並扣減名額。

再檢查「取消預約」的程式路徑：預約不存在、預約屬於其他病患、已取消、超過取消期限，以及可取消等情況，都應有對應分支與預期處理。

核心觀念

本題在考生成式 AI 輔助軟體開發的適用情境、開發流程，以及如何把需求分析、系統設計、程式實作與測試整合成一個可驗證的成果。

Vibe Coding 是以自然語言描述需求，透過 AI 協助產生、修改及解釋程式碼的開發方式。開發者負責界定需求、選擇技術方案、檢視程式碼、執行測試及承擔系統品質；AI 則是加速開發的輔助工具，不能取代需求確認、資安審查或測試。

Vibe Coding 特別適合：

• 原型與概念驗證：快速呈現畫面及操作流程，確認需求是否符合使用者期待。
• 範圍明確的小型應用：例如查詢頁面、資料轉換工具、簡易儀表板或內部使用的小工具。
• 重複性或樣板程式：例如表單、基本 CRUD、欄位驗證、測試案例及文件初稿。
• 探索新技術或學習用途：請 AI 示範程式架構、API 串接方式，或解釋錯誤訊息。

若系統涉及高度機敏資料、複雜交易、關鍵基礎設施、嚴格法規遵循，或錯誤可能造成重大損害，仍須由專業人員主導架構、安全及品質審查。AI 產生的程式碼可能不符合實際需求、包含錯誤或有安全弱點，不能未經檢查便直接上線。

解題方法

作答可依「需求界定 → AI 協作產生 → 人工檢視 → 測試修正 → 部署維護」說明。這種切入方式能涵蓋系統分析與設計的完整生命週期，也能凸顯 Vibe Coding 的關鍵：以自然語言和 AI 反覆協作，但由開發者驗證成果。

1. 界定問題與需求：說明使用者、功能、輸入輸出、限制條件及驗收標準。
2. 拆解工作與選定方案：將需求分成畫面、資料來源、商業邏輯、錯誤處理及部署等部分；選擇適當架構與技術。
3. 以提示詞請 AI 產生程式：提供明確的需求、技術限制、資料格式及預期行為，逐步產生而非一次要求完成整套系統。
4. 檢視與整合程式碼：確認程式是否符合需求，檢查資料流、錯誤處理、輸入驗證、授權及敏感資訊處理。
5. 執行測試並迭代修正：以正常、邊界及異常情境驗證功能；將錯誤與預期行為具體回饋給 AI，再檢視修改結果。
6. 部署與持續維護：完成使用者驗收、環境設定及部署，並監控資料來源、系統錯誤與依賴套件更新。

匯率查詢網站範例

一、需求分析

假設網站供一般使用者查詢匯率，基本需求如下：

• 使用者選擇原幣、目標幣別並輸入金額。
• 系統顯示匯率、換算金額、資料來源及更新時間。
• 使用者可查詢多種常用幣別。
• 若匯率服務無法連線、回傳資料不完整或輸入金額不合法，系統須顯示清楚訊息。
• 匯率資料由外部匯率 API 提供，不在網站程式中硬編碼成固定數值。

可訂定驗收條件，例如：輸入有效金額及幣別後，系統顯示依最新可取得匯率計算的結果；輸入負數或非數字時拒絕計算；API 失敗時提示服務暫時無法使用，而不是顯示錯誤或過期結果為最新匯率。

二、設計與拆解

先將網站分成三部分：

• 前端介面：幣別選擇、金額輸入、查詢按鈕及結果顯示。
• 後端服務：呼叫匯率 API、驗證輸入、計算換算金額及處理錯誤。
• 外部資料來源：提供匯率及更新時間；

核心觀念

本題考查 UML 類別圖的建模：從表單欄位辨認類別與屬性，從表單作業辨認方法，再用關聯、多重度及組合關係描述資料之間的結構。屬性需標示名稱、資料型別與存取權限；方法需標示名稱、參數、回傳型別與存取權限。

題目提供的是表單資料，沒有指定系統操作細節。以下將「新增請求人、檢核資料、登錄證明文件、計算交付份數」作為合理的系統方法設計；不把這些設計補充視為表單明載的規則。

解題方法

先把重複出現的姓名、性別、國籍、出生年月日、身分證明及住所整理為 Person。再用 RequestParticipant 表示某人在某份公證請求中的角色，角色包含請求人、結婚當事人及證人。這樣同一人可兼具請求人與結婚當事人等身分，也能表達表單所列的兩位結婚當事人及兩位證人。

公證請求本身保存請求事項、公證日期及受文機關；證明文件與交付份數各自設為類別，對應表單中的證明文件清單，以及正本、繕本、譯本份數。

類別圖