107 地方特考三等 資訊處理 系統分析與設計 考古題詳解

核心觀念

本題評量考生在軟體工程與系統分析中​「軟體測試生命週期（Software Testing Life Cycle, STLC）」、「系統測試（System Testing）」​以及​「非功能性需求驗證」​之實務規劃能力。

核心理論依據包含：

1. 測試層級（Testing Levels / V-Model）：單元測試（Unit Test）、整合測試（Integration Test）、系統測試（System Test）與驗收測試（Acceptance Test）。
2. 測試類型（Testing Types）：功能性測試（Functional Testing）與非功能性測試（Non-Functional Testing，如效能、安全性、相容性、可靠性等）。
3. 情境特化分析（Context-Driven Testing）：本題題幹具備鮮明的領域特性——「外勤」（行動裝置、弱網環境、硬體感測器整合）與​「情蒐」（高度機敏性、資料完整性、即時性），若僅默背傳統教科書名詞，無法切合實際公務機關資訊專案的需求。

解題方法

本題切入點採用​「兩軸維度法」​展開：

• 第一軸（情境屬性）：切入「外勤環境限制」與「情蒐業務機敏性」。
• 第二軸（測試完整性）：兼顧「系統功能正確性」、「非功能性環境適應力」與「最終使用者驗收」。

因題幹已指明「即將完成開發工作，即將上線」，代表程式碼層級的單元測試與整合測試應已由開發團隊完成；此時機關資訊人員的重點應聚焦於系統層級的黑箱測試、非功能性驗證，以及實地使用者驗收測試。解題必須明確回答「建議哪些測試種類」並論述「為什麼（理由）」，二者缺一不可。

選項分析

本題為申論題（非選擇題），但考生在作答時常有​「測試層級與測試種類混淆」​之觀念謬誤，分析如下：

1. 僅回答「單元測試、整合測試、系統測試、驗收測試」者（不恰當）：

• 這是軟體工程中的「測試層級（Levels）」，並非主管詢問之「為確保上線運作順利的具體測試種類（Types）」。此時開發即將完成，單元測試階段已過，如此回答顯得未扣緊專案時程與實務情境。

2. 僅列舉泛用軟體測試，未對應「外勤情蒐」者（得分受限）：

• 若僅寫「功能測試、效能測試、相容性測試」，未能論及行動終端（GPS/相機）、弱網/離線同步（外勤關鍵）與資安保密（情蒐關鍵），會被評為缺乏實務經驗的樣版回答。

3. 結合「系統測試內涵」與「業務情境」者（最佳解法）：

• 系統化列舉功能、行動相容、離線與同步、資安防護、壓力效能及使用者驗收測試，並緊扣外勤作業動態環境與情資機密性，論述原因極具說服力。

解題技巧

1. 抓取題幹關鍵字架構答案：

• 「外勤」 $\to$ 聯想到行動裝置相容性、GPS 定位、離線暫存與連線同步、省電與弱聯網容錯。
• 「情蒐」 $\to$ 聯想到情資機敏性、傳輸與儲存加密、機密性／完整性／可用性（CIA）、身分驗證與稽核軌跡。
• 「即將完成／確保上線順利」 $\to$ 聯想到效能壓力測試（避免多人同時回傳崩潰）與使用者驗收測試（UAT，確認第一線外勤人員能順手操作）。

2. 標準評分結構公式：

• 每一小項採「【測試名稱】＋【測試內容／方法】＋【為什麼建議此測試（結合情境）】」三段式鋪陳，層次清晰，閱卷老師容易給分。

【答案】

針對貴機關即將上線之「外勤資訊情蒐系統」，身為機關資訊人員，在開發即將完成之驗收階段，應建議進行以下六大類型的測試：

一、 功能測試（Functional Testing）

• 測試內容：依據需求規格書（SRS），採黑箱測試技術（如等價劃分、邊界值分析）逐一驗證情資登錄、多媒體檔案（相片、影音、語

核心觀念

本題評量資料庫反向工程（Database Reverse Engineering）​與實體關係模型（ER Model, Entity-Relationship Model）​之概念塑模能力，主要核心觀念與定義包含：

1. 實體關係模型（ER Model）之核心構件（Peter Chen 標記法）：

• 實體（Entity）：客觀存在且可互相區分之物件或事物，於圖形中以「矩形」表示。
• 屬性（Attribute）：用以描述實體之特徵或性質，以「橢圓形」表示；底線標註者為「主鍵（Primary Key, PK）」。
• 關係（Relationship）：實體型態之間的相互關聯，以「菱形」表示，並標註連線之基數比（Cardinality Ratio，如 $1:1$、$1:N$、$M:N$）。

2. 關聯架構（Relational Schema）反向對映 ER 模型之轉換規則：

