114 司法特考三等 檢察事務官類科電子資訊組 系統分析 考古題詳解

核心觀念

本題考查需求工程中兩類需求的區別，以及如何將安全需求轉化為系統設計與風險控管措施。

• 功能性需求（Functional Requirements）：描述系統「必須提供什麼服務、執行什麼功能」，通常可用使用者操作、系統處理流程與預期結果來表達。
• 非功能性需求（Non-Functional Requirements）：描述系統「必須具備何種品質或限制」，例如安全性、效能、可用性、相容性及法規遵循等。非功能性需求常以可衡量的標準或驗收條件表示。

兩者都會影響安全設計：功能性需求決定系統要提供哪些安全控制；非功能性需求則規定安全控制應達到的品質、強度與運作限制。

解題方法

先辨別需求描述的重點：若描述的是系統要執行的安全操作，歸為功能性需求；若描述的是安全控制應達到的程度、品質或限制，歸為非功能性需求。再將兩類需求連結到設計階段的安全架構與風險控管策略。

功能性需求：行動銀行系統安全需求例

1. 使用者身分驗證：系統須在登入時驗證使用者身分，並支援密碼、生物辨識或多因素驗證。
2. 交易授權：系統須在轉帳或新增約定帳戶等高風險交易前，要求適當的再次驗證或交易確認。
3. 存取控制：系統須依使用者身分、帳戶權限及交易類型，限制可查詢或執行的操作。
4. 安全事件通知與紀錄：系統須記錄登入、轉帳及個人資料異動等重要事件，並在異常登入或可疑交易發生時通知使用者或銀行。

非功能性需求：行動銀行系統安全需求例

1. 傳輸與儲存保護：敏感資料傳輸時須加密；儲存時須採適當加密與金鑰管理機制。
2. 安全控制強度：身分驗證與交易授權須達到銀行訂定的安全標準，且高風險操作須採更高強度的控制。
3. 可用性與復原能力：安全機制不得使正常銀行服務長時間中斷；發生資安事件或故障時，系統須能在規定時間內復原。

核心觀念

測試驅動開發（Test-Driven Development, TDD）是一種以測試引導程式實作的開發方法。開發者先針對預期行為撰寫測試，再撰寫足以通過測試的最少程式碼，接著整理程式結構並確認測試仍通過。

TDD 的典型循環稱為 紅、綠、重構（Red–Green–Refactor）：

1. 紅（Red）：先寫一個描述需求的測試，執行後確認測試失敗。
2. 綠（Green）：撰寫最少的程式碼，使測試通過。
3. 重構（Refactor）：在不改變外部行為的前提下改善程式結構，並重新執行測試。

傳統的 先寫功能再寫測試（Code-First）則是先依需求完成程式功能，再補上測試。兩種方式都可以使用自動化測試；主要差異在於測試於開發流程中的先後順序，以及測試是否直接引導設計與實作。

解題方法

本題要求定義 TDD，並比較 TDD 與 Code-First 在測試覆蓋率、品質保證、維護度等方面的差異，同時分析兩者優缺點。作答時可依序處理：

1. 說明 TDD 的定義及「紅、綠、重構」循環。
2. 以測試覆蓋率、品質保證、維護度為比較面向，逐項說明差異。
3. 補充兩種方式各自的優點與缺點，並指出適用情境。

須特別注意：**TDD 不等於測試數量必然較多，也不保證程式沒有錯誤。**它的重點是先明確定義可驗證的預期行為，讓測試持續回饋開發結果。

TDD 與 Code-First 比較

核心觀念

行為驅動開發（Behavior Driven Development, BDD）是一種以「系統對外呈現的行為」為中心的敏捷開發方法。它透過業務人員、開發人員與測試人員共同描述需求，將需求寫成具體、可理解且可驗證的情境，再以自動化測試確認系統是否符合這些情境。

BDD 的重點不只是撰寫測試，而是讓需求、設計、開發與驗收使用一致的語言。需求以使用者可觀察的結果表達，避免過早陷入內部程式設計細節。常見情境格式為 Given–When–Then：

