6.1 從需求分析進入系統建模

6.1.1 有了需求規格，為什麼還需要模型

需求分析的成果通常包括功能需求、非功能需求、業務規則、資料需求、介面需求、驗收準則，以及需求之間的追蹤關係。這些成果可以說明系統必須滿足哪些要求，也能作為確認系統範圍、安排開發工作與進行驗收的重要依據。

然而，即使每一項需求都已經寫得清楚，讀者仍可能難以從大量文字中迅速看出系統的整體結構。例如：

• 哪些外部角色或系統會與資訊系統互動？
• 各角色希望透過系統完成哪些目標？
• 哪些系統功能彼此相關？
• 工作會依照什麼順序進行？
• 哪些資料會被建立、使用或修改？
• 不同物件之間具有什麼關係？
• 在不同條件、替代或例外情況下，資訊系統應如何回應？
• 系統邊界內外的責任如何區分？

單一需求通常只描述系統的一項要求。例如：

這句描述說明系統應提供的能力，但未必完整呈現：

• 隊長在什麼情況下開始報名？
• 建立報名資料前需要符合哪些條件？
• 報名過程涉及哪些資料？
• 系統需要檢查哪些業務規則？
• 資料不完整時應如何處理？
• 報名完成後，系統應產生什麼結果或狀態？
• 報名這項功能與其他功能有何關係？

因此，除了需求規格之外，還需要利用不同形式的系統模型（System Model）來呈現系統。也就是說：

文字具有高度表達能力，可以記錄條件、規則、限制、例外及驗收方式。但是，當需求數量增加，而且不同需求彼此關聯時，只依靠逐項文字描述，可能產生幾項困難。

§ 需求規格難以看出整體範圍

需求規格可能分別記錄學生報名、資格審查、評審分派、專題評分及結果公告等功能，但讀者不一定能立即看出：

• 系統涉及哪些外部角色
• 每個角色可以使用哪些系統服務
• 哪些作業屬於系統範圍
• 哪些作業仍由人員或外部系統負責

模型可以將分散在不同需求中的角色、功能及邊界集中呈現，使系統範圍更容易理解。

§ 需求規格難以辨識需求之間的關係

一項業務規則可能影響多項功能需求。例如：

這項規則可能同時影響：

• 評審名單建立
• 評審分派
• 分派結果檢查
• 人工調整分派
• 評審存取專題資料的權限

如果只逐項閱讀需求，可能不容易發現這些關係，或者漏列這些關係。適當的模型可以協助系統分析者找出共同角色、共同行為、資料依賴及規則影響範圍。

§ 難以發現需求規格的缺漏與不一致

需求逐項閱讀時，每一項都可能看起來合理；但將需求放入模型後，可能出現新的問題。

例如：

• 系統提供「審核評分更正」功能，卻未明確說明哪些角色可使用。
• 需求提到評審可以提出更正申請，但未說明誰會收到更正申請，因此無法確定誰可以審核更正申請。
• 結果公告前需要主辦單位確認，但需求中沒有相對應的系統服務。
• 某項功能需要外部身分驗證，卻未說明資訊系統與外部身分驗證系統之間的互動。

這些問題不一定代表模型本身錯誤，而可能表示原有需求仍存在缺漏、衝突或尚未確認的事項。因此：

§ 不同讀者需要不同的模型觀點

利害關係人、系統分析者、設計人員、開發人員及測試人員關心的內容並不完全相同。不同模型可以協助各類讀者從其關注的觀點理解系統。

例如：

• 利害關係人可能關心系統是否能支援實際工作。
• 系統分析者可能關心範圍、角色、規則與例外。
• 設計人員可能關心系統結構及元件責任。
• 開發人員可能關心物件、介面與資料。
• 測試人員可能關心情境、條件與預期結果。

單一模型不需要同時滿足所有讀者，而應根據溝通目的選擇合適的觀點。

6.1.2 系統模型的目的

模型（Model）是對真實事物有目的的簡化表示。模型不會保留真實系統的所有細節，而是根據特定目的選擇需要呈現的資訊。舉例來說，「地圖」就是常見的模型。同一個城市可以有道路圖、大眾運輸圖、行政區域圖及觀光地圖。這些地圖描述的是同一個城市，但保留的內容並不相同。

