每個系統分析師今天都應該遵循的DFD最佳實踐

資料流程圖（DFD）仍然是系統分析與設計的基石。它們提供了系統內資訊流動的視覺化表示，突出顯示資料如何進入、通過流程並離開系統。對系統分析師而言，掌握清晰、準確圖表的製作不僅是一項技術技能，更是一種溝通上的必要條件。本指南概述了確保您的DFD能有效發揮作用的關鍵最佳實踐。

🧠 理解DFD的目的

資料流程圖是一種結構化建模技術，用於視覺化展示資料在系統中的流動。與專注於控制流和決策邏輯的流程圖不同，DFD僅專注於資料。它回答以下問題：資料來自哪裡？它會發生什麼變化？最終會去往何處？

在建立DFD時，目標是抽象化複雜性。您是在描繪業務邏輯，而不必陷入程式碼、資料庫結構或特定硬體等實作細節。這種抽象化使利益相關者能夠在無需技術專業知識的情況下理解系統。

為什麼精確性至關重要

• 清晰性： 利益相關者需要在不混淆的情況下看到整體圖景。
• 準確性： 資料流中的錯誤會導致系統設計出現錯誤。
• 溝通： DFD能夠彌合業務需求與技術規格之間的差距。
• 維護： 一份記錄完善的圖表能使未來的變更更容易追蹤。

🏗️ 核心元件與符號

無論使用哪種具體方法論（例如Yourdon & DeMarco或Gane & Sarson），所有DFD都依賴於一組標準符號。理解這些元件是走向最佳實踐的第一步。

📉 DFD層級的層次結構

複雜的系統無法以單一視圖呈現。DFD具有層次結構。將其分解為不同層級，可實現逐步細化。

1. 上下文圖（第0層）

這是最高層級的視圖。它將整個系統表示為單一處理程序。顯示系統邊界以及與外部實體的互動方式。不顯示內部處理程序或資料儲存。

• 重點：系統邊界與外部互動。
• 數量：一個處理程序，多個實體，多個資料流。
• 使用案例：供管理層使用的高階概覽。

2. 第0層圖（功能分解）

此圖將上下文圖中的單一處理程序分解為主要的子處理程序。引入資料儲存，並顯示資料在主要功能區域之間的流動方式。

• 重點：系統的主要功能。
• 數量：為確保易讀性，通常建議為5至9個處理程序。
• 使用案例：定義系統的主要模組。

3. 第1層及以下

這些圖表進一步深入探討第0層中的特定處理程序。用於詳細設計與實作指導。

• 重點：特定邏輯與詳細的資料處理。
• 數量：數量不固定，但應保持可管理。
• 使用案例：開發者交接。

✅ 系統分析師的必要最佳實務

為了建立穩健且可維護的資料流程圖，請遵循這些結構與邏輯規則。

1. 命名慣例

標籤至關重要。讀者應能在不需圖例的情況下理解圖表。模糊不清會導致開發錯誤。

• 處理程序： 使用動詞-名詞組合。範例：「計算稅額」 或 「驗證使用者」。避免使用單一詞語，例如「處理」.
• 資料流： 使用名詞片語。範例：「客戶訂單」 或 「發票資料」。這表示資料流的內容。
• 資料儲存： 使用複數名詞。範例：「客戶紀錄」 或 「訂單日誌」。這意味著一組資料的集合。
• 外部實體： 使用單數或複數名詞來代表行動者。範例：「顧客」 或 「財務部門」.

2. 平衡輸入與輸出

資料守恆是一項基本規則。進入一個流程的資料必須等於離開該流程的資料，即使經過轉換也不應遺失。你不應擁有從無中創造資料（魔法）的流程，或在沒有記錄的情況下刪除資料（除非明確設計）。

• 檢查：針對每個流程，列出輸入流與輸出流。
• 驗證：確保輸出所需的資料元素在輸入中存在。
• 平衡：當從較高層級移動到較低層級時，父流程的輸入與輸出必須與子流程的總輸入與總輸出相符。

3. 避免控制流

一個常見的錯誤是將決策邏輯混入資料流中。DFD 展示的是資料如何移動，而非決策是如何做出的。如果需要決策，應在獨立的規格說明或決策表中記錄，而不是以菱形符號出現在 DFD 上。

• 規則：禁止使用菱形或決策點。
• 規則：流程本身不得包含迴圈或迭代循環。
• 替代方案：如果邏輯較為複雜，可使用獨立的控制流圖。

4. 資料儲存互動

資料必須流入和流出資料儲存。一個流程不能單獨存在於真空之中。

