108 關務升官等考試薦任 技術類（選試系統分析） 系統分析 考古題詳解

核心觀念

本題是名詞解釋題，重點在於說明五個軟體工程概念的定義、用途及彼此關係。作答時可先寫核心定義，再補充主要內容或使用情境，並以容易混淆的概念作區別。

解題方法

依照「定義 → 功能或構成 → 易混淆處」逐項說明。題目不是選擇題，沒有選項需要分析；也沒有涉及特定法條或計算公式。

(一) 軟體系統分析（Software Systems Analysis）

軟體系統分析是針對組織或使用者所面臨的問題與需求，進行調查、理解、整理與建模的工作，目的在於明確界定系統要解決什麼問題、應提供哪些功能，以及須符合哪些限制。

分析工作通常包括：

• 蒐集並確認利害關係人的需求。
• 分析現行作業流程、資料及系統環境。
• 界定系統範圍、介面與限制條件。
• 建立需求模型，例如使用案例、流程圖、資料模型或需求規格。

系統分析的成果可作為後續設計、建置與測試的依據。分析著重於「做什麼、為何要做」；系統設計則進一步決定「如何實作」，例如採用何種架構、資料庫與介面。

(二) 活動圖（Activity Diagram）

活動圖是 UML（Unified Modeling Language）中的行為圖，用來描述一項作業、程序或使用案例中，活動與控制流程的先後關係。它適合呈現從起點到終點的工作流程，也可表示條件分支及平行處理。

常見元素包括：

• 初始節點：表示流程開始。
• 活動或動作節點：表示執行中的工作。
• 控制流程：表示活動執行的先後順序。
• 決策與合併節點：依條件選擇流程，或將不同分支匯合。
• 分叉與匯合節點：表示流程平行執行或等待平行工作完成。
• 活動分割區（泳道）：標示不同角色、部門或系統負責的活動。
• 活動終止節點：表示整個活動流程結束。

活動圖著重呈現「流程如何進行」；若要呈現物件間傳送訊息的互動順序，通常使用循序圖。

(三) 系統開發生命週期（System Development Life Cycle, SDLC）

系統開發生命週期是規劃、開發、導入及維護資訊系統的一套階段性流程，用來管理系統從構想到退役的工作。常見階段包括：

1. 規劃與可行性分析：確認問題、目標、範圍及技術、經濟、作業等可行性。
2. 需求分析：蒐集並確認功能需求、非功能需求與限制。
3. 系統設計：規劃架構、資料、介面、元件及安全控制。
4. 建置與測試：撰寫程式，並進行單元、整合、系統及驗收測試。

核心觀念

本題考查 CMMI 分階段式（staged）表示法的五個成熟度等級，以及需求管理（REQM）、專案規劃（PP）兩個流程領域的目的，並要求說明「特定目標」（Specific Goals）的意義。

CMMI 將組織的流程改善分成不同成熟度階段。分階段式評量依各成熟度等級所包含的一組流程領域，評估組織整體流程成熟度；等級由 1 至 5 逐步提升。流程領域的「目的」說明該流程領域要達成什麼；特定目標則描述該流程領域必須達成的具體成果。

解題方法

依序辨認題目要求的三種內容：五個成熟度等級、兩個流程領域的目的，以及特定目標的定義。作答時，成熟度等級要按順序列出並說明差異；流程領域的目的則以 CMMI 的標準意旨作答，避免只把英文名稱翻成中文。

（一）CMMI 分階段式成熟度評量的五個等級

1. 初始級（Initial，成熟度第 1 級）：流程通常臨時應變、缺乏穩定控制，成果往往仰賴個人能力與投入。
2. 已管理級（Managed，第 2 級）：專案流程依計畫執行並受到管理，能管理需求、工作成果、資源、時程及相關承諾。
3. 已定義級（Defined，第 3 級）：組織建立並維護標準流程，專案依組織標準流程裁適後執行，流程定義與運用較一致。
4. 量化管理級（Quantitatively Managed，第 4 級）：運用量化資料與統計方法管理流程績效及產品品質，使流程的表現可預測、可控制。
5. 最佳化級（Optimizing，第 5 級）：持續分析流程績效與缺失成因，推動流程改善與創新，以提升流程能力及組織績效。

