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

核心觀念

本題考查需求蒐集階段的訪談分類，重點在於區分兩個不同面向：

1. 訪談結構程度：問題是否事先標準化，分為非結構化與結構化訪談。
2. 訪談進行方向：訪談由高層目標逐步深入，或由基層工作逐步歸納，分為自上而下與自下而上訪談。

因此，這四種訪談並非完全互斥。例如，訪談者可以採用「自上而下的結構化訪談」，也可以採用「自下而上的非結構化訪談」。前兩者回答「問題如何設計」，後兩者回答「訪談從哪一層開始」。

---

一、非結構化訪談（Unstructured Interview）

1. 定義

非結構化訪談沒有固定且完整的問題清單，訪談者通常只設定訪談主題、目的或幾個核心問題，再依受訪者的回答自由追問。

其特徵包括：

• 問題順序具有彈性。
• 問題內容可隨訪談發展調整。
• 鼓勵受訪者自由描述經驗、問題與需求。
• 訪談者可依回答追問細節、原因與例外情況。
• 不同受訪者接受的問題內容可能不完全相同。

例如，訪談者詢問承辦人：

「請說明您目前處理案件時，最困難的地方。」

受訪者提到資料重複輸入後，訪談者再追問：

「哪些資料需要重複輸入？」 「重複輸入發生在流程的哪個階段？」 「發生錯誤時如何處理？」

2. 優點

• 能探索尚未被發現的需求。
• 能取得受訪者的實際經驗、感受與抱怨。
• 適合發掘正式文件未記載的例外流程與非正式規則。
• 訪談氣氛較自然，受訪者較容易表達真正想法。
• 適合需求尚不明確、問題範圍尚未界定的專案。

3. 缺點

• 不同受訪者回答內容差異較大，不易直接比較。
• 訪談結果高度依賴訪談者的經驗與追問能力。
• 容易偏離主題，造成時間與成本增加。
• 資料整理、分類與驗證較困難。
• 訪談者的引導方式可能造成偏誤。

4. 使用時機

非結構化訪談適合使用於：

• 專案初期，需求範圍尚未清楚時。
• 探索新領域、陌生業務或缺乏既有文件的系統。
• 需要了解使用者痛點、工作習慣與實際經驗時。
• 需要發現隱性需求、例外情況與非正式作業規則時。
• 先進行廣泛探索，再據此建立後續結構化訪談問卷時。

---

二、結構化訪談（Structured Interview）

1. 定義

結構化訪談是由訪談者事先設計標準化的問題、順序及回答格式，再依相同或近似方式訪問不同受訪者。

其特徵包括：

• 事先準備完整訪談大綱。
• 不同受訪者接受相同或高度相似的問題。
• 問題順序通常固定。
• 可採用選擇題、評分量表、是非題或固定填答格式。
• 訪談結果容易進行比較、統計與彙整。

例如，針對案件管理系統訪問多位承辦人，固定詢問：

1. 每日平均處理幾件案件？
2. 案件登錄平均需要幾分鐘？
3. 是否曾發生資料重複輸入？
4. 對目前系統滿意度為何，請以 $1$ 至 $5$ 分評分？

2. 優點

• 不同受訪者的意見具有可比性。
• 訪談內容較容易控制，不易偏離主題。
• 訪談時間與成本較容易估算。
• 資料便於統計分析、分類及產出需求摘要。
• 可降低訪談者個人偏好的影響。
• 適合驗證已提出的需求或比較不同部門的需求差異。

3. 缺點

• 彈性較低，難以深入追問意外發現。
• 問題設計不完整時，容易漏掉重要需求。
• 受訪者可能只回答選項，無法充分表達真正想法。
• 問題措辭或選項設計不當，可能造成誘導性偏誤。
• 過度強調標準化時，容易忽略不同部門的特殊情況。

4. 使用時機

結構化訪談適合使用於：

• 已經掌握業務範圍，需要有系統地蒐集資料時。
• 需要比較多位使用者、部門或職務的需求時。
• 需要確認需求是否普遍存在時。
• 需要驗證初步需求、原型或候選功能時。
• 專案中後期，需要將需求量化、排序或形成正式紀錄時。
• 受訪者人數較多，必須維持訪談一致性時。