• 讀取/寫入：明確區分讀取資料與寫入資料。雖然某些符號允許使用單一箭頭，但明確標示（讀取/寫入）可減少混淆。
• 幽靈資料： 不要创建从不被写入或读取的数据存储。
• 連接性： 流程必須連接到數據存儲。外部實體不能直接連接到數據存儲（除非它們擁有數據，這通常需要明確的邊界定義）。

5. 線條交叉與佈局

視覺清晰度至關重要。一張看起來像一盤意大利麵的圖表毫無用處。

• 避免交叉： 儘量安排流程和流動，使線條不交叉。如果必須交叉，請使用立體交叉符號或線條上的小斷點。
• 邏輯分組： 將相關的流程聚集在一起。如果流程A為流程B提供輸入，請將它們放置在彼此附近。
• 方向： 通常情況下，流動應從左到右或從上到下，以符合閱讀習慣。
• 留白： 使用充足的間距以避免混亂。擁擠的圖表會掩蓋錯誤。

🚫 應避免的常見陷阱

即使經驗豐富的分析師也會犯錯。了解常見陷阱有助於你保持高品質。

1. 黑洞

一個有輸入但無輸出的流程。這意味著數據被消耗卻未產生任何結果。在一個正常運作的系統中，這在邏輯上是不可能的，除非數據被丟棄，而這必須明確標示。

2. 奇蹟流程

一個有輸出但無輸入的流程。這暗示數據憑空出現。每個輸出都必須有其來源。

3. 直接實體到實體的流動

外部實體不應在未經過系統的情況下直接將數據傳遞給彼此。如果實體A將數據給實體B，數據必須先進入系統，經過處理，然後再離開。

4. 名稱不一致

如果你將一個流動稱為「使用者資料」在上下文圖中，就不要稱它為「客戶資訊」在0級圖中。一致性確保可追蹤性。

5. 過度細化

不要在0級圖中詳細列出每一個步驟。保持在功能層級即可。如果你正在列出每一個按鈕點擊，你其實是在製作UI線框圖，而不是資料流程圖。

🔄 將資料流程圖與需求整合

DFD 不會孤立地創建。它們必須與業務需求保持一致。

• 可追溯性： DFD 中的每個流程都應對應一個需求。如果某個流程沒有對應的需求，可能會導致不必要的範圍蔓延。
• 驗證： 與利益相關者一起審查 DFD。詢問他們流程是否符合他們對業務的理解。
• 演進： 當需求變更時，DFD 必須立即更新。一份過時的圖表比沒有圖表更糟糕。

🛠️ 維護與生命週期

DFD 是一份活文件。系統上線後，圖表仍應持續維護。

• 變更管理： 當新增功能時，應更新圖表。在每張圖表上記錄版本號和日期。
• 文件連結： 將 DFD 與資料字典連結。此文件定義了流程上顯示的資料元素結構。
• 審查週期： 計畫定期審查圖表，以確保它們仍與已部署的系統相符。

📝 關鍵規則摘要

為確保您的 DFD 專業且實用，請在設計會議期間隨時攜帶此檢查清單。

• ✅ 流程使用動詞-名詞格式。
• ✅ 資料流使用名詞格式。
• ✅ 確保每個流程至少有一個輸入和一個輸出。
• ✅ 確保每個資料儲存都至少被一個流程存取。
• ✅ 保持父圖與子圖之間的一致性。
• ✅ 儘可能避免線條交叉。
• ✅ 不要將控制邏輯與資料流混合。
• ✅ 清楚標示每一個箭頭與圖形。
• ✅ 與業務利益相關者審查以確保準確性。
• ✅ 系統變更時更新圖表。

🔍 DFD 與其他圖表的差異

區分 DFD 與其他建模技術非常重要，以避免混淆。

• 流程圖： 關注控制邏輯和順序。資料流程圖關注資料轉換。
• 實體關係圖（ERD）： 關注資料結構和關係。資料流程圖關注資料流動。
• 使用案例圖： 關注使用者互動和目標。資料流程圖關注系統內部結構。

使用適合的工具完成適合的工作，可防止模型疲勞，並確保每個圖表在文件套件中發揮獨特的作用。

🎯 實施的最後想法

建立資料流程圖需要在技術準確性與商業溝通之間取得平衡。透過遵循既定的最佳實務，確保你的圖表不只是繪圖，而是系統成功的功能性藍圖。專注於清晰度、一致性與驗證。當利害關係人看到你的圖表並說：「是的，這正是我們的工作方式」時，你就達到了目標。

請記住，圖表只是一種達成目標的手段，而非目標本身。其價值在於所產生的理解，以及在程式碼撰寫之前幫助避免的錯誤。優先考慮資料流程的邏輯，維持嚴格的命名規範，並保持層級結構的邏輯性。秉持這些實務，你的系統分析將變得穩健、清晰且有效。