資料流程圖（DFD）作為系統邏輯的藍圖，用以說明資訊如何在流程中流動。它們是系統分析與設計中的關鍵成果，彌補了商業需求與技術實現之間的差距。然而，未經驗證的圖表僅僅是一張草圖。為確保架構的完整性，每個DFD都必須經過嚴格的審查。
本指南提供了一套全面的框架，用於驗證資料流程圖。它著重於結構的一致性、邏輯的正確性，以及與商業規則的契合度。透過遵循此檢查清單，分析師可在開發週期後期避免昂貴的返工。
📋 驗證前準備
在檢視圖表的視覺元素之前，必須先建立上下文。驗證不能在真空狀態下進行。以下先決條件可確保審查過程有效。
- 定義系統邊界：明確識別系統內部與外部的內容。外部實體（來源與終點）必須明確定義。
- 收集需求：確保功能性和非功能性需求皆可取得。圖表必須直接對應到這些規格。
- 建立標準：就符號標準達成共識（例如：Gane & Sarson 與 Yourdon & Coad 之間的差異）。混合使用符號會造成歧義。
- 檢閱資料字典：確保存在資料元素的主清單。若資料定義遺漏，DFD 就無法成立。
🔄 層次結構與分解
DFD 具有層次結構。它從情境圖開始，分解為第 0 層、第 1 層，以及更深入的層級。驗證需要檢查這些層級之間的關係。
1. 情境圖驗證
情境圖（第 -1 層）將系統視為單一流程。在審查更深入的層級之前，必須確保其準確性。
- 單一流程節點：確認僅存在一個代表整個系統的流程。
- 外部實體：確認所有外部來源與目的地皆存在。遺漏的實體表示遺漏的資料流。
- 資料流：確保系統的所有輸入與輸出皆被捕捉。禁止資料的自發性產生或消滅。
2. 第 0 層與分解
第 0 層將單一流程分解為主要的子流程。這正是複雜性開始的地方。
- 流程數量：將流程數量限制在可管理的範圍內（通常為 5 到 9 個）。流程過多會讓讀者混淆。
- 流程名稱：名稱應具備動作導向（動詞＋名詞），例如「計算發票」而非僅「發票」。
- 資料儲存： 確定資料在此層級中儲存的位置。確保資料儲存庫不會直接連接到外部實體，而中間沒有處理程序。
⚖️ 平衡規則
DFD 建立中最常見的錯誤之一是違反平衡規則。此規則規定，父處理程序的輸入和輸出必須與其子處理程序的輸入和輸出完全一致。
- 輸入守恆： 如果父處理程序接收「客戶訂單」，子處理程序必須共同接收「客戶訂單」。子層級中不得出現父層級中不存在的新輸入。
- 輸出守恆： 如果父處理程序發送「發票」，子處理程序必須共同發送「發票」。輸出不得意外消失或出現。
- 流程驗證： 追蹤進入父處理程序的每一條線。追蹤離開父處理程序的每一條線。確認它們在子圖中存在。
- 儲存一致性： 如果在子層級中寫入或讀取資料，則父層級中存取的資料儲存庫必須在子層級中可存取。
未能保持平衡會導致高階視圖與詳細實作之間脫節。這通常導致開發人員建立未納入範圍的功能，或忽略關鍵的資料需求。
🏷️ 命名慣例
命名的一致性對於可讀性和維護至關重要。模糊的名稱會導致對系統行為的誤解。
- 處理程序： 始終使用動詞後接名詞。避免使用單一詞語。正確： 「更新庫存」。錯誤： 「庫存更新」。
- 資料流： 使用單數名詞。正確： 「項目」。錯誤： 「項目們」。
- 資料儲存： 使用複數名詞。正確： 「訂單」。錯誤： 「訂單」。
外部實體： 使用專有名詞或商業術語。正確： 「客戶」。錯誤： 「使用者」。
📊 常見錯誤與驗證風險
即使經驗豐富的分析師也會犯錯。下表概述了常見的違規行為及其對系統架構可能造成的影響。
| 檢查項目 | 驗證標準 | 忽略時的風險 |
|---|---|---|
| 自發性流程 | 每個流程都必須至少有一個輸入流。 | 資料從無中產生，違反系統邏輯。 |
| 黑洞 | 每個流程都必須至少有一個輸出流。 | 資料被消耗卻無結果，顯示邏輯上的缺口。 |
| 灰洞 | 輸入與輸出資料內容必須一致。 | 資料被轉換，但轉換方式未明確定義。 |
| 實體直接連接資料儲存 | 沒有資料流直接將實體連接到資料儲存。 | 跳過了商業規則與驗證邏輯。 |
| 不平衡的流程 | 父流程與子流程必須一致。 | 架構偏移；實作與設計不符。 |
| 控制流程 | 資料流程圖顯示資料，而非控制信號。 | 資料移動與系統觸發之間的混淆。 |
📚 與資料字典的一致性
資料流程圖的品質取決於支援它的資料定義。資料字典是儲存元資料的資料庫，用以定義每個資料流程與資料儲存的結構。
- 資料元素一致性： 檢查資料流程圖中命名的資料元素是否存在於資料字典中。
- 資料結構： 驗證資料流程的組成。 「客戶訂單」是否包含如定義所示的「客戶編號」與「訂單日期」？
- 唯一識別碼： 確保資料儲存中已識別主鍵，以支援資料完整性。
- 別名： 若某資料元素在文件中有多個名稱，應予以標準化，以避免混淆。
- 資料類型： 驗證資料類型（數值、字串、日期）在圖表與資料庫結構之間是否一致。
🤝 利益相關者審查與簽核
技術準確性不夠。圖表必須讓提供需求的業務利益相關者能夠理解。
- 業務術語： 標籤中不要使用技術術語，應使用業務部門使用的語言。
- 走查： 舉行走查會議，讓利益相關者追蹤特定交易的資料流程。
- 缺口分析： 詢問利益相關者，圖表中是否遺漏任何關鍵的業務活動。
- 驗證簽核： 取得正式核准。這確認圖表準確反映了雙方同意的業務邏輯。
🛠️ 維護與版本控制
系統會演進，需求會變更。今日有效的資料流程圖，明天可能就無效了。維護是驗證生命週期的一部分。
- 變更管理： 對流程邏輯的任何變更都必須更新資料流程圖。未更新圖表前，不得更新程式碼。
- 版本控制： 使用版本號碼與日期標示圖表。維護變更歷史，以了解系統的演進過程。
- 連結： 將資料流程圖連結至需求文件。若需求變更，對應的圖形節點必須標示。
- 定期審核： 計畫定期將資料流程圖與實際系統行為進行比對審查。隨著時間推移，會產生偏差。
🔍 詳細的技術一致性檢查
除了通用規則外，還必須遵守特定的技術限制，以確保圖示可準備實作。
1. 資料儲存體完整性
資料儲存體代表持久性儲存。它們不應是暫時性的。
- 讀取/寫入存取： 確認每個寫入儲存體的處理程序，若有必要，也應從該儲存體讀取。若涉及資料修改，確保無處理程序在無讀取需求的情況下寫入儲存體。
- 開放/封閉邊界： 資料儲存體不應具有開放邊界。每個資料儲存體必須至少連接一個處理程序。
- 儲存體命名： 名稱應反映內容，例如「員工檔案」而非「檔案1」。
2. 處理邏輯完整性
處理程序代表轉換邏輯。
- 轉換： 確保處理程序確實改變資料。僅將資料傳遞通過的處理程序屬於資料流，而非處理程序。
- 決策點： 雖然資料流程圖不會像流程圖一樣明確顯示決策邏輯，但必要時資料流標籤應暗示條件（例如「有效訂單」與「無效訂單」）。
- 外部依賴： 若某處理程序依賴外部系統，應以外部實體或子處理程序表示，而非以「神奇盒子」方式呈現。
3. 資料流方向性
箭頭表示資料移動的方向。
- 單一方向： 箭頭必須由來源指向目的地。除非資料流在同一步驟中確實為雙向，否則不得使用雙頭箭頭。
- 標籤清晰度： 每個箭頭都必須有標籤。未標籤的資料流會造成歧義。
- 禁止交叉： 最小化線條交叉。若線條交叉，應使用交叉符號或重新調整佈局以提升可讀性。
🧠 認知負荷降低
一個有效的資料流程圖不僅需要技術上正確；它還必須在認知上易於理解。如果圖表過於複雜，就會失去其主要目的：溝通。
- 模組化：將複雜的流程分解為子流程。如果一個流程的輸入或輸出超過七個，就應進行分解。
- 視覺層次：流程使用一致的形狀，資料儲存使用菱形（依符號系統而定），實體使用矩形。一致性可降低認知負荷。
- 留白：在元素之間留出空間。雜亂的圖表會掩蓋錯誤。
- 色彩編碼：如果工具允許，可使用顏色來區分不同類型的流程（例如輸入與輸出），但必須確保黑白列印後仍可讀。
📝 最後的考量
驗證是一個迭代的過程。很少能在第一次就成功。目標是建立一個穩健、清晰且符合現實的模型。
- 迭代優化：預期需要多次修改圖表。每次修改都應提升清晰度。
- 文件衛生：保持圖表與文件同步。如果文字與圖表內容不一致，系統將會失敗。
- 培訓：確保團隊理解符號的含義。如果審查者不理解符號，檢查清單將毫無用處。
- 工具：使用能強制執行語法規則的建模工具。雖然檢查清單是手動的，但工具可以自動執行如平衡性等基本檢查。
遵循此全面的檢查清單，可確保資料流程圖成為系統的可靠基礎。它們將成為一份活文件，引導開發並驗證業務邏輯。這種紀律能降低風險、改善溝通，並確保最終產品符合預期需求。
請記住，圖表是一種思考工具，而不僅僅是交付成果。驗證圖表的過程迫使分析師面對可能在測試開始前一直隱藏的邏輯漏洞。請花時間徹底驗證。