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

核心觀念

看板方法（Kanban Method）是一種以可視化工作流程、限制進行中工作（WIP），並持續改善交付流程為核心的敏捷管理方法。它通常在團隊既有的工作流程上逐步導入，不要求先改組織架構或採用固定週期。

看板上的卡片代表工作項目，欄位代表工作流程階段，例如「待辦、分析、開發、測試、完成」。團隊依照明確的流程政策拉取工作，並透過觀察工作流量與阻塞情形，找出瓶頸、調整流程。

看板方法常見的核心原則包括：

• 從現況開始：先呈現既有流程，再逐步改善。
• 漸進式改變：透過小幅、持續的調整推動改進。
• 尊重既有角色與責任：不以大規模組織重整作為導入前提。
• 鼓勵各層級共同改善：讓實際參與工作的人一起檢視流程。

實務上，團隊會將工作流程視覺化、設定各階段的 WIP 限制、管理工作項目的流動、明確化流程政策，並定期檢視與改善。這些做法使團隊能看見工作累積與阻塞位置，並著重於穩定、持續地交付價值。

解題方法

本題分成兩部分作答：先定義看板方法及其管理機制，再依其特性判斷適用與不適用的開發情境。判斷重點是：專案是否有持續進入的工作、需求可逐步排序，以及流程能否以拉式方式穩定交付。

適合的開發情境

看板適合下列情境：

• 需求持續進入、優先順序常調整：例如維運、錯誤修正、客服需求、系統小幅改善。團隊可依目前產能拉取最優先工作，不必等到下一個固定迭代才處理。
• 工作項目大小不一，但流程大致固定：可在看板上追蹤各工作項目的狀態，並觀察哪個階段形成瓶頸。
• 組織希望漸進導入敏捷：看板可從既有流程開始，逐步增加視覺化、WIP 限制和流程改善，不必先改變所有角色與制度。
• 需要改善交付流動與縮短等待時間：限制同時進行的工作數，可避免工作大量堆積，促使團隊先完成手上的工作再承接新工作。

不適用或需搭配其他方法的專案

核心觀念

需求驗證（Requirements Validation）是確認需求文件是否正確描述利害關係人的實際需要，並確認需求是否適合作為後續設計、建置與驗收的依據。它與需求確認（Requirements Verification）的重點略有不同：驗證著重「需求是否符合使用者真正需要」，確認則著重「需求文件本身是否完整、一致、可行且可檢驗」。實務上兩者常一起進行。

良好的需求通常應具備下列特性：

• 正確：符合使用者需求與組織目標。
• 完整：必要的功能、限制及例外情況均有描述。
• 一致：不同需求之間沒有矛盾。
• 可行：在技術、成本、時程及法令限制下可實現。
• 可測試：能以明確方法判斷是否達成。
• 可追溯：能連結到其來源、設計、測試或驗收項目。

解題方法

題目要求列舉並解釋至少三種需求驗證技術，並說明哪些需求不可測試。作答時可先指出需求驗證的目的，再以「文件審查、原型、測試案例」等具體技術說明如何找出需求問題；最後說明不可測試需求的判準與例子。

需求驗證技術

1. 需求審查（Requirements Review） 由使用者、分析師、開發人員、測試人員及其他相關人員共同檢視需求文件。可採正式檢查（Inspection）、走查（Walkthrough）或同儕審查等方式，確認需求是否正確、完整、一致、可行且易於理解。審查時可使用檢核表，逐項檢查模糊用語、缺漏情境、彼此矛盾及未說明的限制。

2. 原型驗證（Prototyping） 建立系統畫面、操作流程或低擬真模型，讓使用者實際檢視或操作，以確認需求分析者對使用情境及功能的理解是否正確。原型特別適合用來釐清使用者介面、操作流程及尚未明確表達的需求，也能及早發現使用者想要的功能與文件描述不一致之處。

3. 測試案例產生（Test-case Generation） 嘗試依每一項需求設計測試案例及預期結果。若需求無法導出清楚的測試步驟或判定標準，通常表示需求描述含糊、缺少量化條件，或本身不可測試。此方法也能檢查需求是否涵蓋正常流程、錯誤流程及邊界條件。

