什麼是資料流程圖？新分析師的清晰逐步解析

理解複雜系統不僅僅需要談論它們，還需要視覺化資訊如何在其中流動。這正是「資料流程圖」，通常稱為 DFD，成為商業與系統分析師不可或缺的工具。無論您是設計新應用程式、審核現有工作流程，還是記錄需求，掌握 DFD 的基本知識對於清晰溝通至關重要。本指南全面解析了 DFD 是什麼、其核心組成部分，以及如何有效構建它。

資料流程圖是一種以圖形方式呈現資料在資訊系統中流動的表示法。它顯示資料如何進入系統、如何被處理、儲存在哪裡，以及如何離開系統。與專注於控制流程和邏輯的流程圖不同，DFD 僅專注於資料的移動。這項區別對分析師至關重要，因為他們需要繪製系統功能，而不必陷入決策邏輯的細節中。

資料流程圖的核心組成部分 🧩

每個 DFD 都建立在四個基本符號之上。雖然不同方法論之間的符號風格略有差異，但其背後的概念保持一致。要創建有效的圖表，您必須理解每個元素的作用。

• 外部實體： 也稱為終結點或資料來源/接收點，代表與被建模系統互動的人、組織或其他系統。它們是輸入資料的來源或輸出資料的目的地。它們位於系統邊界之外。
• 處理程序： 這些代表對資料執行的工作。處理程序會將輸入資料轉換為輸出資料。它可能是一項計算、驗證步驟或排序操作。每個處理程序都必須至少有一個輸入和一個輸出。
• 資料儲存： 這些是資料暫時儲存以供後續使用的場所。它們代表資料庫、檔案或手動記錄系統。資料不會直接從一個資料儲存流向另一個資料儲存，而必須經過處理程序。
• 資料流： 這些是連接各元件的線條，表示資料的移動。它們以所傳輸資料的名稱標示。資料流代表資訊的流動，而非實體的電線或連接。

理解DFD層級 📉

DFD通常以一系列層級創建，從高階抽象逐步轉向詳細的具體內容。這種技術稱為分解。這使得利益相關者可以在深入細節之前先理解整體概況。

1. 上下文圖（第0層）

上下文圖是最高層次的視圖。它將整個系統表示為單一處理過程。它顯示系統的邊界以及與外部世界的互動方式。此圖回答的問題是：「系統是什麼，誰與它對話？」

• 單一處理過程： 整個系統是一個單一的氣泡。
• 外部實體： 所有外部來源和目的地均被顯示。
• 資料流： 僅顯示主要的輸入與輸出。
• 無資料儲存： 此層級中，內部儲存被隱藏。

2. 第0層圖（分解）

當上下文建立後，單一處理過程會被分解為主要的子處理過程。此圖顯示系統的高階功能區域。它引入資料儲存，並將資料流分解為更易管理的片段。

• 多個處理過程： 通常為3到7個主要處理過程。
• 資料儲存： 主要儲存庫被識別出來。
• 一致性： 輸入與輸出必須與上下文圖完全一致。

3. 第1層與第2層圖

在較低層級中會進行進一步的分解。第1層詳細說明第0層的處理過程，而第2層則詳細說明第1層中的特定處理過程。目標是達到每個處理過程都成為一個基本處理過程——一個無法再進一步分解而不會失去意義的步驟。

建立DFD的逐步指南 🛠️

建立資料流程圖是一個系統性的過程。遵循結構化的方法可確保在整個建模生命週期中保持準確性與一致性。

步驟1：定義系統邊界

在繪製任何內容之前，先識別系統內部與外部的內容。這定義了分析的範圍。所有為系統產生資料或從系統接收資料的項目均為外部實體。組織或軟體內部發生的一切均為內部內容。

步驟 2：識別外部實體

列出所有相關的使用者、部門或外部系統，並給予明確且具描述性的名稱。若有可能，避免使用模糊的詞語如「使用者」，改用「客戶」或「管理員」等詞。這為上下文圖的建立奠定基礎。

步驟 3：繪製主要的資料流

繪製箭頭，將實體連接到中央流程。為每個箭頭標示所交換的具體資料。例如，應使用「訂單詳情」而非僅僅「資料」。這可確保日後閱讀圖表的人能清楚理解。

步驟 4：建立 Level 0 圖

將中央流程拆分成主要功能。識別資料儲存的位置。確保上下文圖中的每一筆資料流在此處仍然存在。這通常稱為平衡。若上下文圖顯示「發票」離開系統，Level 0 圖也必須顯示「發票」離開系統。

步驟 5：進一步分解

從 Level 0 中挑選一個複雜的流程，並分解為 Level 1 的較小步驟。重複此過程，直到流程簡單到足以被理解為單一動作。確保資料儲存不會被跳過，且所有資料流都已被納入考量。

基本規則與規範 ✅

為維持模型的完整性，分析師必須遵守特定規則。違反這些規則可能導致混淆，並產生不準確的系統設計。

