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

核心觀念

本題評量軟體開發生命週期（Software Development Life Cycle, SDLC）中各階段的「交付標的（Deliverables）」與「文件化管理（Documentation Management）」。核心重點在於釐清：

1. 階段分工與層次演進：需求分析（定義問題與範圍）$\to$ 系統分析（建構邏輯模型，強調 What to do）$\to$ 系統設計（建構實體模型，強調 How to do）$\to$ 系統製作（程式撰寫、組裝與測試驗證）。
2. 文件的雙重功能：對外作為與利害關係人（機關使用者、管理階層）的「驗收基準與溝通契約」；對內作為團隊跨階段協作的「施工藍圖與品質稽核依據」。

---

解題方法

身為「專案經理（PM）」，答題切入點應兼顧「標準軟體工程規範（如 IEEE 830 / ISO/IEC/IEEE 29148）」與「題目特定情境（福林機關車輛管制系統）」。

1. 結構化分層呈現：依題目指定的四個階段（需求分析、系統分析、系統設計、系統製作）逐一開展，每一階段明確列出「應備文件名稱」與「準備目的」。
2. 扣緊題目情境：在文件的內容說明中，自然融入車輛進出管制、車牌辨識（LPR）、道閘控制、黑名單告警、月租／訪客管理等具體業務特徵，避免流於純理論背誦，爭取高分。

---

解題技巧

1. 嚴防「分析」與「設計」混淆：

• 系統分析文件：聚焦於「業務邏輯與概念模型」（如：使用案例模型、資料流程圖、概念資料模型）。
• 系統設計文件：聚焦於「技術架構與實體規格」（如：資料庫綱要 Schema、API 介面定義、道閘硬體通訊協定、循序圖）。

2. 必備文件的「標準英文縮寫」：適度寫出軟體工程通用術語（如 SRS、SDD、RTM），能展現專業度與作答精確度。
3. 目的撰寫公式： $\text{目的} = \text{對齊溝通（誰與誰）} + \text{技術指導（指導下一階段何項工作）} + \text{驗收與防錯（避免範疇潛移／做為測試基準）}$

---

【答案】

身為本專案之專案經理，針對福林機關「車輛管制系統」之開發，各階段團隊應準備之文件及其目的規劃如下：

一、需求分析階段（Requirements Analysis Phase）

1. 專案開發計畫書（Project Management Plan, PMP）

• 主要內容：定義專案範疇基準、時程里程碑（WBS）、人員組織權責、風險管理計畫及品質保證措施。
• 準備目的：確立機關與開發團隊的合作共識，作為專案執行、資源分配與時程監控的總體基準。

2. 軟體需求規格書（Software Requirements Specification, SRS）

• 主要內容：記載車輛管制系統之功能需求（如車牌辨識、門禁權限管制、訪客登記、收費計算）、非功能需求（如辨識反應時間 $\le 1$ 秒、系統可用度 $99.9\%$、高併發車流負載），以及外部環境限制。
• 準備目的：將使用者口頭或業務需求轉化為正式書面協定，建立專案之「範疇基準線（Scope Baseline）」，做為後續開發與驗收之法律與合約依據。

3. 需求追蹤矩陣（Requirements Traceability Matrix, RTM）

• 主要內容：建立每項業務需求與後續分析、設計、程式碼及測試案例之雙向對應關係。
• 準備目的：確保機關提出的每一項車管需求（如黑名單車輛通報）皆被落實於設計與測試中，避免範疇潛移（Scope Creep）或功能遺漏。

---

二、系統分析階段（System Analysis Phase）

1. 系統分析規格書／功能規格書（System Analysis Specification / Functional Specification）

• 主要內容：包含使用案例模型（Use Case Diagram & Use Case Specifications）、活動圖（Activity Diagram）或資料流程圖（DFD）、資料字典（Data Dictionary）及領域概念模型（Domain Model）。

核心觀念

本題測驗關聯式資料庫設計與概念資料塑模的核心理論——實體關係模型（Entity-Relationship Model, ER Model）中「關係的度數（Degree of a Relationship）」。

1. 關係度數（Degree）的定義：指參與同一個關係類型（Relationship Type）的實體類型（Entity Type）數量。
2. 度數分類：

• 一元關係（Unary / Recursive Relationship, Degree = 1）：同一個實體集內的實體彼此產生關聯，通常實體在關係中扮演不同的「角色（Role）」。
• 二元關係（Binary Relationship, Degree = 2）：最常見的關係型態，由兩個不同的實體集參與關聯。
• 多元關係（N-ary / Ternary Relationship, Degree $\ge 3$）：由三個或三個以上的實體集同時參與同一個不可分割的關係。

3. 區分度數（Degree）與基數（Cardinality）：度數是「參與實體集的個數」；基數（如 $1:1$、$1:N$、$M:N$）則是「一個實體能與另一實體關聯的實例數量上限」。

---

解題方法

