In three different banking system projects last year, I found the same issue: a Level 1 process showed a data flow in, but the corresponding Level 2 diagram had no incoming flow from the parent. The root cause? A failure to validate DFD balance. This isn\u2019t just a technical oversight\u2014it\u2019s a breakdown in system integrity.<\/p>\n
As someone who\u2019s built and audited DFDs for over two decades, I\u2019ve learned that balancing isn\u2019t a one-time task. It\u2019s a continuous discipline. The most common mistake? Assuming consistency happens automatically when you decompose a process.<\/p>\n
This chapter gives you a clear, field-tested method to check DFD consistency across levels. You\u2019ll learn how to inspect inputs and outputs systematically, using real-world patterns and a step-by-step checklist. This is not theory\u2014it\u2019s what works in actual projects.<\/p>\n
Start by placing the parent diagram and its child diagram adjacent to each other. Use a digital tool or large paper layout to ensure visibility.<\/p>\n
Focus on the process being decomposed. Every input and output in the parent must either appear directly in the child, or be accounted for through other flows.<\/p>\n
This is the foundation. If you skip this step, you risk missing a flow that\u2019s embedded in multiple child processes.<\/p>\n
Write down all incoming and outgoing data flows from the parent process. Be precise: use the same data names as in your data dictionary.<\/p>\n
For example, if the parent process \u00abProcess Payment\u00bb takes in \u00abPayment Request\u00bb and outputs \u00abPayment Confirmation,\u00bb list each exactly as defined.<\/p>\n
Do not assume that a flow like \u00abPayment Details\u00bb is the same as \u00abPayment Request.\u00bb If they\u2019re not in your data dictionary, you\u2019re working with ambiguity\u2014this is where validation fails.<\/p>\n
Now go through each flow listed in the parent. Check whether it appears in the child diagram.<\/p>\n
If the flow is incoming, ensure it either:\n <\/p>\n
If the flow is outgoing, confirm it:\n <\/p>\n
Remember: a flow can be split across multiple processes. But if the parent shows \u00abPayment Confirmation\u00bb as an output, the child must show how it\u2019s produced.<\/p>\n
Use a table to summarize your findings. This makes discrepancies easy to spot.<\/p>\n
| Data Flow<\/th>\n | Parent Level<\/th>\n | Child Level: Present?<\/th>\n | Status<\/th>\n<\/tr>\n |
|---|---|---|---|
| Payment Request<\/td>\n | Input<\/td>\n | Yes, from Customer<\/td>\n | Valid<\/td>\n<\/tr>\n |
| Payment Confirmation<\/td>\n | Output<\/td>\n | No direct flow<\/td>\n | Invalid<\/td>\n<\/tr>\n |
| Transaction Log<\/td>\n | Output<\/td>\n | Yes, stored in Data Store<\/td>\n | Valid<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Any \u00abNo\u00bb or \u00abNot found\u00bb indicates a gap. This is a red flag in your DFD validation process.<\/p>\n Common Flow Mismatches to Watch For<\/h3>\nDiscrepancies often stem from subtle mismatches. Be alert to:\n <\/p>\n
|