Visual Paradigm Desktop | 
Visual Paradigm Online
建立資料流程圖（DFD）是系統分析中的重要里程碑。它描繪了資料在系統中的流動，定義資訊如何被處理、儲存與傳輸。然而，一個視覺上吸引人的圖表未必在功能上正確。驗證是關鍵階段，您需確認圖表正確反映系統需求，且無邏輯錯誤。此過程確保資料流一致、處理程序平衡，且結構能支援預期的商業邏輯。
驗證並非單一動作，而是一種有紀律的審查。它需要有系統的方法，將每個元素與既定規則逐一核對。透過遵循結構化的審查流程，可消除模糊性，確保圖表能作為開發與利害關係人溝通的可靠藍圖。本指南概述了有效驗證您DFD所需的全面步驟，確保系統設計全程的準確性與一致性。
在深入具體步驟之前，理解驗證在系統設計脈絡中所達成的目標至關重要。驗證問的是：『我們是否正確地建構產品？』而驗證則問：『我們是否在建構正確的產品？』在DFD的脈絡中，驗證彌補了抽象需求與具體系統行為之間的差距。
經過驗證的DFD可確保：
跳過此階段通常會導致開發階段產生高昂的返工成本。例如資料流遺漏或未定義的資料儲存等問題，一旦程式碼開始撰寫，修復成本將極高。嚴謹的審查流程可及早降低這些風險。
在開始正式審查前，請確保圖表已準備妥當以接受檢視。雜亂或組織不良的圖表會使驗證變得困難。請使用以下清單來準備您的工作：
情境圖是抽象層級最高的圖表。它將系統呈現為單一流程，並顯示其與外部實體的互動。這是驗證的第一道防線。
外部實體代表系統邊界以外的資料來源或目的地。確保顯示的每個實體都是必要且明確定義的。請提出以下問題：
代表系統的單一流程必須包含所有內部邏輯。確認沒有任何資料流在未經過此流程的情況下跨越邊界。如果資料從一個外部實體直接移動到另一個外部實體而未進入系統，則不應在上下文圖中顯示，因為這超出範圍。
檢視與中央流程相連的每一條箭頭。每個輸入都必須有對應的輸出或儲存動作。如果資料流進入系統但沒有資料離開，可能表示存在一個「黑洞」流程，資料無故消失。
Level 0 DFD 將上下文圖中的單一流程分解為主要子系統。此處最重要的規則是平衡。父流程的輸入與輸出必須與子流程的輸入與輸出完全一致。
對於每一個進入上下文圖流程的資料流，都必須有對應的資料流進入 Level 0 圖。輸出亦同。這稱為資料守恆。如果上下文圖顯示「客戶訂單」進入系統，Level 0 圖必須顯示「客戶訂單」進入至少一個主要流程。
Level 0 通常包含 3 到 7 個流程。如果超過 7 個，圖表可能過於複雜，無法單一視圖呈現。如果少於 3 個，可能需要進一步分解。確保每個流程都明確區分，並執行單一邏輯功能。
檢查 Level 0 中的每個資料儲存是否必要。只有當資料需要被保留以供後續使用時，資料儲存才應存在。確保流入和流出儲存的資料流標籤正確。資料儲存不應直接連接到外部實體；所有資料都必須經過流程。
Level N 圖表為 Level 0 中識別的特定流程提供進一步細節。此層級的驗證重點在於與父流程的一致性。
與 Level 0 相同，父流程的輸入與輸出必須與其子流程的總輸入與總輸出匹配。如果在 Level 0 圖中 Process 1.0 接收「登入資料」並輸出「存取權杖」，則 Process 1.0 的 Level 1 分解也必須接收「登入資料」並產生「存取權杖」。
確保分解是邏輯合理的。子圖是否解釋了如何父流程是如何運作的？避免在子圖中引入父圖未暗示的新外部實體或資料儲存。若引入新的資料儲存，必須有保留資料的需求作為合理依據。
子圖中資料流的標籤必須與父圖中的標籤一致（適用時）。如果在子圖中對資料流進行細化（例如「資料」變為「使用者資料」），此變更應與資料字典一致。此處的模糊性會在實作時造成混淆。
存在特定的結構異常，顯示 DFD 設計中的錯誤。這些常見模式必須在驗證期間被識別並修正。
黑洞流程是指具有輸入但無輸出的流程。資料進入流程後便消失不見。這通常表示缺少輸出流或流程定義不完整。每個流程都必須產生某種結果，無論是需要儲存的資料、需要發送到其他地方的資料，還是決策結果。
奇蹟流程是指具有輸出但無輸入的流程。它從無中創造資料。這在系統設計中在邏輯上是不可能的。每個輸出都必須來自輸入資料，或從儲存的資料中推導出來。
當輸入與輸出在邏輯上不匹配時，就會出現灰洞。例如，如果輸入是「客戶地址」，而輸出是「付款詳情」，則該流程不僅僅是轉換，還在創造無法從輸入推導出的資料。這表明可能存在缺失的資料流或缺失的資料儲存。
確保資料流不會直接從外部實體流向資料儲存。所有進入或離開儲存的資料都必須經過流程。這可確保在儲存前應用資料完整性規則和業務邏輯。
在審查過程中可將此表格作為快速參考。它總結了關鍵規則以及每個元素所需的特定檢查。
| 元素 | 驗證規則 | 常見錯誤 |
|---|---|---|
| 流程 | 至少必須有一個輸入和一個輸出 | 黑洞或奇蹟流程 |
| 資料儲存 | 必須連接到流程，而非實體 | 實體直接流向儲存 |
| 資料流 | 必須使用名詞片語標記 | 動詞標籤或遺漏標籤 |
| 外部實體 | 必須位於系統邊界之外 | 實體位於系統邊界內 |
| 一致性 | 父級與子級的輸入/輸出必須一致 | 資料流不平衡 |
| 分解 | 子流程必須解釋「如何」，而非「為何」 | 添加不在範圍內的邏輯 |
驗證不僅僅是技術檢查；它是一種溝通工具。技術規則滿足後，必須由利益相關者審查圖表，以確保其符合業務需求。
不要孤立地展示圖表。準備一個導覽，解釋資料流動的過程。提供某些資料儲存位置存在的原因以及流程之間如何互動的背景資訊。確保所有利益相關者都能存取資料字典以理解術語。
鼓勵利益相關者質疑資料流動。提出具體問題，例如：
記錄所有反饋和建議的變更。如果利益相關者建議新增資料流，請在接受前根據平衡規則進行驗證。同時更新圖表和資料字典以保持同步。版本控制至關重要；在每次審查週期中保留圖表狀態的記錄。
驗證很少是一次性的事件。隨著需求的演變，資料流程圖（DFD）也必須隨之演變。本節介紹如何在專案生命周期中管理變更。
當有變更請求時，分析其對整個層級結構的影響。如果一級流程發生變更，是否會影響零級？是否需要新增資料儲存？是否會影響共享相同資料流的其他流程？進行此影響分析可防止連鎖錯誤。
維持圖表修訂的清晰歷史記錄。使用版本號碼（例如 v1.0、v1.1）和修訂日期。這使團隊能夠追蹤系統設計的成熟過程，並在必要時回退變更。雖然不需要特定工具，但檔案命名規則必須嚴謹。
實施變更後，再次執行驗證流程。不要假設微小變更能維持整體完整性。重新檢查平衡規則、命名慣例和結構完整性。有時一個微小的新增項目可能會破壞先前已驗證圖表的平衡。
資料字典是您資料流程圖（DFD）的骨幹。它定義了每個資料元素的結構。驗證必須超越視覺圖表，延伸至文字定義。
確保圖表上的資料流標籤與字典條目完全一致。如果圖表顯示「發票編號」，而字典顯示「發票識別碼」，這種不一致可能在資料庫設計過程中造成混淆。應在所有文件中統一術語。
檢查每個資料儲存是否在字典中具有明確定義的結構。列出屬性、資料類型和關鍵約束。如果資料儲存在 DFD 中被引用，但字典中無對應條目，則設計不完整。此類缺口通常會導致後續資料庫錯誤。
驗證圖表中隱含的資料類型是否符合業務規則。例如，若資料流代表「出生日期」，則在字典中不應視為文字字串，而應具有日期格式。這種細節層面可確保技術實現與概念設計一致。
即使經驗豐富的分析師在驗證過程中也會遇到特定陷阱。了解這些常見陷阱有助於您更有效地應對審查。
驗證完成後，文件必須最終定稿，以便移交給開發團隊。這包括整合圖表、資料字典和驗證報告。
將所有 Level 0 圖表、Level N 圖表和上下文圖整合成一個單一包。確保層級關係明確標示，以便開發人員能追蹤分解過程。將資料字典作為附屬文件一併包含。
建立驗證過程的摘要報告。列出審查期間發現的任何問題及其解決方式。此文件作為設計已通過審核的證據。同時也為未來可能未參與最初審查的維護人員提供背景資訊。
定義移交已驗證 DFD 的流程。這應包括一場向開發團隊說明設計的會議。解決有關模糊資料流或複雜資料儲存的任何疑問。確保團隊理解 DFD 是資料需求的唯一真實來源。
工作並非在驗證後就結束。隨著系統的演進，圖表必須保持準確。應建立未來變更的治理流程。
透過遵循這些驗證步驟，可確保您的資料流程圖在系統生命週期中始終具備強韌性、準確性與實用性。這種紀律能減少模糊性，防止高昂錯誤，並為成功的系統開發奠定穩固基礎。