---

三、自上而下訪談（Top-Down Interview）

1. 定義

自上而下訪談是從組織的高層目標、策略與整體業務流程開始，再逐層向下訪問至部門、角色、工作活動與操作細節。

其邏輯可表示為：

$$\text{組織目標} \rightarrow \text{部門目標} \rightarrow \text{業務流程} \rightarrow \text{使用者角色} \rightarrow \text{工作任務} \rightarrow \text{資料與功能需求}$$

訪談順序通常是：

1. 高階主管或業務負責人。
2. 部門主管及流程管理者。
3. 業務承辦人與實際使用者。
4. 系統管理者、資料管理者及其他相關人員。

2. 主要目的

自上而下訪談著重於確認：

• 系統為何要建置。
• 組織希望達成哪些目標。
• 哪些業務流程屬於系統範圍。
• 各部門的責任與權限如何分配。
• 系統功能如何支援組織策略。
• 需求之間的優先順序與整體關聯。

例如，先向主管確認：

「本系統是否以縮短案件處理時間為主要目標？」

再向流程負責人詢問：

「哪些流程最影響處理時間？」

最後向承辦人追問：

「實際作業中哪些步驟最耗時？」

3. 優點

• 能先建立整體系統範圍與方向。
• 可確保需求與組織目標一致。
• 有助於辨識跨部門流程與權責關係。
• 能避免一開始只處理局部作業，導致系統缺乏整體性。
• 適合進行企業流程、組織流程及策略層級的分析。

4. 缺點

• 高層未必熟悉實際操作細節。
• 高層陳述的目標可能過於抽象。
• 若只訪問主管，容易遺漏基層使用者的痛點與例外流程。
• 需求由上而下傳遞時，可能發生資訊失真。
• 可能過度重視正式流程，忽略實際工作中的非正式作法。

5. 使用時機

自上而下訪談適合使用於：

• 新系統尚未界定範圍時。
• 需要確認組織目標、策略及管理需求時。
• 進行跨部門整合或企業流程再造時。
• 系統影響多個部門，需要先釐清權責與整體流程時。
• 高層對系統的方向、績效指標及管理報表有明確要求時。

---

核心觀念

本題考查 UML（Unified Modeling Language）活動圖（Activity Diagram）如何描述企業流程，以及活動圖中各類節點與流程的語意。

活動圖主要用來表示：

• 企業流程中各項活動的執行順序。
• 活動的執行者與責任分工。
• 條件判斷與不同流程路徑。
• 平行活動的分支與同步。
• 活動之間傳遞的資料、文件、物品或訊息。
• 流程的開始、結束與例外終止。

活動圖的基本構成可表示為：

$$\text{活動圖}=\text{活動節點}+\text{控制節點}+\text{物件節點}+\text{流程線}$$

其中，活動（activity）代表企業流程或一組具有明確目的的工作；動作（action）則是活動中不可再細分或較細部的工作步驟。

---

解題方法：以企業採購流程為例

可用「企業採購流程」說明活動圖塑造企業流程的方法。

一、確認流程範圍與啟動事件

先界定流程的起點與終點，例如：

• 起點：員工提出採購申請。
• 終點：採購完成並通知申請人，或申請遭到拒絕。

如此可避免活動圖只描述局部工作，卻無法呈現完整企業流程。

二、建立活動與責任分工

依照企業實際參與者建立泳道（swimlane），例如：

1. 申請員工
2. 部門主管
3. 採購部門
4. 財務部門
5. 供應商

泳道表示活動的責任歸屬，可清楚呈現「誰負責執行哪一項工作」。

三、安排主要活動順序

採購流程可設計如下：

1. 員工填寫採購申請。
2. 系統檢查申請資料是否完整。
3. 部門主管審核申請。
4. 若主管不核准，系統記錄拒絕原因並通知員工。
5. 若主管核准，採購部門詢價。
6. 選定供應商並建立採購單。
7. 財務部門確認預算。
8. 若預算不足，退回採購申請並通知相關人員。
9. 若預算足夠，送出採購單給供應商。
10. 供應商交貨。
11. 採購部門驗收。
12. 財務部門付款。
13. 系統通知申請人採購完成。

