113 調查局特考三等 資訊科學組 系統分析與設計 考古題詳解
第 一 題25 分
請解釋安全軟體開發生命週期（Secure Software Development Life Cycle），並說明各階段的主要目標、具體活動及應完成的事項。請注意到整個安全軟體開發生命週期的階段數目不得少於七個。
登入後即可作答並保存紀錄。
核心觀念
安全軟體開發生命週期（Secure Software Development Life Cycle, Secure SDLC）是把安全需求、風險管理與安全驗證整合進軟體從規劃、開發、發布、維運到退役的完整生命週期。安全不是只在程式完成後才做一次滲透測試，而是從需求階段就開始考量，並在各階段持續驗證與修正。
本題要求階段數目不少於七個，因此以下依實務常見流程整理為九個階段。不同機關或開發方法可能將部分階段合併或再細分，但核心原則相同：每階段都要有明確的安全目標、執行活動與可檢視的交付事項。敏捷或 DevSecOps 專案也適用此原則，只是安全活動通常會在每個迭代中反覆進行。
**解題方法：**依軟體從需求到退役的時間順序列出階段，再為每階段說明「目標、活動、交付事項」。作答時應呈現安全工作如何一路延續，並避免只列一般 SDLC 階段名稱而未說明安全內容。
各階段的目標、活動與應完成事項
| 階段 | 主要目標 | 具體活動 | 應完成事項 |
|---|---|---|---|
| 一、規劃與啟動 | 決定專案的安全治理方式與初步風險範圍。 | 界定系統範圍、使用情境及資料敏感度；辨識利害關係人與法令或組織政策要求；指定安全負責人、資源、時程及審查關卡；評估是否採用第三方服務或元件。 | 專案計畫、安全治理與責任分工、初步風險評估、適用安全政策與審查關卡。 |
| 二、安全需求分析 | 把安全需求轉成可設計、可實作、可驗證的條件。 | 蒐集機密性、完整性、可用性、身分驗證、授權、稽核、隱私及資料保護需求；分析濫用情境與業務風險；訂定安全需求優先順序及驗收標準。 | 安全需求規格、濫用案例或安全情境、需求追溯資料、安全驗收準則。 |
| 三、架構與安全設計 | 以安全架構及控制措施回應已知需求與風險。 | 設計系統元件、信任邊界、資料流與部署架構；進行威脅建模，辨識攻擊面、威脅及可能影響；選擇身分驗證、授權、加密、輸入驗證、日誌及錯誤處理等控制措施；檢視最小權限與縱深防禦原則。 | 系統與安全架構圖、資料流程圖、威脅模型、風險處置與安全控制設計、設計審查紀錄。 |
| 四、安全實作 | 依安全設計與安全編碼規範產生程式碼。 | 使用受控的原始碼管理與程式碼審查流程；遵循安全編碼規範；驗證輸入、妥善處理錯誤與權限；避免硬編碼密碼或金鑰；使用經核可的函式庫與元件；以靜態程式碼分析輔助檢查。 | 原始碼、程式碼審查紀錄、靜態分析結果、第三方元件及版本清單、已知問題與處理紀錄。 |
| 五、整合與安全建置 | 確保元件整合、編譯及封裝過程未引入或掩蓋安全弱點。 | 在受控環境中執行建置；限制建置系統與發布憑證的存取權限；驗證套件來源與完整性；檢查相依套件、容器映像及組態；保護程式碼、建置產物與簽章金鑰。 |
第 二 題25 分
請列舉並解釋至少三種不同的系統設計方法，並詳細說明這些方法之間的差異。請特別指出那些系統設計方法是互斥的，並提供具體的解釋和說明。如果沒有具體的解釋和說明，將不予計分。
登入後即可作答並保存紀錄。
核心觀念
本題考查系統分析與設計中的設計典範，以及不同典範對系統結構、資料與處理程序的看法。回答時須先說清楚各方法的設計單位與建模重點，再比較其差異；題目特別要求指出互斥的方法，不能只列名稱。
「互斥」指同一系統在主要設計模型上採取彼此不同的基本觀點，不能把兩套觀點不加區分地混成同一套模型。這不代表實務專案不能同時使用不同方法處理不同子系統，也不代表某種方法完全不能借用另一種方法的工具。
解題方法
作答可按「設計觀點、主要元素、適用情境、與其他方法的差異」逐一說明，再指出典範上的互斥關係。以下列出結構化設計、物件導向設計與敏捷設計；其中前兩者的核心分解觀點互斥，敏捷設計則主要是開發與設計演進方式，不能與前兩者視為同一層次的互斥典範。
一、結構化設計（Structured Design）
結構化設計以「程序與功能」為中心，先由系統整體功能逐層分解，再將功能分派至模組。常見工具包括資料流程圖、結構圖與模組規格。
設計時會分析輸入、處理及輸出，辨識資料轉換與控制流程，並依模組化、低耦合、高內聚等原則安排程式模組。模組通常透過參數或資料傳遞合作。
例如，圖書借閱系統可分為「受理借閱」、「檢查讀者資格」、「確認館藏」、「登錄借閱」等功能模組；設計重點在各功能如何分解及串接。
二、物件導向設計（Object-Oriented Design）
物件導向設計以「物件」為中心，將具有共同狀態與行為的概念封裝成類別，再由類別建立物件。主要模型包括類別圖、物件互動圖及狀態圖等，常見原則包括封裝、繼承、多型及低耦合、高內聚。
物件不只負責執行功能，也持有並管理自身資料，透過訊息或方法呼叫與其他物件合作。設計者會辨識領域中的實體、其狀態、責任及彼此關係。
例如，圖書借閱系統可設計「讀者」、「館藏資料」、「借閱紀錄」等類別，由各物件負責讀者資格、借閱狀態及借閱紀錄等相關行為。
三、敏捷設計（Agile Design）
敏捷設計強調短週期、反覆增量及持續回饋。設計不必在開發初期一次完成，而是依每次迭代的需求，先設計並實作目前需要的功能，再透過測試、使用者回饋與重構逐步調整。
其重點是讓設計能因應需求變化，維持程式碼可理解、可測試及易於修改。敏捷是一種設計與開發的工作方式，並未規定系統必須以程序或物件作為唯一的建模單位，因此敏捷團隊仍可採用物件導向或結構化的技術
第 三 題25 分
請解釋何謂變異測試（Mutation Test）及說明其原理，另請舉例說明變異測試如何運作。
登入後即可作答並保存紀錄。
核心觀念
變異測試（Mutation Testing）是一種評估測試案例品質的測試技術。它在原始程式碼中刻意植入小幅、常見的程式錯誤，產生多個「變異程式」（mutants），再檢查既有測試案例能否發現這些錯誤。
每個變異程式通常只做一項小修改，例如：
- 將算術運算子
+改成-。 - 將比較運算子
>改成>=。 - 將條件式
&&改成||。 - 將某個變數或常數替換成另一個值。
若測試案例執行原始程式與變異程式時，得到不同結果，代表測試案例偵測到該變異，稱為殺死變異體（kill a mutant）。若兩者結果相同，則稱為存活變異體（surviving mutant），表示現有測試案例未能辨識該項程式差異。
解題方法與運作原理
作答時可依序說明「產生變異、執行測試、比較結果、評估測試品質」：
- 建立原始程式及測試案例：先有待測程式與預期輸出。
- 產生變異程式：套用變異運算子，逐一製造小型程式修改。
- 以相同測試案例執行各版本：測試案例先執行原始程式，再執行變異程式。
- 比較輸出或狀態：結果不同，該測試案例殺死變異體；結果相同，變異體存活。
- 檢視存活變異體：補充測試案例，或判斷該變異體是否為等價變異體。
變異測試常用變異分數（mutation score）衡量測試套件的偵測能力：
第 四 題25 分
人工智慧（Artificial Intelligence）是當前最熱門新興技術之一，請討論將人工智慧引入需求分析（Requirements Analysis）的可能性及其影響。
登入後即可作答並保存紀錄。
核心觀念
本題考查人工智慧（Artificial Intelligence, AI）如何支援需求分析，以及導入後對需求品質、分析流程與利害關係人的影響。需求分析是從利害關係人的目標與問題出發，蒐集、整理、分析並驗證系統需求的工作；產出通常包括功能需求、非功能需求、需求模型及需求規格。
AI 可運用自然語言處理、機器學習、生成式 AI、知識圖譜與資料分析，協助分析需求資料。它能提升資訊整理與初步分析的效率，但需求的業務脈絡、優先順序與最終取捨仍須由利害關係人和需求分析人員確認。
解題方法
可依「需求分析活動 → AI 可提供的協助 → 預期效益與風險 → 治理方式」作答。這樣能同時說明導入的可能性與影響，避免只列舉 AI 工具，卻未回答其對需求分析工作的改變。
一、需求蒐集與整理
AI 可處理訪談逐字稿、問卷、客服紀錄、電子郵件、既有系統文件及法規文件，進行摘要、分類、關鍵詞擷取與主題歸納。自然語言處理也能協助辨識不同利害關係人對同一概念的不同用語，彙整常見需求與痛點。
**影響：**減少大量文字資料的初步整理時間，讓分析人員較快掌握需求主題；但摘要或分類可能遺漏例外情境、語氣及隱含需求，不能直接取代原始資料查證。
二、需求分析與需求品質檢查
AI 可協助檢查需求是否含糊、重複、互相矛盾、不可驗證或缺乏必要條件，並提示缺少的例外流程、資料欄位、權限條件或非功能需求。例如，對「系統應快速回應」這類描述，AI 可提示補上可量測的回應時間與適用情境。
AI 也可依既有文件或範本，協助草擬使用案例、使用者故事、驗收條件、流程圖文字說明及需求追溯資料。
**影響：**有助於提早發現缺漏與不一致，提升需求規格的完整性、明確性及可測試性；但 AI 提出的檢查結果屬於輔助提示，仍須依實際業務規則與利害關係人確認。
三、需求優先排序與影響分析
AI 可分析需求與業務目標、成本估計、風險、法令限制、使用者回饋及歷史專案資料之間的關係，提供優先排序或變更影響的建議。