1. 塑模語法選擇：採用國家考試最標準之 Peter Chen（陳品山）記法（Chen's Notation）。實體以矩形表示、關係以菱形表示，並於連線上標註對應的基數比率（Cardinality Ratio：$1$、$N$、$M$、$P$ 等）。
2. 實例選取策略：

• 挑選經典、具代表性且無語意爭議的企業實務模型（如組織架構、選課系統、供應鏈、醫療處方）。
• 一元關係必須標明「角色名稱（Role Name）」，以展現對遞迴關係語意的理解。
• 多元關係以「三元關係（Ternary Relationship）」最為典型，必須展現三個實體同時關聯的不可分割性（Atomicity），不可拆解為多個二元關係。

---

選項分析

本題為申論題，非選擇題。依閱卷評分標準，配分通常依題幹三個子題均分，各子題的評分要點如下：

• 第一子題（一元關係）：佔分關鍵在於能否清楚說明「同實體集內個體互動」之本質，並於圖形與說明中明確標示「角色（Role）」。若未標示角色，通常會被酌扣 1～2 分。
• 第二子題（二元關係）：佔分關鍵在於基數（$1:N$ 與 $M:N$）的多元展現與實務合理性，圖形連線與語意須嚴格對應。
• 第三子題（多元關係）：此為失分高危險區。常有考生誤將多元關係畫成「多個獨立的二元關係」，正確作法必須是一個中央菱形同時連向三個（含以上）實體矩形。

---

解題技巧

1. 角色標註防呆：繪製一元關係時，連線上務必寫出角色（例如「主管／部屬」、「主件／組件」），否則評審無法確認你是否理解同一實體集合內的不同語意定位。
2. 多元關係檢驗法：判斷是否為真三元關係，問自己一句話：「若抽掉其中一個實體，該筆關聯紀錄是否仍具完整商業意義？」若答案為否（例如：某供應商為某專案供應某零件，抽掉專案就失去該次供應的目的），則確定為三元關係，絕不可拆成兩個二元關係。
3. 符號簡潔：考卷作答版面有限，實體與關係屬性（橢圓形）可適度省略，聚焦於題目要求的實體矩形、關係菱形與基數標記。

---

【答案】

一、一元關係（Unary / Recursive Relationship）

1. 說明： 參與同一個關係的實體只有一個實體集（Degree = 1），又稱為「遞迴關係（Recursive Relationship）」。

核心觀念

本題考查軟體工程與系統分析中**系統開發生命週期（SDLC）之雛型法（Prototyping Methodology）**的理論與實務應用，核心考點包含：

1. 雛型法的適用情境：在面對「需求模糊」、「新技術導入（如大數據）」、「使用者缺乏具體概念」時，雛型法如何透過快速建構具體模型以釐清需求、降低開發風險。
2. 演進式雛型（Evolutionary Prototyping）：將雛型作為最終系統的基石，透過不斷反覆迭代（Iteration）擴充功能，最終直接演變為上線系統。
3. 拋棄式雛型（Throwaway Prototyping）：亦稱探索式雛型，製作雛型僅用來釐清特定需求、探討操作介面或進行概念驗證（PoC），一旦目標達成即將雛型捨棄，再以嚴謹架構重新撰寫正式系統。

---

解題方法

本題屬於標準的情境申論分析題，解題切入點分為兩大主軸：

1. 背景契合度分析（為什麼要用雛型法）：結合「基雲縣政府」與「大數據分析平台」的情境特性，指出政府機關跨局處整合、使用者非技術專家、大數據分析維度與演算法成果具不確定性等痛點，說明雛型法如何提供視覺化反饋以弭平認知落差。
2. 比較分析（演進式 vs. 拋棄式）：以結構化表格或條列並行方式，從「系統架構品質」、「開發時程與成本」、「技術債與維護性」、「使用者期望管理」四個構面分別論述兩者的優勢（利）與劣勢（弊），最後給予決策建議以扣合主管的疑慮。

---

選項分析

本題為申論題，非選擇題。作答時應將題意拆解為兩大子題進行針對性答題：

• 子題一（採用雛型法原因）：從「大數據特性（4V）」、「公部門使用者特性（非技術導向）」、「溝通成本與風險控制」三方面論述。
• 子題二（演進式與拋棄式利弊）：逐一對比兩者的運作機制、適用時機、潛在風險（如演進式的架構劣化、拋棄式的重複開發成本）。

---

解題技巧

1. 切忌泛泛而談：論述「為什麼用雛型法」時，必須扣合「大數據分析平台」的特徵（如資料視覺化儀表板 Dashboard、探索式資料分析 EDA、跨單位異質資料源），而非只背誦軟體工程課本的通用定義。
2. 點出關鍵痛點（主管遲疑的原因）：演進式雛型看似快且不浪費程式碼，但大數據平台極度仰賴底層分散式架構與資料管道（Pipeline）效能，若初期雛型缺乏嚴謹架構設計，演進到後期常面臨效能瓶頸與巨額技術債；拋棄式雛型架構穩健但初期成本看似沉沒。點出此一權衡是拿高分的關鍵。