四、加入判斷與分支

「主管是否核准」與「預算是否足夠」屬於條件判斷，應使用決策節點（decision node）。

例如：

$$\text{主管審核} \rightarrow \begin{cases} \text{核准} & \text{進入詢價流程}\\ \text{不核准} & \text{通知申請人並結束} \end{cases}$$

決策節點的每一條輸出流程應標示條件，例如 [核准]、[不核准]。

若多條替代路徑最後重新匯合，應使用合併節點（merge node），例如「核准後詢價」與「採購單修改後重新送審」重新回到同一流程點。

五、加入平行流程

採購單送出後，企業可能同時進行：

• 通知申請人採購進度。
• 建立應付帳款紀錄。
• 追蹤供應商交貨日期。

此時可使用分叉節點（fork node）將一條流程拆成多條平行流程；待各平行工作完成後，再使用聯結節點（join node）同步整合。

示意如下：

$$\text{採購單送出} \rightarrow \text{分叉} \rightarrow \begin{cases} \text{通知申請人}\\ \text{建立付款紀錄}\\ \text{追蹤交貨} \end{cases} \rightarrow \text{聯結} \rightarrow \text{完成採購}$$

六、表示資料與文件傳遞

企業流程不只包含工作順序，也包含文件與資料的流動。例如：

• 採購申請單由員工產生。
• 核准後的採購申請單提供給採購部門。
• 採購單傳送給供應商。
• 驗收紀錄提供給財務部門付款。

這些資料應以物件節點表示，並以物件流程連接到使用該資料的活動。

---

活動圖的主要符號

一、動作節點（Action Node）

動作節點表示具體工作，例如：

• 填寫採購申請
• 審核採購申請
• 建立採購單
• 驗收貨品
• 執行付款

通常以圓角矩形表示。

二、控制節點（Control Node）

控制節點不代表企業資料，而是負責控制流程的開始、結束、分支、匯合與平行同步。

三、物件節點（Object Node）

物件節點表示流程中被產生、使用、修改或傳遞的資料、文件、貨品與訊息。

四、流程線（Edge）

流程線連接節點，表示控制或物件的傳遞方向。箭頭方向代表流程前進方向。

---

控制節點的類型

一、初始節點（Initial Node）

表示活動或流程的起點，通常以實心黑圓表示。

例如：

• 員工提出採購需求。
• 客戶送出訂單。
• 系統接收到服務請求。

一個活動圖可有一個以上的初始節點，但在一般企業流程中通常以一個主要起點表達。

二、活動終止節點（Activity Final Node）

表示整個活動或整個活動圖結束，通常以「實心黑圓外加圓圈」表示。

當某一條流程到達活動終止節點時，整個活動的所有其他流程通常也會一併停止。

例如：

• 採購完成。
• 申請被拒絕且流程正式結束。

三、流程終止節點（Flow Final Node）

表示某一條控制流程結束，通常以圓圈內含叉號表示。

流程終止節點只終止到達該節點的那一條流程，不會使整個活動圖的其他平行流程停止。

例如：

• 某一筆申請因資料錯誤而結束。
• 某一條例外處理路徑結束，但其他流程仍持續執行。

四、決策節點（Decision Node）

表示依據條件選擇不同流程路徑，通常以菱形表示。

例如：

• 主管是否核准？
• 預算是否足夠？
• 申請資料是否完整？

決策節點通常具有一條輸入流程及多條輸出流程，各輸出流程應附加守衛條件（guard condition），例如：

• [核准]
• [不核准]
• [資料完整]
• [資料不完整]

五、合併節點（Merge Node）

表示多條替代流程重新匯合，通常也以菱形表示。

合併節點與決策節點的差異在於：

• 決策節點：一條輸入、多條可能輸出。
• 合併節點：多條可能輸入、一條輸出。

例如，主管核准流程與重新補件流程最後都進入「建立採購單」，此處可使用合併節點。

合併節點只表示替代路徑的匯合，不表示等待所有輸入流程完成。

六、分叉節點（Fork Node）

表示將一條控制流程分成兩條以上可同時執行的平行流程，通常以粗黑線表示。