核心觀念

V 模型（V-model）是瀑布式開發的延伸，將開發階段與驗證、確認階段對應排列成 V 字形。左側由需求逐步細化為系統設計、架構設計與模組設計；底部進入程式實作；右側則由單元測試逐步整合至系統測試與驗收測試。

各階段的對應關係如下：

V 模型中的「驗證」（Verification）著重確認工作成果是否符合前一階段的規格，例如設計是否符合需求；「確認」（Validation）則著重確認完成的系統是否真正滿足使用者的使用目的。兩者都應納入開發流程。

V 模型與品質保證的關係

品質保證（Quality Assurance, QA）是以預防為主的管理與流程活動，目的在確保開發流程及工作方式能產生符合品質要求的成果。品質管制（Quality Control, QC）則偏重檢查產品本身，例如透過測試找出缺陷。

V 模型與 QA 的關係主要有三點：

1. 品質活動從需求階段開始：每個開發階段都要產生可檢視的工作成果，並設定審查、規格檢查及核准等品質活動，避免缺陷一路傳到後續階段。
2. 測試與規格建立同步規劃：左側定義需求及設計時，右側對應的測試也開始規劃。例如分析使用者需求時，就建立驗收測試的測試條件；設計模組時，就規劃單元測試。
3. 測試提供品質管制證據：右側各層測試用來確認產品是否符合對應規格，並揭露缺陷。測試結果可回饋 QA，促使流程或規格改善。

因此，V 模型提供 QA 可落實的階段架構與追溯方式；QA 則透過流程標準、審查、文件管制、測試規劃及缺陷管理，確保模型各階段確實執行。V 模型本身不等於 QA，也不能只靠測試保證品質。

解題方法

本題分成兩個部分作答：

核心觀念

本題考查人工智慧技術導入資訊系統開發後，對系統分析與系統設計造成的改變。重點不在列舉 AI 演算法，而在說明傳統資訊系統的需求、資料、處理流程、介面、架構與測試，如何因 AI 系統具有資料依賴、機率輸出與持續調整等特性而改變。

傳統系統多以明確規則處理輸入，對相同輸入通常產生可預期的結果；AI 系統則透過資料與模型推論，輸出可能具有不確定性，且品質受訓練資料、模型選擇與使用情境影響。因此，分析與設計階段必須同時考量資料與模型生命週期、結果品質及使用者監督。

解題方法

可依系統開發生命週期，從「需求分析、資料分析、系統設計、介面與流程、測試維運、風險治理」逐層說明。每一層都指出 AI 帶來的新工作或設計考量，並與傳統系統開發相互對照，即可完整回答「影響為何」。

對系統分析與設計的影響

一、需求分析：由固定功能需求擴及模型品質需求

傳統需求分析通常描述輸入、處理規則與輸出結果。導入 AI 後，除了功能需求，還需定義模型的準確率、召回率、誤判成本、回應時間、可解釋性及公平性等非功能需求。

需求分析也要釐清 AI 的適用範圍與限制，例如模型負責提供分類、預測或建議，哪些決策仍須由人員核准，以及模型無法判斷或信心不足時如何處理。需求應以實際使用情境及可衡量的驗收標準表達，避免只寫「系統應具備智慧判斷能力」。

二、資料分析：資料成為核心系統資源

AI 模型的效能高度依賴資料，系統分析須盤點資料來源、格式、數量、品質、更新頻率及使用權限，並確認資料是否具有代表性、標記是否正確，以及是否存在缺漏、偏差或重複。

設計時還須規劃資料蒐集、清理、標記、轉換、儲存與版本管理流程。若訓練資料與實際上線資料分布不同，模型效能可能下降，因此須分析資料如何持續更新，以及如何監測資料分布變化。

三、系統架構與模組設計：加入模型及資料管線

傳統系統常以商業規則、資料庫與應用程式模組為主要設計對象。AI 系統則須納入資料管線、模型訓練與驗證環境、模型部署服務，以及與既有系統介接的方式。