• 道路圖重視道路及行車方向。
• 大眾運輸圖重視路線、車站及轉乘關係。
• 行政區域圖重視區域邊界。
• 觀光地圖重視景點與旅遊資訊。

不能因為大眾運輸圖沒有畫出每一棟建築，就認為它不完整。也不要因為觀光地圖沒有呈現行政區域界線，就認為觀光地圖有誤。判斷模型是否合宜，應該先確認：

同一個資訊系統可以從不同角度建立不同的模型。不同的模型滿足不同的需求。

這些模型不是互相競爭，也不一定具有一對一的對應關係。每一種模型都從特定角度呈現系統，共同協助讀者建立較完整的理解。系統模型的主要用途說明如下。

§ 簡化複雜系統

真實系統通常同時涉及人員、流程、規則、資料、軟體及外部服務。模型可以暫時忽略較無關的細節，讓分析者專注處理特定問題。

§ 促進溝通

圖形或結構化模型可以為討論建立共同焦點。利害關係人可以針對模型中的角色、功能、流程或資料提出修正，而不必只依賴抽象的口頭描述。

§ 支援需求分析

模型可以協助檢查需求分析的結果是否合宜、是否有遺漏或不一致——例如角色、目標是否齊全，功能與業務規則是否一致，資料是否足以支援作業——補強單靠文字不容易察覺的問題。

§ 保存分析成果

需求分析過程中的重要判斷，例如系統邊界、角色責任及概念關係，可以透過模型加以保存。模型也能作為後續討論、修改與驗證的依據。

§ 連結分析、設計與驗證

經過確認的分析模型，可以提供給系統設計作為輸入，也能協助測試人員理解應驗證的使用情境。但必須注意的是：模型不能自行取代需求規格。圖中未呈現的規則、限制、品質要求及例外條件，仍需要透過文字、表格或其他規格形式保存。

6.1.3 分析模型與設計模型

系統建模可以出現在系統分析與系統設計的不同階段。為避免模型過早加入實作假設，需要區分分析模型（Analysis Model）與設計模型（Design Model）。

§ 分析模型

分析模型著重：

分析模型通常關心：

• 系統邊界
• 外部角色
• 使用者目標
• 業務流程
• 領域概念
• 資料關係
• 系統責任
• 重要事件
• 業務狀態與規則

例如，在Case M01中，分析模型可以呈現：

• 團隊隊長可以提交競賽報名。
• 候選內容：競賽承辦人員可以審查報名資格；此項服務尚須核對需求來源，未確認前不得直接納入正式模型。
• 評審可以評定被分派的專題。
• 主辦單位負責確認競賽結果。
• 評審不得審查本人所指導之學生團隊。

分析模型著重業務需求與系統責任，不需要先決定以下內容：

• 使用哪一種程式語言
• 採用哪一種前端框架
• 資料要儲存在哪一張實體資料表
• 系統要部署在哪一個雲端平台
• 程式內部需要建立哪些技術類別

§ 設計模型

設計模型著重：

設計模型可能進一步呈現：

• 軟體架構
• 元件責任
• 程式介面
• 資料庫結構
• 訊息交換
• 外部服務整合
• 安全控制
• 部署環境

例如，為了實現「評審只能查看被分派的專題資料」，設計模型可能進一步考慮：

• 權限檢查由哪個元件負責
• 評審與分派紀錄如何儲存
• 查詢服務如何限制資料範圍
• 未授權存取如何被拒絕與記錄
• 哪些介面會使用這項服務

分析模型與設計模型之間並非完全分離。分析結果會影響設計，設計過程也可能發現需求不足或存在矛盾，需要重新確認。但兩者的主要問題不同：

§ 避免過早進入設計

初學者在分析階段常會直接加入熟悉的技術方案。例如，需求是：

過早加入設計後，可能直接變成：

後面的說法已經加入：

• 前端技術：React函式庫
• 畫面形式：卡片
• 顏色：藍色
• 資料庫：MySQL

除非這些項目已確認為必要限制，否則不應在分析模型中提前固定。在這個階段，根本不需要確定要使用React函式庫、卡片、藍色、MySQL資料庫。過早進入設計可能造成以下缺點：