例如，採購單送出後同時：

• 通知申請人。
• 建立付款紀錄。
• 追蹤交貨狀態。

分叉節點代表平行化，不代表條件選擇。

七、聯結節點（Join Node）

表示等待多條平行流程完成後，才繼續往下執行，通常也以粗黑線表示。

核心觀念

本題考查物件導向設計中的「共生性」（connascence）。共生性用來描述：兩個以上的軟體元件，必須共享某項資訊、遵守某項規則，才能正確協同運作。

共生性可視為對下列設計概念的廣義化：

• 內聚力（cohesion）：同一模組內各責任彼此相關的程度。
• 耦合力（coupling）：不同模組之間相互依賴的程度。
• 封裝（encapsulation）：隱藏內部實作細節，只暴露必要介面。

良好的物件導向設計，通常追求：

1. 降低不必要的共生性。
2. 將共生性集中在少數元件內。
3. 讓共生性依賴透過清楚、穩定的介面表達。
4. 優先採用較弱、較容易維護的共生性形式。

本題指定的五種共生性如下：

類型	英文	主要依賴內容
名稱共生性	Name	必須使用相同名稱
型態或類別共生性	Type or Class	必須使用相容的資料型態或類別
習慣用法共生性	Convention	必須遵守共同約定
演算法共生性	Algorithm	必須採用相同或相容的演算法
位置共生性	Position	必須依賴資料或參數的相對位置

---

解題方法

作答時可依「定義＋依賴內容＋物件導向例子」逐項說明。每一種共生性都應回答三件事：

1. 哪些元件彼此依賴？
2. 依賴的是名稱、型態、約定、演算法或位置？
3. 這項依賴如何影響系統維護？

本題不是要求比較五種共生性的強弱，因此重點在於清楚區分其依賴來源，並各自提出具體例子。

---

一、名稱共生性（Connascence of Name, CoN）

定義

名稱共生性是指兩個元件必須使用相同的名稱，才能正確取得、呼叫或操作同一個概念。

名稱可能包括：

• 方法名稱
• 屬性名稱
• 變數名稱
• 介面名稱
• 訊息或事件名稱
• 資料欄位名稱

若其中一方更改名稱，另一方未同步修改，系統就可能無法正常運作。

例子

class UserService {
 public User findUserById(int id) {
 // ...
 return null;
 }
}

class UserController {
 private UserService userService;

 public void execute(int id) {
 User user = userService.findUserById(id);
 }
}

UserController 必須知道 UserService 中的方法名稱是 findUserById，兩個類別因而產生名稱共生性。

若服務類別將方法改名為：

findById(int id)

但控制器仍呼叫 findUserById，就會造成編譯錯誤或介面呼叫失敗。

設計意義

名稱共生性通常透過公開介面呈現。若名稱被集中定義於介面、列舉型態或常數中，能減少名稱分散造成的不一致。

---

二、型態或類別共生性（Connascence of Type/Class, CoT）

定義

型態或類別共生性是指兩個元件必須對資料的型態、類別或物件介面具有共同認知，才能正確傳遞與處理資料。

這種共生性可能涉及：

• 基本資料型態，例如 int、String
• 自訂類別
• 介面
• 繼承關係
• 泛型型態
• 例外類別

若一方傳送的型態與另一方預期的型態不相容，就會產生編譯錯誤、轉型錯誤或執行結果錯誤。

例子

class OrderService {
 public void createOrder(Customer customer) {
 // ...
 }
}

class OrderController {
 private OrderService orderService;

 public void execute(Customer customer) {
 orderService.createOrder(customer);
 }
}

OrderService.createOrder 要求接收 Customer 類別，呼叫端也必須建立並傳入 Customer 物件，因此兩者具有型態或類別共生性。

若方法改為：

public void createOrder(CustomerDTO customer)

呼叫端仍傳入 Customer，就必須進行轉換，否則無法直接呼叫。

設計意義

使用介面與抽象類別，可降低元件對具體類別的依賴。例如：

public void createOrder(CustomerRepository repository) {
 // ...
}

相較於直接依賴某個具體資料庫類別，依賴介面能提高替換性與測試性。

---

三、習慣用法共生性（Connascence of Convention, CoC）

