每個複雜系統都始於一系列想法、需求與限制，這些就是需求。然而，以自然語言書寫的需求往往含糊不清，容易產生誤解，且在技術驗證上困難重重。為了填補利害關係人所期望的內容與工程師所建構內容之間的差距，我們需要一種視覺語言。這正是數據流圖（DFD）變得不可或缺之處。🧭
數據流圖不僅是一張圖表；它是一個邏輯模型，用於映射資訊如何在系統中流動。它摒除實體實現的細節，專注於數據本身的流動。本文將探討將原始需求轉化為結構化且經過驗證的數據流模型的嚴謹過程。
理解基礎：需求分析 📝
在繪製任何箭頭之前，必須充分理解輸入內容。需求分析是模型所立足的基礎。若缺乏堅實的基礎，上方的結構將不穩定。
功能性與非功能性需求
DFD 主要建模功能性行為。它們回答的問題是：「系統對數據做了什麼？」非功能性需求（如效能、安全性或延遲）會影響實體設計，但通常不會以節點形式出現在 DFD 中。然而，它們決定了數據流動所必須遵循的限制。
- 功能性需求：系統必須執行的特定行為或功能（例如：「系統必須根據地區計算稅額。」）。
- 非功能性需求：品質屬性（例如：「計算必須在 2 秒內完成。」）。
收集輸入資訊
模型的資訊來自多個來源。訪談、使用者故事及現有文件提供了原始素材。目標是識別所有與系統互動的實體，以及所有進入或離開系統的數據。
在收集這些資訊時，請留意動詞。動詞通常表示處理過程；名詞通常表示數據物件或實體。這種語言線索有助於圖表的初步範圍界定。
數據流圖的核心概念 🗺️
要建立有效的模型，必須遵循標準符號。雖然符號略有差異，但核心概念保持一致。數據流圖由四個主要組件構成。
1. 外部實體（參與者）
這些是系統邊界之外的數據來源或目的地。它們可能是人、其他系統或組織。在 DFD 中，它們通常以矩形表示。
2. 處理過程（轉換）
處理過程將輸入數據轉換為輸出數據。它們是系統的活躍元素。在 DFD 中，它們通常以圓形或圓角矩形表示。一個處理過程必須至少有一個輸入和一個輸出。
3. 數據流（移動）
這些是顯示數據移動方向的箭頭。它們連接實體、處理過程和數據儲存。每個數據流都必須有標籤，說明正在移動的資訊（例如：「訂單詳情」）。
4. 數據儲存（記憶體）
這些代表用於後續使用的數據存放位置。它們是被動的儲存庫。在 DFD 中，它們通常以開放式矩形或平行線表示。數據儲存不會觸發動作；它僅等待被讀取或寫入。
轉換過程：從文字到線條 🛠️
將文字轉化為圖表需要系統化的方法。此過程涉及分解與抽象。你無法一次繪製整個系統。你必須從高層開始，逐步深入。
步驟 1：定義系統邊界
決定系統內部與外部的內容。內部所有內容均為處理過程、儲存或數據流；外部所有內容均為外部實體。此邊界對於定義情境至關重要。
步驟 2：識別情境
建立一個情境圖（亦稱為零級數據流圖）。這是最高層次的抽象。它將整個系統視為單一處理程序，並顯示其與外部實體的互動。
- 處理程序：整個系統的名稱。
- 實體：所有外部來源與匯集點。
- 流程：主要資料輸入與輸出。
步驟三：分解處理程序
一旦確立情境，即將單一處理程序分解為主要子處理程序。此即一級數據流圖。每個子處理程序應處理源自需求之獨立功能。請確保進入頂層的資料亦進入其中一個子處理程序。
步驟四：新增細節與儲存區
當您深入至二級及更高層級時，您將引入資料儲存區。此處邏輯變得具體。您需定義資料在各步驟間存放的位置。請確保每個資料儲存區至少連接到一個處理程序（您不能僅建立儲存位置而無更新或檢索之途徑）。
抽象層級說明 📊
數據流圖具有階層結構。這使利害關係人能以其理解程度適當的層級檢視系統。下表概述標準層級之間的差異。
| 層級 | 範圍 | 主要焦點 | 典型受眾 |
|---|---|---|---|
| 情境圖 | 整體系統 | 主要輸入與輸出 | 利害關係人、管理層 |
| 一級 | 主要功能 | 關鍵處理程序與資料儲存區 | 專案經理、架構師 |
| 第二層 | 子流程 | 具體的資料轉換 | 開發人員、分析師 |
| 第三層及以上 | 原子流程 | 詳細的邏輯流程 | 工程師 |
請注意，隨著層級數字的增加，複雜度也會提高。情境圖提供鳥瞰視圖，而更深的層級則提供詳細的機制。
確保一致性与平衡 ⚖️
在資料流程圖（DFD）建模中，最關鍵的規則之一是平衡。當您分解一個流程時，父流程的輸入與輸出必須與所有子流程的輸入與輸出總和相符。您無法無中生有地創造或銷毀資料。
如果一個第一層流程以「使用者登入」為輸入，其子流程中必須有一個最終接受「使用者登入」或其衍生版本。如果某個流程輸出「報告」，該輸出也必須出現在父流程圖中。這確保了層級間的邏輯完整性。
驗證技術
您如何確認模型是正確的？驗證涉及多項檢查：
- 流程驗證：追蹤每一支箭頭從來源到目的地。這是否合理？是否有對應的流程來處理它？
- 實體覆蓋：情境圖中是否已代表所有外部實體？
- 儲存庫使用：是否每個資料儲存庫都有被存取？未連接的儲存庫通常代表無效程式碼。
- 需求映射：您能否將每項需求追溯至圖中的某個流程或流程？
資料流程建模的挑戰 ⚠️
建立這些模型並非總是直截了當。分析師經常遇到會阻礙進度或導致不準確表示的障礙。
需求模糊
如果初始需求模糊，圖表也會模糊。例如，「處理訂單」過於寬泛。這是指「接收訂單」、「驗證庫存」還是「出貨」？這是三個需要獨立節點的明確流程。精確定義動詞至關重要。
範圍蔓延
在建模階段，經常會出現新需求。這很容易讓人想立即加入。然而，過早加入太多細節會使圖表變得雜亂。更好的做法是將新需求記錄在待辦事項清單中，並在模型的下次迭代中處理。
與控制流程混淆
一個常見的錯誤是將控制邏輯與資料流程混為一談。資料流程圖（DFD）顯示的是「哪些資料在移動，而非「何時移動」」。控制流程圖（如流程圖）顯示邏輯分支（if/else）。DFD 假設流程會發生，僅展示資料的流動。請將焦點放在資料負載上，而非決策邏輯。
長期維護模型 🔄
需求會改變，系統會演進。DFD 並非一次繪製後便歸檔的靜態產出，而必須作為一份活的文件持續維護。
當需求變更時，請追蹤其影響。若新增了一個資料欄位，是否會改變流程？是否需要新增儲存區？請立即更新圖表。這能確保文件與現實保持一致。
版本控制也至關重要。隨著模型的成長，舊版本對於審計或理解舊有邏輯仍具參考價值。為版本標註名稱（例如 DFD_v1.0、DFD_v2.0）有助於追蹤系統設計的演進。
提升清晰度的最佳實踐 ✨
為確保模型能達成其目的，請遵循以下溝通指南。
- 為所有項目命名：實體、流程與資料流必須擁有清晰且具描述性的名稱。除非是業界標準，否則避免使用縮寫。
- 限制複雜度：若單一流程的輸入或輸出超過七個，則可能過於複雜，應進一步分解。
- 最小化線條交叉：雖非總是可行，但請嘗試安排圖表，使箭頭不致過度交叉，以提升可讀性。
- 使用一致的符號：整份文件應堅持使用同一種符號表示法（例如 Gane & Sarson 或 Yourdon & DeMarco）。
系統設計結論 🏁
從需求到資料流程模型的旅程，是一門追求清晰度的學問。這需要剝除實作上的雜訊，以窺見資訊的核心流動。透過遵循分解、平衡與驗證的原則，您將建立一份工程師信賴、利害關係人能理解的藍圖。
此模型成為資料庫設計、API 定義與介面規範的參考基準，將專案紮根於現實之中。當需求穩固時，圖表便是引導團隊抵達目標的地圖。請將焦點放在資料上，尊重邊界，並確保每一支箭頭都訴說一個故事。