系統分析師數據流圖快速入門

數據流圖（DFD）是系統分析師用來理解、設計和記錄複雜資訊系統的基礎工具。它們以視覺化方式呈現資料在系統中的流動情況，強調處理程序、資料儲存與外部互動。本指南概述了構建準確且實用的數據流圖所必需的基本原則、符號與方法論，且不依賴特定專有工具。

什麼是數據流圖？📊

數據流圖是一種以圖形方式呈現資料在資訊系統中流動的工具。與專注於控制流程和邏輯的流程圖不同，數據流圖專注於資料從輸入到輸出的轉換過程。它們幫助分析師透過將系統分解為較小且可管理的部分，來繪製系統的功能需求。

數據流圖不會詳細顯示時間順序或決策邏輯。相反地，它們回答一些關鍵問題，例如：

• 資料來自哪裡？
• 資料在系統內部會發生什麼變化？
• 資料處理後會去哪裡？
• 資料儲存在哪裡？

透過視覺化這些元素，分析師可在程式碼開發前識別瓶頸、重複的流程以及安全漏洞。數據流圖所使用的符號通常遵循尤爾頓與德馬科的標準，但也有其他變體存在。

為什麼系統分析師需要數據流圖💡

對系統分析師而言，清晰明確至關重要。利益相關者經常難以理解技術術語，但視覺化圖表能彌補業務需求與技術實現之間的差距。數據流圖在分析階段扮演多項關鍵功能：

• 溝通： 它們作為業務利益相關者與技術團隊之間的共同語言。
• 文件記錄： 它們為未來的系統維護提供永久性的系統行為記錄。
• 分析： 它們能揭示在初步訪談中被忽略的缺失流程或資料儲存。
• 驗證： 它們有助於確認系統是否符合既定需求。

優勢	對專案的影響
需求驗證	透過確認範圍內與外的內容，減少範圍蔓延。
系統設計	引導資料庫設計與API架構。
培訓	協助新成員快速理解系統邏輯。
除錯	有助於追蹤資料錯誤的來源。

核心組件與符號 🛠️

理解資料流程圖（DFD）的構建模塊對於創建準確的圖表至關重要。標準DFD符號中使用了四個主要元素。

1. 外部實體

外部實體代表系統邊界之外的資料來源或目的地。它們是與系統互動的使用者、其他系統或組織。在圖表中，這些通常以矩形或正方形表示。

• 範例：客戶、銀行、庫存系統。
• 注意：如果內部使用者或部門屬於所建模的系統，則不要將其視為外部實體。

2. 處理過程

處理過程將資料從輸入轉換為輸出。它們代表系統執行的功能或動作。在DFD中，處理過程通常以圓形或圓角矩形繪製。每個處理過程至少必須有一個輸入和一個輸出。

• 範例：計算稅款、驗證使用者、生成報表。
• 注意：避免使用資料名稱來命名處理過程（例如「儲存資料」）。應使用動作動詞。

3. 資料儲存

資料儲存代表資料在系統中被保存以供後續使用的地點。它們並不代表特定技術（如SQL資料庫或Excel表格），而是資料的邏輯位置。這些通常以開口矩形或平行線繪製。

• 範例：客戶資料庫、訂單歷史、檔案儲存庫。
• 注意：資料流會流入和流出儲存，但外部實體不能直接連接到資料儲存。

4. 資料流

資料流顯示資料在實體、處理過程和儲存之間的移動。它們以箭頭表示。箭頭上的標籤描述的是被移動的資料包，而非所執行的動作。

• 範例：發票、付款細節、使用者憑證。
• 注意：箭頭必須為單向。如果資料雙向流動，應使用兩個獨立的箭頭。

元件	形狀	功能
外部實體	矩形	系統外部資料的來源或目的地
流程	圓形 / 圓角矩形	轉換資料
資料儲存	開口矩形	儲存資料以供未來使用
資料流	箭頭	顯示資料移動的方向

DFD 的層級 📉

DFD 是層次化的。您從高階概覽開始，逐步將流程分解為更詳細的子流程。這種技術稱為分解。

第 0 層：上下文圖

上下文圖是抽象層級最高的圖。它將系統表示為一個單一流程（通常是一個大圓圈），並顯示與其互動的所有外部實體。它定義了系統的邊界。

• 一個流程： 整個系統由一個泡泡表示。
• 輸入/輸出： 顯示主要資料流進入和離開系統的情況。
• 無資料儲存： 上下文圖通常不會顯示內部資料儲存。

第 1 層：功能分解

第 1 層的 DFD 將上下文圖中的單一流程分解為主要的子流程。此層級揭示了系統的主要功能，而不會陷入細節之中。

• 主要流程： 通常為 5 到 9 個流程，以保持可讀性。
• 資料儲存： 在此引入內部儲存庫。
• 一致性： 輸入和輸出必須與上下文圖一致。

第 2 層：詳細分解

第二層資料流程圖會將第一層中的特定流程進一步分解。這適用於需要更高細節程度的複雜功能。

• 重點：僅特定流程會被分解；其他流程則保持為第一層的圓泡。
• 細節：顯示特定的資料轉換與中間儲存位置。

建立資料流程圖：逐步指南 📝

建立資料流程圖需要採取結構化的方法，以確保準確性與一致性。遵循以下步驟，以建立穩健的圖表。

步驟 1：定義系統邊界

識別系統內部與外部的內容。這將決定哪些實體為外部，哪些為內部。邊界以外的所有項目均為外部實體。

步驟 2：識別外部實體