定義

習慣用法共生性是指多個元件必須共同遵守某項約定，才能正確解讀或處理資料。這項約定不一定由程式語言的型態系統直接強制，而可能存在於規格、文件或團隊開發慣例中。

常見內容包括：

• 日期格式
• 字串編碼
• 回傳值代表的意義
• 狀態碼定義
• 欄位命名規則
• true、false 的語意
• 空值的表示方式
• API 回應格式

例子

假設系統約定 API 回傳的 status 欄位：

核心觀念

本題考查資訊系統的安全性需求（security requirements）。安全性需求是系統為防止未經授權的存取、資料遭竄改、服務中斷、身分冒用及事後否認等風險，所必須具備的功能與品質要求。

答題可採資訊安全的核心目標切入，說明下列五項：

1. 機密性（Confidentiality）
2. 完整性（Integrity）
3. 可用性（Availability）
4. 身分鑑別與真實性（Authentication and Authenticity）
5. 不可否認性與責任追蹤（Non-repudiation and Accountability）

這五項需求同時涵蓋人為故意攻擊，以及硬體故障、天然災害、操作錯誤等隨機事件。

解題方法

每一項安全性需求均以「定義、威脅、控制措施、實際例子」說明。答題時先列出五項名稱，再逐項說明，可使答案完整且容易取得分數。

一、機密性

定義

機密性是指資訊只能由經過授權的使用者、程式或系統存取，防止資料遭未授權揭露。

防護對象

• 駭客竊取資料
• 內部人員越權查詢
• 網路傳輸遭竊聽
• 備份媒體遺失導致資料外洩

實作方式

• 使用帳號、密碼及多因素驗證
• 依角色設定存取權限
• 傳輸資料採用 TLS 加密
• 資料庫及備份檔進行加密
• 遵守最小權限原則

例子

公務人員資料系統中的身分證號、住址及案件資料，只能由具有承辦權限的使用者查閱；即使攻擊者攔截網路封包，因資料已加密，也無法直接讀取內容。

二、完整性

定義

完整性是指資料與程式只能被授權者依合法程序建立、修改或刪除，並且資料在儲存與傳輸過程中保持正確、完整且未遭竄改。

防護對象

• 駭客修改資料
• 傳輸過程中的資料遭篡改
• 操作錯誤造成欄位內容錯誤
• 程式錯誤導致交易資料不一致

實作方式

• 設定資料表主鍵、外鍵及欄位限制
• 使用交易控制與一致性檢查
• 使用雜湊值、數位簽章或訊息驗證碼確認資料未遭修改
• 建立版本控管及異動紀錄
• 實施雙人覆核與職務分離

例子

薪資系統不得讓一般承辦人直接修改薪資金額。薪資異動必須由承辦人提出、主管覆核，系統並記錄異動前後內容、操作者及時間，以避免資料被任意竄改。

三、可用性

定義

可用性是指經授權的使用者在需要時，能在合理時間內使用系統及取得所需資訊。

可用性不只是「系統能開啟」，還包括服務持續性、故障復原能力及合理的回應時間。

防護對象

• 硬體故障
• 網路中斷
• 勒索軟體或阻斷服務攻擊
• 電力中斷
• 火災、地震、水災等天然災害
• 程式錯誤造成系統停止服務

實作方式

• 建置備份與還原機制
• 使用 RAID、叢集或備援伺服器
• 建立異地備援與災害復原中心
• 設計故障轉移（failover）機制
• 使用防火牆及阻斷服務攻擊防護
• 設定復原時間目標（RTO）與復原點目標（RPO）
• 定期進行備份還原及災害演練

例子

戶政服務系統的主機故障時，備援主機可自動接手服務；若發生重大災害，則由異地備份資料復原系統，使民眾仍能在可接受的時間內辦理業務。

四、身分鑑別與真實性

定義

身分鑑別是確認使用者、設備或服務的身分確實與其宣稱的身分相符；真實性則是確認訊息來源確實為可信的對象，避免冒名登入或偽造訊息。

身分鑑別與授權必須區分：

• 身分鑑別回答「你是誰？」
• 授權回答「你可以做什麼？」

防護對象