• 禁止實體與實體之間的直接資料流：資料無法在未經過系統的情況下，直接從一個外部實體流到另一個外部實體。若發生此情況，表示系統缺少處理該互動的流程。
• 禁止資料儲存與資料儲存之間的資料流：資料無法在沒有流程的情況下，於儲存位置之間移動。必須有某種處理動作來轉換或移動資料（例如備份流程或資料遷移腳本）。
• 每個流程都必須有輸入與輸出： 若一個流程有資料流入但無任何資料流出，則為「匯集點」（sink），技術上屬於實體而非流程。同樣地，沒有輸入的流程則為「來源」（source）。
• 命名規範： 流程應以「動詞＋名詞」結構命名（例如「計算稅額」）。資料流與資料儲存則應以「名詞」結構命名（例如「稅率」）。
• 命名一致性： 高階層的資料流名稱必須與低階層的資料流名稱一致。若在 Level 0 時稱為「客戶資料」，則在 Level 1 時不應稱為「使用者資訊」，除非明確定義兩者之間的關係。

常見錯誤應避免 ⚠️

即使經驗豐富的分析師在建模時也會犯錯。及早識別這些陷阱，可在審查階段節省大量時間。

• 控制流與資料流： 不要混淆流程發生的時機（控制）與所移動的資料（資料）。資料流程圖（DFD）不會明確顯示迴圈或條件。
• 過度複雜： 一張包含 50 個流程的圖表通常難以閱讀。應使用分解方式，使圖表保持清晰且易於管理。
• 遺漏資料儲存： 忘記標示資料儲存位置，可能導致設計中資訊在步驟之間遺失。
• 黑洞： 一個有輸入但無輸出的過程稱為黑洞。它消耗資料，但不產生任何東西。
• 奇蹟過程： 一個有輸出但無輸入的過程稱為奇蹟。它能從無到有創造資料。

DFD 與流程圖：了解兩者的差異 🔄

人們經常混淆資料流程圖與流程圖。雖然它們外觀相似，但用途不同。

了解這項區別能確保你使用正確的工具來完成正確的工作。若需定義決策的執行方式，請使用流程圖；若需定義支援決策所需的資料，請使用 DFD。

使用資料流程圖的好處 🌟

為什麼要花時間繪製這些圖表？其價值遠超過文件編製。

• 改善溝通： 它提供一種視覺化語言，讓利害關係人、開發人員與業務使用者都能理解。這能彌補技術與非技術團隊之間的隔閡。
• 更佳的需求收集： 畫圖的過程經常會在建立階段揭露遺漏的需求或不清的流程。
• 系統分析： 它有助於識別重複的流程、瓶頸，或資料未被有效利用的區域。
• 文件標準： 它作為系統架構的永久記錄，有利於維護和未來升級。
• 培訓工具： 新成員可以透過檢視圖表而非閱讀冗長的文字，更快地了解系統的資料流程。

分析師的最佳實務 🎓

為確保您的圖表專業且有效，請考慮以下實用建議。

• 使用一致的符號： 在整個專案中堅持使用一種風格（例如 Gane & Sarson 或 Yourdon & DeMarco），以避免混淆。
• 保持整潔： 避免線條交叉。若線條必須交叉，請使用弧線表示它們並未連接。
• 為您的流程編號： 為流程編號（例如 1.0、1.1、1.2）有助於在文件中引用，並維持層級結構。
• 與利害關係人共同審查： 永遠不要假設您的圖表是正確的。應與業務使用者一起走查，以確認準確性。
• 迭代： 資料流程圖通常在第一稿時並非完美。隨著對系統了解的加深，應預期需不斷修正。

實務範例：訂單處理系統 🛒

為說明這些概念如何應用於實際情境，請考慮一個訂單處理系統。

背景圖：

• 實體：顧客
• 實體：庫存系統
• 流程：訂單處理
• 資料流： 顧客發出的「訂單請求」，發送到庫存系統的「庫存檢查」，以及回傳給顧客的「確認」。

第 0 層圖：

• 流程 1.0：接收訂單
• 流程 2.0：驗證庫存
• 流程 3.0：生成發票
• 資料儲存：訂單資料庫
• 資料儲存：產品目錄

第 1 層圖示（分解流程 2.0）：

• 流程 2.1：檢查庫存水準
• 流程 2.2：更新庫存
• 資料儲存：庫存日誌

此分解顯示了單一高階需求如何轉化為可執行的系統組件，而無需指定特定的軟體工具。

DFD 建模總結 📝

資料流程圖仍然是系統分析的基石。它提供了一種結構化的方式來思考資料流動與系統邊界。透過遵循分解規則、保持命名一致，並避免常見陷阱，分析師可以建立既準確又實用的模型。目標不僅是畫出線條，更是理解推動商業價值的資訊流動。

對於新手分析師而言，從清晰的背景圖開始並逐步向下分解，是最可靠的途徑。請記住，圖表是一份活文件。隨著需求變更，圖表也應隨之演進以反映新的現實。這種彈性確保系統文件在整個專案生命週期中保持相關性。

透過掌握這些基礎知識，您將具備強大的分析與設計工具。能夠視覺化資料流動是一項跨產業與技術的技能。無論您從事網頁應用、企業軟體或內部工作流程，資料流程圖的原則都普遍適用。