---

【答案】

一、基雲縣政府開發大數據分析平台採用「雛型法」之原因分析

縣政府在推動「大數據分析平台」時，系統具備高度複雜性與不確定性，採用雛型法的主要原因如下：

1. 需求高度模糊與探索性特質： 大數據分析有別於傳統以交易為導向的管理資訊系統（MIS），其報表維度、關聯分析規則與預測模型往往無法在專案初期精確定義。公部門主管與業務承辦人員多缺乏資料科學背景，難以憑空提出具體需求規格，雛型法能提供「所見即所得」的具體回饋。
2. 介面與視覺化（Dashboard）溝通效益： 大數據的核心價值在於資料視覺化呈現。

核心觀念

本題評量系統發展生命週期（SDLC）在「規劃階段」（Planning Phase）中的**可行性分析（Feasibility Analysis）**架構，並測驗考生能否將理論結合特定新興科技（人臉辨識、生物特徵識別）與場域（公務機關）之特性進行申論。

核心架構採用系統分析與設計之標準 TELOS 模型：

1. 技術可行性（Technical Feasibility）：評估現有技術、軟硬體基礎設施與團隊能力能否實現系統。
2. 經濟可行性（Economic Feasibility）：透過成本效益分析（Cost-Benefit Analysis, CBA），評估專案財務合理性與效益。
3. 法律與法規可行性（Legal / Regulatory Feasibility）：檢視系統建置與資料蒐集是否符合法律規範與政策命令。
4. 作業／營運可行性（Operational Feasibility）：評估組織文化、使用者抗拒、作業流程變革及維運配套。
5. 時程可行性（Schedule Feasibility）：評估在目標期限內完成採購、開發、測試與上線的合理性。

法規與憲法依據（以命題當年民國 107 年法規為準）：

• 《個人資料保護法》：人臉特徵屬於生物特徵個人資料，公務機關依第 15 條規定，蒐集、處理或利用個人資料必須在「執行法定職務必要範圍內」，並應符合特定目的與比例原則。
• 司法院釋字第 603 號解釋：揭櫫憲法保障個人資訊自主權，要求國家基於重大公益目的且有法律明文授權時，始得蒐集具高度敏感性之個人生物特徵資料。
• （現行法提醒：國家後續成立個人資料保護委員會籌備處，並修正《資通安全管理法》與相關個人資料保護防護基準，對生物特徵與人臉辨識影像的保存年限、傳輸加密與存取稽核要求更加嚴格，但解題仍以命題當年為準。）

---

解題方法

本題為典型的「理論架構＋情境題」。若僅條列教科書定義（技術、經濟、作業、時程、法律），難以在調查局特考等高階三等考試中脫穎而出；必須緊扣「光華機關（政府公務機關）」與「人臉辨識系統（非接觸式高敏度生物特徵）」的關鍵屬性，提出「分析項目」並申述「為什麼（分析理由與風險）」：

1. 技術面向：聚焦於光線變化、遮蔽物（如口罩、眼鏡）、演算法誤識率（$FAR$）與拒識率（$FRR$），以及與既有門禁／警政／人事差勤系統的整合能力。
2. 法律與合規面向（重中之重）：公務機關蒐集人臉影像涉及隱私權與人權爭議，必須具備正當法律程序與授權基礎。
3. 作業與營運面向：著眼於機關同仁與洽公民眾對「全面監控」的疑慮與心理抗拒，以及系統辨識失敗時的人工備援措施。
4. 經濟面向：平衡邊緣運算（Edge AI）硬體、高解析攝影機與授權成本，與節省稽核人力／提升安全等級之間的產出比。
5. 時程面向：考量《政府採購法》招標期程、概念驗證（PoC, Proof of Concept）與實地壓力測試的時間限制。

---

選項分析

本題為國家考試之申論申述題，無固定選擇項目。答題時對可行性各維度在「人臉辨識專案」中的內涵進行對比解析：

• 技術可行性 vs. 規格驗證：可行性分析不是單純檢查伺服器規格，而是評估「動態環境下辨識率的極限」與「資訊安全（對抗假冒攻擊如照片、3D面具之活體檢測 Liveness Detection）」。若技術不可行，後續開發將全盤失敗。
• 法律可行性 vs. 行政常規：一般資訊系統（如公文系統）甚少深入評估法律可行性，但人臉辨識涉及憲法法益，若無法律依據蒐集，將面臨訴訟與違憲風險，是此系統成敗的前提。
• 作業可行性 vs. 操作介面（UI）設計：作業可行性重在「利害關係人接受度」與「例外流程」。若同仁因隱私疑慮集體抗拒或故意遮蔽鏡頭，系統將形同虛設。

---

解題技巧

1. 記憶口訣：利用英文字首「TELOS」（Technical、Economic、Legal、Operational、Schedule）或中文口訣「技、經、法、作、時」作為大標題骨架，確保面向不遺漏。
2. 切題關鍵詞置入：