Glossary of DFD Terms and Relationships
Never assume that a term is self-explanatory. Misunderstanding a single word—like “process” or “data store”—can derail an entire model. I’ve seen teams waste weeks on a misaligned diagram simply because “data flow” was interpreted differently across stakeholders. The fix? Anchor every term to a shared definition.
This glossary is built from over two decades of modeling systems from healthcare to finance, where consistency wasn’t just ideal—it was non-negotiable. You’ll find precise, field-tested definitions that clarify ambiguity and align with DFD standards. Each term includes context, usage, and why it matters in balancing and leveling. Use this as your go-to reference.
Core DFD Elements
Process
Represents a transformation or computation that alters data. It takes input, performs an operation, and produces output.
Not a program or function—it’s a logical action. For example, “validate customer login” is a process, not a code block.
Key rule: Every process must have at least one input and one output. If it has neither, it’s not a valid process.
External Entity
An actor outside the system boundary that sends or receives data flows. Also called a “source” or “sink.”
Examples: Customer, Bank, Government Agency.
Always label with a noun and avoid verbs. “Customer” is correct; “Submitting Application” is misleading—use “Customer” with a clear data flow like “Submits Application”.
Data Flow
Represents the movement of data between processes, data stores, or external entities. It’s not a physical transfer—it’s a logical description of data being passed.
Use clear, action-oriented labels: “Customer Order Details” or “Payment Confirmation.”
Never describe the data itself. “Send data” is vague. “Transmit Invoice to Accounting” is precise.
Data Store
Represents a place where data is held for later use. It is not a database or file system—it’s a conceptual container.
Example: “Customer Records” or “Pending Orders.”
Must be referenced by at least one process. If a data store is not accessed, it’s redundant.
Structural and Relational Concepts
System Boundary
Defines the scope of the system being modeled. Everything inside is part of the system; everything outside is external.
Drawn as a rectangle or box around the primary processes. It’s the first line of defense against scope creep.
Ask: “Does this flow cross the boundary? If yes, it must be labeled and accounted for.”
Leveling
The process of decomposing a high-level DFD into increasingly detailed levels (e.g., Level 0 → Level 1 → Level 2).
Each level adds detail while preserving the parent’s context. Level 0 is the context diagram; Level 1 shows high-level processes.
Never skip levels. Each decomposition must be traceable and logically consistent.
Decomposition
The act of breaking down a complex process into smaller, manageable sub-processes.
Use the “What happens next?” question: “After receiving an order, what does the system do?” Split actions until each sub-process is atomic.
Rule of thumb: If a process can be split further without changing the data flow, it’s not fully decomposed.
Atomic Process
A process that cannot be meaningfully decomposed further. It’s the smallest unit of functional activity.
It must have inputs, outputs, and a clear transformation. There is no internal data flow.
Example: “Calculate tax” is atomic. “Process order” is not—it can be broken into “Validate,” “Confirm,” “Send to Billing.”
Validation and Consistency
DFD Balancing
The principle that data flows in and out of each level must match across parent and child diagrams.
Every flow into a process in a child diagram must have a corresponding flow in the parent. Same for outputs.
If you see “Customer Order” in Level 1 but “Customer Order Submission” in Level 2, you’ve violated balancing.
Consistency Across Levels
Meaning and labeling must remain stable between levels. A change in terminology breaks traceability.
Use a data dictionary. If “Customer Order” is defined as “a record of products ordered by a customer,” that definition must apply at all levels.
Don’t rename terms for “clarity.” Rename only when necessary—and update the dictionary.
Data Dictionary
A formal list of all data elements used in the DFD, including name, definition, aliases, and source.
Not optional. It’s your truth layer. Without it, even a balanced DFD can be misinterpreted.
Example entry:
- Name: Customer Order
- Definition: A record containing customer ID, order date, list of items, and total amount.
- Source: Customer, Order Entry System
Traceability
The ability to link a DFD element back to its source—whether a requirement, user story, or business rule.
Use reference IDs: “Req-004” or “User Story #123.” This ensures auditing and impact analysis.
Without traceability, your model becomes a black box. Balancing becomes guesswork.
Key Relationships and Patterns
Input-Output Relationship
A fundamental principle: every process must have both input and output data flows.
Missing an input? The process lacks context. Missing output? It does nothing.
Even a “validation” process must output “Validated Data” or “Error Message.”
Flow Containment
Ensures that no data flow leaves the system without being accounted for in the external entity.
Example: If “Payment Confirmation” flows to “Bank,” the bank must be an external entity with a receiving flow.
Never allow unaccounted flows. They indicate boundary or scope errors.
Looping Flow
A data flow that returns to the same process. It’s allowed—but only if it represents a state change or delayed processing.
Example: “Recheck Validation” loop in a fraud detection process.
Use looping flows cautiously. They can suggest poor process design or missing data store.
Common Pitfalls and Fixes
Over-Decomposition
Breaking down processes too far—into steps that aren’t meaningful in isolation.
Fix: Ensure each sub-process has a clear function. If it’s just “do step 1 of 5,” it’s not atomic.
Under-Decomposition
Leaving too much complexity in a single process.
Fix: Ask: “Can this process be split to improve clarity or maintainability?” If yes, decompose.
Missing Data Store
When data is stored but not represented in the DFD.
Fix: If data is retained across time (e.g., past orders), it must be in a data store. Don’t assume it’s implicit.
Data Flow Definitions at a Glance
| Term | Definition | Example |
|---|---|---|
| Process | Transforms input data into output data. | Calculate total invoice |
| Data Flow | Logical movement of data between elements. | Send Invoice to Customer |
| Data Store | Logical container for data not actively in motion. | Order History Database |
| External Entity | Actor outside system boundary sending or receiving data. | Payment Gateway |
| System Boundary | Defines scope of the system. | Box around core processes |
Frequently Asked Questions
What is the purpose of a DFD glossary?
To eliminate ambiguity. Without a shared understanding of terms like “data flow,” “process,” or “data store,” models become inconsistent and unverifiable.
How do I ensure data flow definitions are consistent across levels?
Use a data dictionary. Define every data element once. Use the same name and meaning at every level. Never rename “Customer Order” to “Order Entry” unless you update the dictionary.
Can I use synonyms in different DFD levels?
No. Synonyms create inconsistency. If you use “Order” in Level 1 and “Purchase” in Level 2, they must refer to the same data. Use a master list to enforce naming standards.
Why is DFD balancing so critical?
It ensures that the model reflects reality. If a flow appears in a child diagram but not the parent, you’re modeling something outside the system’s scope—or missing a vital connection.
How often should I update the DFD glossary?
Every time a term is added, changed, or removed. It’s not a one-time task—it’s a living reference. Update it when you revise any level.
What’s the difference between a data flow and a data store?
A data flow is movement. A data store is storage. A flow “moves” data from one place to another. A store “holds” data over time. Think of data flow as a river, and data store as a lake.