• 把目前想到的方案誤認為唯一可行方案
• 過早排除其他可能更合適的設計選擇
• 使利害關係人把注意力轉向技術細節
• 混合業務語言與技術語言
• 因技術選擇改變而使分析模型失去穩定性

因此：

6.1.4 建立與使用模型的基本原則

系統模型的價值不在於圖形數量，而在於模型是否能有效回答分析問題。建立模型時，可以遵循以下原則。

§ 每個模型都應有明確目的

建模前應先回答：

• 這個模型要回答什麼問題？
• 主要讀者是誰？
• 模型需要支援哪一項分析或決策？
• 哪些內容應該呈現？
• 哪些細節可以暫時省略？

如果無法說明模型的用途，就不應只因為某種圖形常見而建立它。

§ 選擇適當的抽象層次

模型過於概括，可能缺乏足夠資訊支援分析；模型過於詳細，則可能難以閱讀，且過早進入實作。

例如，下列使用者目標：

如果只寫成：

範圍過大，無法清楚表達具體目標。

如果拆成：

• 點選新增按鈕
• 輸入團隊名稱
• 點選下一步
• 顯示確認訊息

又可能過早進入介面操作細節。

適當的模型應保留完成業務目標所需的資訊，同時避免混入不必要的設計決策。

§ 使用一致的名稱

需求規格、模型、表格及驗收準則若使用不同名稱，容易造成誤解。例如，同一角色不宜交替稱為：

• 承辦人
• 承辦人員
• 競賽管理者
• 活動管理員

除非這些名稱代表不同角色，否則應選擇一個正式名稱並保持一致。同樣地，「提交競賽報名」與「送出報名資料」若代表同一項系統服務，也應確認是否需要統一。

§ 圖形與文字相互補充

圖形適合呈現：

• 範圍
• 結構
• 關係
• 流程
• 互動
• 狀態

文字適合記錄：

• 詳細條件
• 業務規則
• 例外說明
• 品質要求
• 決議理由
• 待確認事項

不應為了讓圖形看起來完整，而把大量文字全部塞進圖中；也不應只保留圖形，使重要規則與條件無處追蹤。文字與圖形是搭配使用的。

§ 模型元素應具有需求依據

模型中的角色、功能、資料及規則，應能追溯至：

• 已確認的需求
• 正式業務規則
• 需求來源
• 已核准的範圍
• 經權責人員確認的決議

如果建模時發現看似必要但缺乏依據的內容，應將其標示為候選項目或待確認事項，而不是直接當成已確認的模型內容。

§ 模型之間應保持一致

同一個系統可能具有多個模型。不同模型的觀點可以不同，但核心概念不應互相矛盾。例如：

• 如果使用案例模型中包含「評定專題」，流程模型就不應讓未被分派的評審直接評分。
• 資料模型若包含「評分更正申請」，相關流程就應說明其建立及處理方式。
• 狀態模型若規定正式送出的評分不能直接修改，使用案例描述就不應允許評審自行修改分數。
• 所有模型中的角色、資料及狀態名稱應盡量一致。

§ 模型需要經過檢查與確認

模型完成後，至少應檢查：

• 是否符合系統目的與範圍
• 是否具有可查證的需求依據
• 是否遺漏重要角色、目標或情境
• 是否加入沒有來源的假設
• 是否存在名稱或語意不一致
• 是否混入過多實作細節
• 是否能被主要讀者理解
• 是否與其他需求成果一致

利害關係人、分析人員、設計人員及測試人員應共同針對模型進行查核確認，不同角色可能從模型中發現不同問題。

§ 建模工具與AI不能保證模型正確

建模軟體可以協助繪製、保存與輸出模型；生成式AI也可以整理候選元素、轉換表示語法及進行初步檢查。然而，工具能產生圖形或通過語法檢查，不表示模型已符合真實需求。模型仍須核對範圍、語意、需求依據及跨文件一致性。

需求規格與系統模型具有不同但互補的功能：

系統建模不是在需求分析完成後才附加的繪圖工作。建立模型的過程，可能發現新的缺漏、衝突與待確認事項，使需求得到進一步修正。

整個過程可以表示為：

因此：