• 一般關聯表轉強實體（Regular Entity）：擁有獨立單一主鍵之表格，直接對應為強實體。
• 外鍵（Foreign Key, FK）轉實體關係：表格內包含參照至另一表格主鍵之外鍵時，該外鍵轉化為兩實體間的關係連線，不再以獨立屬性形式重複出現在 ER 圖中。
• 複合外鍵中介表轉多對多（$M:N$）關係或關聯實體：若某表格的主鍵是由兩個參照外部實體的外鍵共同組成（複合主鍵），代表兩端實體具備多對多關係；該中介表的其餘非鍵欄位，則轉化為掛載於關係菱形上的「關係屬性（Relationship Attribute）」。

解題方法

題目缺漏資訊與定案假設說明： 題目原卷包含實體關聯圖形，因掃描圖像未隨題文載入，缺漏具體表格圖形；本題依據考選部民國 107 年公職考試原卷題意與命題慣例，以該題所採用之經典訂單管理架構（包含「客戶」、「訂單」、「產品」、「訂單明細」四個關聯表及其主外鍵參照）作為合理假設進行定案解答。

1. 關聯架構（Relational Schema）分析

• 客戶（Customer）：主鍵為 客戶編號（PK），其餘欄位包含 姓名、電話、地址。
• 訂單（Orders）：主鍵為 訂單編號（PK），包含外鍵 客戶編號（FK，指向 客戶），其餘欄位包含 訂單日期。
• 產品（Product）：主鍵為 產品編號（PK），其餘欄位包含 產品名稱、單價、庫存量。
• 訂單明細（Order_Detail）：複合主鍵由 (訂單編號 FK, 產品編號 FK) 共同構成，其餘欄位包含 購買數量、成交單價。

2. 反向工程轉換與關係萃取步驟

• 步驟一（萃取實體）：
• 客戶（Customer）與 產品（Product）各自擁有獨立主鍵，對映為強實體。
• 訂單（Orders）擁有獨立主鍵 訂單編號，對映為實體。
• 步驟二（萃取 $1:N$ 關係）：
• 訂單 表中的外鍵 客戶編號 指向 客戶 表之主鍵，且該外鍵未設唯一性限制（Unique Constraint）。
• 推導：一位客戶可建立多筆訂單，一筆訂單僅隸屬於一位客戶，因此「客戶」與「訂單」之間存在基數比為 $1:N$ 的「下單（Places）」關係。
• 步驟三（萃取 $M:N$ 關係與關係屬性）：
• 訂單明細 表的主鍵由 訂單編號 與 產品編號 兩組外鍵複合而成，屬於多對多關聯的中介表（Junction Table）。
• 推導：「訂單」與「產品」之間存在基數比為 $M:N$ 的「包含（Contains）」關係。
• 訂單明細 中的非鍵欄位 購買數量 與 成交單價，其數值必須同時依附於特定訂單與特定產品才能確立，故轉化為「包含」關係之關係屬性。

選項分析

本題為申論題（非選擇題），無個別選項；評分核心著重於考生能否正確區分「概念層（ER 模型）」與「實體/邏輯層（關聯綱要）」之差異，並在圖形中精確表達各構件的圖示標準與關聯基數。

解題技巧

1. 外鍵消除原則（關鍵失分陷阱）： 在邏輯關聯表中，「外鍵」是實現關聯的機制；但在概念層的 Peter Chen ER 模型中，關係已由「菱形」具體表達，因此實體屬性中絕對不可再繪入外鍵欄位（例如「訂單」實體下不可畫出「客戶編號」橢圓），若重複繪出會被閱卷委員視為觀念混淆而扣分。

核心觀念

本題評量系統分析與設計中處理邏輯塑模（Process Logic Modeling）​的核心工具。當規格書中出現多條件、多規則的分支商業邏輯時，系統分析師需利用結構化工具消除自然語言的歧義性（Ambiguity）。

1. 決策表（Decision Table）：以表格方式列舉所有可能條件組合與對應動作。標準結構包含四象限：

• 條件樁（Condition Stub）：列出所有決策條件。
• 條件條（Condition Entry）：列出條件之狀態值（如 $Y/N$ 或特定數值）。
• 動作樁（Action Stub）：列出系統所有可能執行的動作。
• 動作條（Action Entry）：以符號（如 $X$ 或 $\checkmark$）標記在特定規則下應執行的動作。

2. 決策樹（Decision Tree）：以樹狀階層結構由左至右（根節點至葉節點）展開條件判斷與最終動作，特別適合呈現具有先後順序性的邏輯判斷。
3. 決策流程圖（Decision Flowchart）：採用標準 ANSI/ISO 流程圖符號（菱形代表判斷、矩形代表處理、橢圓代表端點），呈現程式控制流（Control Flow）與執行順序。
4. 結構化英文（Structured English）：使用受限詞彙（如 IF、THEN、ELSE、SELECT CASE、縮排與邏輯運算子），結合自然語言描述演算法邏輯，兼具可讀性與程式虛擬碼（Pseudocode）的嚴謹性。

解題方法

1. 條件變數分析：

• 設請假天數為 $D$（單位：天）。
• 題目包含三個互斥區間（MECE 原則）：
• 區間一：$D \le 1$
• 區間二：$1 < D \le 3$
• 區間三：$D > 3$

