資料流程圖（DFD）在系統分析與業務流程建模領域中扮演著基石的角色。對業務分析師而言，掌握如何視覺化資訊在系統中流動的方式，不僅是一項技術技能，更是一種溝通上的超能力。一張設計良好的DFD能將原本混亂的狀況變得清晰，揭露瓶頸、重複流程以及優化機會。
本指南從業務角度探討DFD的實際應用。內容涵蓋基礎概念、結構組成、不同抽象層級，以及不依賴特定軟體工具來建立有效圖表的方法。完成後，您將了解如何運用這些圖表，彌合利害關係人需求與技術實現之間的差距。
什麼是資料流程圖？ 🧐
資料流程圖是一種以圖形方式呈現資料在資訊系統中流動的表示法。與專注於控制邏輯與決策步驟的流程圖不同，DFD僅專注於資料的移動。它回答的問題是：資料發生了什麼事？
對業務分析師而言，DFD是一種探索工具。它幫助您理解現狀（現行系統），並設計未來狀態（目標系統）。它讓您忽略系統的物理細節，專注於資訊的邏輯流程。
為何DFD對業務分析師如此重要 🤔
- 釐清需求： 利害關係人經常難以用文字描述複雜的系統。視覺化模型能讓需求具體可見。
- 識別缺口： 在繪製資料流時，遺漏的資料儲存或外部實體會立即顯現。
- 溝通： 它為業務利害關係人與技術團隊之間提供了共同語言。
- 流程優化： 它能突顯不必要的資料移動或工作流程中的瓶頸。
DFD的核心組成部分 🧩
在嘗試繪製圖表之前，理解基本構成要素至關重要。標準DFD符號中使用了四種主要符號。雖然特定風格（如Gane & Sarson或Yourdon & DeMarco）略有差異，但概念保持一致。
1. 外部實體 👤
外部實體代表系統邊界以外的資料來源或目的地。這可能是個人、團體、另一個系統或組織。系統與它們互動，但它們並非內部邏輯的一部分。
- 範例：客戶、供應商、銀行、政府機構。
- 角色： 它們啟動資料流或接收最終輸出。
2. 處理程序 ⚙️
處理程序代表資料的轉換。它接收輸入資料，執行某種動作（計算、驗證、儲存），並產生輸出資料。在DFD中，處理程序並非關注「如何」動作在技術上是如何執行的，而是關注「什麼」資料正在發生什麼事。
- 範例：計算稅款、驗證訂單、產生報表。
- 規則：一個流程必須至少有一個輸入和一個輸出。
3. 資料儲存庫 📂
資料儲存庫代表資料被保存以供後續使用的地點。它不是一個流程；它不會改變資料。它是一個被動的儲存庫。這可能是資料庫表格、檔案、實體檔案櫃，或雲端儲存桶。
- 範例：客戶資料庫、庫存日誌、已存檔訂單。
- 規則：資料流入儲存庫以進行儲存，並從儲存庫流出以進行檢索。
4. 資料流 🔄
資料流顯示資料在實體、流程和儲存庫之間的移動。它代表一個在系統中傳輸的資訊封包。它以箭頭表示。
- 標籤：每個箭頭都必須有明確的標籤，用以描述資料（例如：「發票」、「付款細節」）。
- 方向：箭頭表示移動的方向。
抽象層級 📉
資料流程圖是層次化的。你不應將所有內容繪製在同一頁上。相反地，你應將系統分解為細節逐漸增加的層級。這讓利害關係人能先看到整體概況，再深入探討細節。
上下文圖（第0層） 🌍
上下文圖是最高層級的視圖。它將系統呈現為一個單一流程（通常稱為「系統」或「企業」），並顯示其與所有外部實體的互動。它定義了專案的邊界。
- 重點：邊界與外部介面。
- <細節：不顯示內部流程或資料儲存庫。
第1層圖 📋
第1層圖將上下文圖中的單一流程分解為主要的子流程。它顯示主要的資料儲存庫，以及資料在這些主要功能之間如何流動。
- 重點：系統的主要功能區域。
- 細節： 展示系統在邏輯上的組織方式。
第二層圖示（及以下）🔍
第二層圖示會將第一層中的單一流程進一步分解。此層通常用於技術團隊理解特定邏輯。對於業務分析師而言，當定義複雜模組的詳細需求時，此層非常有用。
- 重點：特定的子流程。
- 細節：細緻的資料移動與驗證步驟。
建立資料流程圖：逐步方法🛠️
建立資料流程圖是一個迭代過程。它需要蒐集資訊、建立模型與驗證。遵循此結構化方法可確保準確性。
步驟 1：定義系統邊界🚧
在繪製任何內容之前，先決定系統內部與外部的範圍。這對情境圖至關重要。向利益相關者提問：「我們是為誰打造這個系統？」以及「哪些資料會進入系統，哪些會離開系統？」
步驟 2：識別外部實體👥
列出所有與專案互動的人、部門或系統。除非內部使用者扮演獨立系統的角色，否則不要包含他們。例如，若經理批准一項請求，則經理是外部實體，但「核准流程」則屬於系統內部。
步驟 3：繪製主要流程🔄
識別系統必須執行的關鍵動作。使用動詞-名詞短語命名（例如「處理付款」，而非「付款」）。確保每個流程都有資料流入與流出。
步驟 4：連結資料流📡
繪製箭頭以連接實體、流程與儲存。確保每個箭頭都標示清楚。若資料從客戶流向系統，標示為「訂單請求」；若資料從系統流向客戶，標示為「收據」。
步驟 5：驗證與平衡⚖️
這是最重要的一步。輸入與輸出平衡必須在各層之間維持平衡。若第一層流程接收「訂單詳情」，則該流程的第二層分解也必須接收「訂單詳情」（或其部分）作為輸入。這稱為資料守恆。
資料流程圖與流程圖的差異：了解其區別🔄
人們常將資料流程圖與流程圖混淆。雖然兩者都是圖表，但用途不同。了解其差異可避免建模錯誤。
| 功能 | 資料流程圖（DFD） | 流程圖 |
|---|---|---|
| 重點 | 資料流 | 控制流／邏輯 |
| 邏輯 | 不顯示決策點 | 顯示決策點（是/否） |
| 實體 | 外部來源/目的地 | 起點/終點 |
| 最適合用於 | 系統分析、需求 | 演算法設計、程式碼 |
| 狀態變更 | 資料被轉換 | 流程被執行 |
常見陷阱，應避免 ⚠️
即使是經驗豐富的分析師，在建模資料流程時也可能出錯。請留意這些常見錯誤。
- 懸空資料流程： 一條指向 nowhere 的箭頭。每條線都必須連接兩個元件。
- 黑洞： 有輸入但無輸出的流程。資料不能消失。
- 重力拉扯： 有輸出但無輸入的流程。資料不能憑空出現。
- 資料儲存混淆： 將資料儲存視為流程。儲存器僅用來存放資料；它不會改變資料。若資料需要改變，必須先經過流程。
- DFD 中的控制流程： 不要使用 DFD 來顯示決策邏輯（如果/那麼）。應使用流程圖。DFD 的重點在於資料移動。
- 過度複雜化： 在一級圖中嘗試加入過多細節。保持高階圖的高階性。
業務分析師的最佳實務 ✅
為了從您的 DFD 中獲得最大價值，請遵循這些原則。
1. 使用一致的命名 🏷️
在所有圖表中對資料流程使用相同的術語。如果在上下文圖中稱為「客戶編號」，就不應在一級圖中改為「客戶編號」。一致性可減少審查時的混淆。
2. 限制每張圖的流程數量 📐
一個好的經驗法則是，在單一的第1級圖表中，流程數量不要超過7到9個。如果超過這個數量，應考慮將系統拆分成子系統。這樣可以保持圖表的可讀性。
3. 關注邏輯層面，而非物理層面 🧠
邏輯資料流程圖顯示業務如何運作，與技術無關。物理資料流程圖則顯示系統如何使用特定硬體或軟體運作。應從邏輯層面開始。在邏輯模型中，不要提及資料庫或伺服器。
4. 尽早讓利害關係人參與 🤝
繪製圖表並與利害關係人一起走查。請他們追蹤特定的交易流程。「如果我下訂單，錢會去哪裡？」這種驗證能確保模型符合現實情況。
5. 保持版本控制 📅
需求會變動，資料流程圖也必須隨之演進。務必追蹤版本。當某個流程變更時，應更新圖表並記錄變更內容。這能為系統的演進建立審計軌跡。
與需求工程的整合 📝
資料流程圖並非孤立存在。它與您的需求規格文件（RSD）緊密相關。以下是對齊它們的方法。
- 可追溯性： 資料流程圖中的每個流程都應對應到一個功能需求。如果某個流程沒有對應的需求，就應質疑其必要性。
- 非功能需求： 資料流程圖有助於識別性能需求。例如，如果某個流程需要來自遠端資料庫的資料，延遲可能成為關注點。
- 驗證： 利用資料流程圖驗證業務所需的所有資料是否都已納入考量。如果需要產生報表，請確保資料能流入支援該報表的資料儲存或流程中。
驗證與審查 🔍
圖表繪製完成後，必須經過正式審查。這不僅是視覺上的檢查，更是一次邏輯上的審查。
走查法
進行一次走查會議。選擇一個特定的資料項目，例如「銷售訂單」。從外部實體開始，追蹤該資料經過每一道流程與資料儲存，直到抵達最終目的地。這條路徑是否合理？在每個階段資料是否完整？
資料守恆檢查
確認資料是守恆的。如果某個流程輸出「寄送地址」，則輸入必須包含「地址」資訊。若資料消失，表示模型不完整。
分解檢查
確保第2級圖表是第1級圖表的真正分解。父流程的輸入與輸出，必須等於子流程輸入與輸出的總和。
案例研究：線上零售系統 🛒
舉例來說，考慮一個線上零售系統。上下文圖會顯示「顧客」送出「訂單」並收到「發票」，而「倉庫」則送出「庫存可用性」。
在第1級圖表中，系統被分解為「接收訂單」、「處理付款」、「更新庫存」和「發貨」。其中「顧客資料庫」與「庫存資料庫」作為資料儲存。
這種結構有助於業務分析師識別出「處理付款」需要來自「接收訂單」的資料，且必須更新「庫存資料庫」。同時也突顯出「倉庫」是外部實體，表示系統必須與其庫存系統進行介接。
維護與演進 🔄
系統是活的實體。隨著業務成長，資料流程圖也必須隨之改變。資料流程圖不是一次性的交付成果。
- 變更管理： 新增功能時，請先更新資料流程圖。這有助於識別下游影響。
- 重構： 如果一個流程變得過於複雜，請將其分解。如果兩個流程很少一起使用，則考慮將它們合併。
- 文件記錄： 將資料流程圖與需求一同保存。它可作為文件的視覺索引。
視覺化模型總結 🎯
資料流程圖不僅僅是技術圖繪；它是一種商業邏輯的語言。它能將抽象的需求轉化為具體的視覺路徑。透過遵循層次、一致性與驗證的原則，商業分析師可以建立推動系統成功實施的模型。
目標不是第一稿的完美，而是溝通的清晰。無論圖中包含多少箭頭，只要能引發討論並揭示遺漏的需求，就是一張成功的圖表。專注於資料，尊重流程，讓圖表引導你的分析。
透過練習，繪製這些圖表將自然成為你分析工具箱的一部分。它們仍然是確保最終系統確實支援其設計所要服務的商業需求的最可靠方法之一。