（二）需求管理（Requirements Management, REQM）的目的

REQM 的目的，是管理專案產品及產品組件的需求，並確認需求與專案計畫、工作成果之間的一致性。

核心觀念

本題考查 UI 設計從概念到可操作介面的三個階段，以及易用性測試的評估重點。三者通常由低擬真度逐步發展到高擬真度：先確認資訊與版面配置，再呈現視覺風格，最後驗證互動流程與使用者操作經驗。

解題方法

第一、二小題可依「呈現內容、主要目的、製作方式」比較 Wireframe、Mockup、Prototype。第三小題則從易學性、效率、錯誤、記憶性與滿意度等面向，說明如何觀察使用者能否順利完成任務。

（一）中文翻譯

• Wireframe：線框圖，也稱線框稿。
• Mockup：模型圖，也稱視覺稿或介面模型。
• Prototype：原型，也稱互動原型。

各中文譯名在業界並不完全一致，作答時宜保留英文名詞，並搭配常見中文譯名。

（二）目的與作法的差異

三者的重點可概括如下：**Wireframe 看結構，Mockup 看外觀，Prototype 看操作與流程。**它們是常見的設計階段與產出形式，實務上會依專案需求反覆修訂，不必然只能按單一路徑線性完成。

（三）UI 易用性（Usability）測試重點

核心觀念

使用案例塑模（Use Case Modeling）是從外部觀點描述系統需求的方法。它以「參與者（Actor）要透過系統完成什麼目標」為核心，呈現系統提供的功能，以及參與者與功能之間的互動。

• Actor：與系統互動的角色，可以是人、組織或外部系統。
• Use case：系統為參與者完成一項有意義目標所提供的功能。
• 系統邊界：界定哪些功能屬於受分析的系統；Actor 在邊界之外，Use case 在邊界之內。
• 使用案例圖（UCD）：呈現參與者、使用案例及其關係，提供需求範圍的概觀。
• 使用案例描述（Use Case Narrative）：以文字記錄單一使用案例的執行流程與條件。

本題分別考查使用案例的目的、UCD 的繪製與說明、使用案例描述的意義，以及 include 關係。

（一）使用案例的目的

使用案例的目的，是以參與者的目標為中心，描述系統「應提供什麼服務」，並呈現參與者如何與系統互動。它主要用於：

1. 蒐集與整理功能需求：將需求整理成一項項可辨識的系統服務。
2. 界定系統範圍：藉由系統邊界區分系統內部功能與外部角色。
3. 促進利害關係人溝通：以容易理解的方式呈現使用者目標，讓使用者、分析人員與開發人員確認需求。
4. 作為後續工作的依據：支援需求確認、系統設計、測試案例規劃及使用者驗收。

使用案例聚焦於參與者可觀察到的系統行為與完成的目標，不以描述程式內部如何實作為主要目的。

（二）購物網站 UCD 與說明

解題方法

先界定系統邊界為「購物網站」，再找出與網站互動的外部角色，最後列出各角色要透過網站完成的目標，形成使用案例。至少應呈現三個使用案例，並以連線表示 Actor 與其參與的使用案例。

UCD

 ┌────────────── 購物網站 ──────────────┐
顧客（Actor） ────┼── (瀏覽商品) │
 │ ├── (加入購物車) │
 ├────────┼── (下訂單) ──────── <<include>> ──> (計算訂單金額)
 │ ├── (付款) │
 │ └── (查詢訂單) │
 │ │
金流服務（Actor） ─────────────────────── (付款) │
 └──────────────────────────────────────┘

圖示說明