2. 動作分析（注意「累加核可」要求）：

• $D \le 1$：需【課長核可】。
• $1 < D \le 3$：除課長外加處長，即需【課長核可】＋【處長核可】。
• $D > 3$：除課長、處長外加協理，即需【課長核可】＋【處長核可】＋【協理核可】。

3. 工具塑模策略：

• 決策表採用標準有限項決策表（Limited-Entry Decision Table），透過兩道連續條件判斷消去無效狀態，建立 3 條明確規則（$R_1, R_2, R_3$）。
• 決策樹以「請假天數」為起點，向右分出三個條件分支，末端標註累計簽核層級。
• 流程圖依序判斷天數是否滿足門檻，流向對應的簽核處理程序。
• 結構化英文使用標準巢狀 IF-THEN-ELSE 語法呈現。

解題技巧與常見陷阱

1. 累加核可陷阱：題目敘述為「課長之外，還需要處長核可」，代表審核為累進關卡，絕不可在動作項目中單選「處長核可」或「協理核可」，每一級都必須包含前置主管。
2. 邊界值（Boundary Value）定義：

• 「一天以內」含本數（$\le 1$）。
• 「超過一天、三天以內」為大於 1 且小於等於 3（$1 < D \le 3$）。
• 「超過三天」不含 3（$> 3$）。 條件劃分必須界定清楚，不得出現 $D=1$ 或 $D=3$ 歸屬不清的情形。

核心觀念

本題評量物件導向系統分析與設計（OOAD）中 UML 使用案例塑模（Use Case Modeling） 的基礎能力，包含兩大重點：

1. 使用案例圖（Use Case Diagram）之組成要素：

• 參與者（Actor）：系統外部與系統互動的角色，通常以小人符號（Stick Man）表示。本題參與者為「房東」與「學生」。
• 使用案例（Use Case）：系統所提供可為參與者產出可觀察價值之完整功能單元，以水平橢圓形表示，內部命名慣例為「動詞＋名詞」。
• 系統邊界（System Boundary）：標示系統範圍的矩形框線，使用案例位於矩形內部，參與者位於矩形外部。
• 關聯關係（Association）：參與者與使用案例之間的實線連結，代表兩者間存在溝通或觸發行為。

2. 使用案例文字描述（Use Case Description / Specification）之標準規範：

• 包含：使用案例名稱、主要參與者、摘要說明、前置條件（Pre-conditions）、後置條件（Post-conditions）、主要成功流程（Basic Flow）及例外／替代流程（Alternative/Exception Flow）。

解題方法

1. 繪圖切入點：

• 繪製外層矩形代表「校園住宿服務系統」之系統邊界。
• 將主要參與者「房東」與「學生」置於邊界兩側（或左側）。
• 嚴格依照題目指示，於系統邊界內放置三個核心使用案例：「增加租屋單位」、「減少租屋單位」、「搜尋租屋單位」。
• 依據業務邏輯連線：房東連結「增加租屋單位」與「減少租屋單位」；學生連結「搜尋租屋單位」。

2. 文字描述切入點：

• 採用軟體工程界公認標準之結構化格式（類似 Cockburn 或 RUP 範本）。
• 明確交代事件觸發者、輸入資訊、系統處理與驗證、輸出呈現，以及資料庫狀態改變（後置條件）。

選項分析

本題為申論實作題，非選擇題，故無選項分析。

解題技巧

1. 嚴守題意邊界，切忌畫蛇添足（Over-engineering）： 題目已明確限定「共有三個使用案例」，考場上切勿自行補充「登入」、「會員註冊」、「審核租屋」等其他案例，更不要隨意加入不必要的 <<include>> 或 <<extend>> 關係，以免偏離閱卷評分標準。
2. 命名規範性： 使用案例命名必須為具體的業務動賓詞組（如：「增加租屋單位」），不可使用模糊名稱（如「租屋處理」）。
3. 文字描述層次化： 閱卷委員批改速度快，文字描述應採「條列式結構」編寫，必備「前置條件」、「主要流程（步驟編號 1, 2, 3...）」與「後置條件」，展現專業答題架構。

【答案】

一、校園住宿服務系統之使用案例圖

graph LR
 subgraph System ["校園住宿服務系統 (Campus Housing Service System)"]
 UC1(["增加租屋單位"])
 UC2(["減少租屋單位"])
 UC3(["搜尋租屋單位"])
 end

 Actor1["房東 (Landlord)"]
 Actor2["學生 (Student)"]

 Actor1 --- UC1
 Actor1 --- UC2
 Actor2 --- UC3

圖形組成說明：

1. 系統邊界：外圍矩形框代表「校園住宿服務系統」。
2. 參與者（Actor）：外側實體，分別為「房東」與「學生」。
3. 使用案例（Use Case）：系統內之三個橢圓節點（增加租屋單位、減少租屋單位、搜尋租屋單位）。