列出所有與您的系統互動的人、部門或系統。為每個實體賦予唯一的名稱。避免使用模糊的名稱，例如「使用者」；應使用具體的角色名稱，如「管理員」或「訪客」。

步驟 3：繪製主要資料流

繪製箭頭，將實體連接到系統。以傳輸的資料來標示這些資料流（例如：「登入請求」、「銷售報表」）。確保每個實體至少有一個連接。

步驟 4：定義核心流程

將系統分解為邏輯功能。使用動詞-名詞格式命名每個流程（例如：「處理訂單」）。確保每個流程都有輸入與輸出。

步驟 5：新增資料儲存

識別資料必須儲存的位置。將流程與資料儲存連接，以顯示讀取與寫入操作。請記住，資料流可以從流程流向儲存，或從儲存流向流程。

步驟 6：檢視與平衡

檢查父圖與子圖之間的輸入與輸出是否一致。這稱為「平衡」。若第一層流程的輸入為「客戶資料」，則子圖也必須接收「客戶資料」。

驗證規則與最佳實務 ✅

為確保您的資料流程圖在技術上正確且實用，請遵守以下驗證規則。

• 無幽靈資料流：每個資料流都必須連接到一個流程或儲存位置。不要讓箭頭懸浮。
• 黑洞：流程不能在沒有輸入的情況下產生輸出。若資料進入，則必須有某種處理發生。
• 奇蹟：流程不能在沒有輸出的情況下有輸入。每一個轉換都必須產生結果。
• 資料儲存命名：資料儲存使用複數名詞（例如：「訂單」），資料流則使用單數名詞（例如：「訂單」）。
• 流程命名： 使用主動動詞。避免以處理的資料來命名流程（例如，使用「驗證密碼」而非「密碼」）。
• 一致性： 確保相同資料流在圖表的不同層級中標籤一致。
• 複雜度控制： 如果一個泡泡過於擁擠，請將其分解。目標是每張圖表包含 5 到 9 個流程。

應避免的常見陷阱 ⚠️

即使經驗豐富的分析師也會犯錯。了解常見錯誤可節省審查會議的時間。

• 混淆控制與資料： 資料流程圖顯示資料，而非控制流程。不要顯示判斷菱形或迴圈（除非用來表示資料儲存）。
• 實體與儲存之間的直接連接： 外部實體無法直接寫入資料儲存。所有資料必須先經過流程。
• 過於技術性的細節： 不要顯示資料庫表格或檔案名稱。保持邏輯性，而非物理性。
• 遺漏反饋迴路： 如果某流程需要來自先前輸出的輸入，請確保流程正確呈現。
• 命名不一致： 避免對相同資料使用同義詞（例如「客戶」與「客戶」）。堅持使用一種術語。

邏輯型與物理型資料流程圖 🔄

分析師經常為同一系統創建兩種類型的圖表。理解兩者的差異對於有效溝通至關重要。

功能	邏輯型資料流程圖	物理型資料流程圖
重點	業務需求與規則。	實作細節與技術。
流程名稱	通用動作（例如「計算價格」）。	具體動作（例如「執行稅務演算法 V2」）。
資料儲存	邏輯容器（例如「庫存」）。	實體檔案或資料表（例如「SQL 資料表 INV」）。
時序	不顯示時序或頻率。	可能顯示批次處理或即時觸發。
使用案例	需求收集與設計。	系統架構與開發。

區分 DFD 與其他圖表 📐

很容易將 DFD 與其他建模工具混淆。以下是它們的差異。

• DFD 與流程圖：流程圖顯示邏輯流程（if/else、迴圈）。DFD 則顯示資料流動。流程圖回答「接下來發生什麼？」，而 DFD 則回答「資料會去哪裡？」
• DFD 與實體關係圖：實體關係圖著重於資料結構以及實體之間的關係。DFD 則著重於資料的流動與轉換。
• DFD 與使用案例圖：使用案例圖顯示使用者互動與目標。DFD 則顯示支援這些目標的內部機制。

維護與更新 DFD 🔄

DFD 不是一次性的交付成果。系統會演進，圖表也必須隨之演進。定期維護可確保文件內容保持準確。

• 版本控制：追蹤變更內容。以版本號碼或日期標示圖表。
• 變更請求： 新功能加入時，於程式碼開發前更新 DFD。
• 審查週期： 計畫定期與利害關係人審查，以確認圖表符合目前的運作狀況。
• 整合： 確保 DFD 與其他文件（如需求規格與資料庫結構）一致。

實務範例：電子商務訂單系統 🛒

為說明這些概念，請考慮一個線上商店。情境圖會將「顧客」與「付款網關」顯示為外部實體。

在第一層 DFD 中，系統流程「訂單管理」會拆分為：

• 流程：「接收訂單」
• 流程：「驗證庫存」
• 流程：「處理付款」
• 流程：「發貨」

資料流包括「訂單詳情」、「庫存檢查」和「確認」。資料儲存則包括「產品目錄」和「交易記錄」。此分解確保顧客旅程中的每一步都得到妥善處理。

關於DFD精通的最後想法 🎯

創建有效的資料流程圖需要耐心與細心。這是一項隨著練習而提升的技能。透過專注於資料流動而非邏輯，您能為開發人員與利益相關者提供清晰的指引。請記住，目標是清晰，而非複雜。保持圖表簡潔、一致，並與業務現實相符。

當您持續擔任系統分析師的工作時，請運用DFD來挖掘隱藏的需求並簡化系統設計。它們仍然是在複雜環境中可視化資訊流動最可靠的工具之一。