• Given（假設）：描述情境的前置條件。
• When（當）：描述使用者執行的動作或事件。
• Then（則）：描述系統應產生的可觀察結果。

例如，線上申請系統可寫成：

假設申請人已登入且已填妥必要資料，當申請人送出申請時，則系統應建立案件並顯示案件編號。

這段描述同時可供業務人員確認需求，也可轉化為自動化驗收測試。

解題方法與實施流程

本題可從「BDD 如何把需求轉成可驗證行為」切入，再依序說明協作、情境撰寫、實作與驗證，最後與瀑布式開發比較。答題時要涵蓋流程及其目的，避免只列出 Given–When–Then 格式。

典型實施流程如下：

1. 探索需求與共同討論 業務人員、開發人員及測試人員共同釐清使用者目標、業務規則、例外狀況與驗收條件，建立共享的領域語言。

2. 描述行為情境 將需求寫成可理解、可觀察的情境，常使用 Given–When–Then 格式。情境應聚焦於系統行為及結果，而非程式內部如何實作。

3. 將情境轉成可執行規格 使用 BDD 工具或測試框架，將情境文字連結至自動化測試程式。若系統尚未具備所需行為，測試會顯示未通過。

4. 實作最小必要功能 開發人員依情境實作功能，使相關測試通過；過程中可先處理最重要或最有價值的行為。

5. 重構並持續驗證 在維持測試通過的前提下改善設計，並反覆執行情境測試及其他回歸測試，確認新功能與既有功能均符合需求。

6. 依回饋調整需求與情境 當業務規則或需求理解改變時，團隊更新情境及測試，再據以調整實作，使規格與系統行為保持一致。

與瀑布式開發的主要差異

核心觀念

本題考查微服務架構的定義，以及採用此架構後，系統分析與設計工作如何改變。微服務是一種將應用程式拆分為多個小型、可獨立部署服務的架構風格。各服務通常圍繞特定業務能力設計，並透過明確介面（常見為 HTTP API 或訊息）互相溝通；每個服務可獨立開發、部署及擴充。

微服務不是單純把單體系統切成許多程式或伺服器。切分依據應以業務邊界與服務責任為核心，並明確界定服務間的資料歸屬、介面契約及依賴關係。

解題方法

作答時先下定義，再依系統分析與設計階段的工作，分別說明微服務帶來的效益與風險。效益可從需求分工、模組邊界、技術選擇及部署擴充切入；風險則可從服務切分、分散式通訊、資料一致性、測試維運及安全治理切入。以「架構特性如何影響分析與設計工作」作為主軸，能避免只羅列微服務的一般優缺點。

系統分析與設計階段的效益

1. 依業務能力劃分系統責任 分析業務流程與領域概念後，可將系統劃分為訂單、會員、付款等服務，讓服務邊界貼近業務責任。需求較容易分派給不同團隊，也能降低各功能彼此牽連的程度。

2. 提高模組化與變更局部性 各服務透過明確介面交換資料，分析與設計階段可先定義服務契約、輸入輸出及錯誤處理方式。單一服務的需求變更較容易限制在其責任範圍內，降低全系統連動修改的風險。

3. 支援獨立開發與部署 服務邊界與介面契約明確後，各團隊可平行開發、測試與發布不同服務，減少大型單體系統必須協調整體版本的情形，提升交付彈性。

4. 依服務需求選用技術與擴充資源 不同服務可依其需求選擇適合的程式語言、資料儲存方式與部署資源。高負載服務也可獨立擴充，不必同步增加整個系統的資源。

5. 改善故障隔離與可演進性 若服務間設計有適當的逾時、重試及降級機制，個別服務故障較能限制影響範圍。服務亦可逐步替換或改版，支援系統分階段演進。

風險與挑戰

1. 服務邊界難以正確劃分 切分過粗，會失去微服務獨立演進的優點；切分過細，則增加服務數量、通訊及管理成本。若業務邊界分析不當，常見結果是服務間高度依賴，形成「分散式單體」。