Data Flow Diagrams (DFDs) are graphical representations that model how data moves through a system. They are fundamental tools in structured systems analysis and design, used to visualize data processes, storage, and flows without specifying technical implementation details.
1. Overview: What Are Data Flow Diagrams?
A Data Flow Diagram is a visual modeling technique that describes:
What data flows through the system
Where data originates and terminates (external entities)
How data is transformed by processes
Where data is stored and retrieved
System boundaries and external interactions
Role in Structured Analysis
DFDs are a cornerstone of structured analysis methodology, enabling:
Business Logic Capture — Document how data moves without implementation details
Process Decomposition — Break complex systems into manageable, hierarchical levels
Stakeholder Communication — Non-technical diagrams facilitate dialogue with business users
Requirement Validation — Ensure all inputs and outputs are accounted for
Impact Analysis — Understand dependencies before changes
Historical Origins
DFDs emerged in the late 1970s and early 1980s through the work of pioneers in structured analysis:
Tom DeMarco — Formalized DFDs in "Structured Analysis and System Specification" (1978)
Ed Yourdon — Co-developed the Yourdon/DeMarco notation (circles for processes)
Chris Gane & Trish Sarson — Created the alternative Gane-Sarson notation (rounded rectangles for processes)
When to Use DFDs
Analyzing information systems and business processes
Designing databases and data architectures
Documenting legacy systems before modernization
Eliciting and validating system requirements
Training new team members on system architecture
Not suitable for real-time systems, control systems, or when detailed algorithmic flow is critical (use UML state diagrams instead)
2. Core Elements of DFDs
Every DFD consists of four fundamental symbols. Below are both major notations side by side:
Yourdon/DeMarco Notation vs. Gane-Sarson Notation
Detailed Symbol Explanations
1. External Entity (Square/Rectangle)
Represents systems, users, or organizations outside your system boundary
Source or sink of data
Examples: Customer, Supplier, Bank, Government Agency
Named with a noun (singular or plural)
Cannot communicate directly with data stores or other external entities
2. Process (Circle or Rounded Rectangle)
Performs transformation on data (input → output)
Labeled with a verb phrase: "Validate Order", "Calculate Fees"
Numbered for reference: 1.0, 1.1, 1.2, etc. (numbering reflects hierarchy)
Has at least one input and one output data flow
Yourdon/DeMarco use circles (◯)
Gane-Sarson use rounded rectangles (╭─┐)
3. Data Store (Parallel Lines)
Represents persistent storage of data (database, file, cache)
Labeled with plural nouns: "Customers", "Orders", "Inventory"
Referenced by D# notation: D1, D2, D3, etc.
Data flows in and out; cannot communicate directly with external entities or other data stores
Symbol: Two parallel lines with label between them
4. Data Flow (Arrow with Label)
Represents movement of named data between elements
Labeled with noun phrases: "Customer Record", "Payment Confirmation"
Direction indicated by arrowhead
Can flow in multiple directions between same elements on different paths
Represents a logical flow of data, not physical transport
3. DFD Levels and Hierarchical Decomposition
DFDs are hierarchical, allowing progressive refinement from high-level context to detailed processes:
Level 0: Context Diagram
The entire system is represented as one single process. Shows:
System boundary (the process bubble)
All external entities
Data flows between system and external entities
No internal detail
Level 1: Major Processes
The Level 0 process is decomposed into 5-7 major processes, each with:
Refined data flows
Introduction of data stores
Data flows between processes
External entities still present at system boundary
Level 2+: Detailed Decomposition
Individual Level 1 processes are further decomposed to show implementation details. Can continue to Level 3, 4, etc., though rarely beyond Level 2-3 due to complexity.
Balancing Rule (Critical)
When a process is decomposed, the data flows into and out of that process at the parent level must match exactly the flows at the child level. This ensures logical consistency.
4. Example: Order Management System (All Three Levels)
Level 0: Context Diagram
Level 1: Major Processes
Level 2: Decompose Process 1.4 (Process Payment)
5. Rules and Conventions
Mandatory Rules
Rule 1: Conservation of Data — Each process must have at least one input and one output. Data cannot be created or destroyed.
Rule 2: Data Stores Cannot Communicate — Data stores can only interact via processes. Direct connections between data stores are forbidden.
Rule 3: External Entities Cannot Communicate Directly — External entities interact only with processes, not with data stores or other external entities.
Rule 4: Balancing — When decomposing a process from level N to N+1, the input/output flows must be conserved (in = in, out = out).
Rule 5: No Self-Flows — A data flow cannot start and end at the same element without passing through at least one other element (avoid loops within a single level).
Naming Conventions
Element
Naming Style
Examples
Process
Verb + Object
Validate Customer, Calculate Fees, Submit Order
Data Flow
Noun phrase (what data)
Customer Record, Payment Confirmation, Order Details
Which process or external entity produces this data
Destination
Which processes or data stores consume this data
Owner
Department or person responsible for data quality
Notes
Implementation notes, business rules, examples
Example Data Dictionary Entries
========================================================================
DATA ELEMENT: Order_ID
========================================================================
Alias: Order Number, Order Identifier
Data Type: Integer (Long)
Length: 11 digits
Constraints: NOT NULL, PRIMARY KEY, UNIQUE, > 0
Description: Unique system-generated identifier for an order
Source: External Entity: Customer
Destination: Process 1.0, D1 (Orders), D2 (Audit Log)
Owner: Sales Department
Format Example: 12345678901
Notes: Auto-incremented, never reused even if order canceled
========================================================================
DATA ELEMENT: Customer_Record
========================================================================
Alias: Customer Info, Customer Profile
Data Type: Composite/Record (multiple fields)
Composition: { CustomerID, Name, Email, Address, Phone }
Constraints: NOT NULL (for all sub-fields)
Description: Complete customer information
Source: External Entity: Customer or Process 1.1
Destination: Process 1.1, Process 1.3, D2 (Customers)
Owner: Customer Service Department
Sub-fields:
- CustomerID: Integer, 8 digits, PK
- Name: String, max 100 chars, not null
- Email: String, max 255 chars, unique, email format
- Address: String, max 500 chars
- Phone: String, 10-15 digits, format: +1-234-567-8900
Notes: Validated against CRM before use
========================================================================
DATA ELEMENT: Payment_Confirmation
========================================================================
Alias: Transaction Receipt, Payment Auth Code
Data Type: String
Length: 32 characters (hex-encoded)
Constraints: NOT NULL, UNIQUE, non-empty
Description: Bank-issued authorization code for approved payment
Source: External Entity: Bank (Process 1.3)
Destination: Process 1.4, D4 (Payments)
Owner: Finance Department
Format Example: AB12CD34EF56GH78IJ90KL12MN34OP56
Notes: Must be received within 30 seconds of payment
submission; retry logic after timeout
========================================================================
DATA ELEMENT: Inventory_Status
========================================================================
Alias: Stock Level, Available Quantity
Data Type: Integer
Length: 8 digits
Constraints: >= 0, NOT NULL
Description: Current count of items available for sale
Source: D3 (Inventory), Process 1.2
Destination: Process 1.2, Process 1.4, D3 (Inventory)
Owner: Warehouse Management
Format Example: 456 units
Notes: Updated in real-time via Process 1.4;
negative values trigger auto-reorder
10. DFD vs. Other Diagram Types
Different diagrams serve different purposes in systems analysis and design:
Diagram Type
Focus
When to Use
Comparison to DFD
DFD (Data Flow Diagram)
Data movement, transformation, storage
Analyze business processes, design database systems, document legacy systems
Primary tool — Shows WHAT data flows and WHERE, not HOW or WHEN
Use Case Diagram
System interactions, user roles, functional requirements
Define system boundaries, capture user interactions, elicit use cases
Complements DFD — Shows WHO uses WHAT functionality; DFD shows data inside those use cases
Activity Diagram
Process flow, decision points, control flow
Model business workflows, sequential/parallel activities, swimlanes for roles
Different abstraction — Shows WHEN and ORDER of activities; DFD shows data dependencies
BPMN (Business Process Model & Notation)
Business process execution, timing, resource allocation
Model executable processes, integrate with workflow engines, document compliance
More detailed than DFD — Includes timers, exceptions, events; DFD is simpler and more abstract
Entity-Relationship Diagram (ERD)
Data structure, entities, relationships, cardinality
Design databases, define schema, document data models
Complements DFD — Shows structure of D1, D2, D3, etc. defined in DFD
Sequence Diagram
Message passing, object interaction, timing
Document message sequences between objects/systems, design API contracts
More technical — Shows specific method calls; DFD shows logical data movement
State Diagram
State transitions, events, conditions
Model real-time systems, device behavior, protocol logic
Different purpose — Not suitable for data-centric systems; better for control systems
How to Choose
DFD + ERD + Use Case → Classic structured analysis for business systems
DFD + Activity Diagram → Understand data flow within business workflows
Use Case + Activity Diagram + Sequence → UML approach, common in OOP systems
BPMN alone → Process automation, compliance documentation
ERD alone → Pure database design without process context
Limit processes per level to 5-7 for readability; use decomposition to manage complexity
Number sequentially left-to-right or top-to-bottom to follow reading direction
Never reuse a number — each process has a unique path
Validation and Balancing
Validate conservation of data — Every process has inputs and outputs; no spontaneous generation or destruction
Balance between levels — Parent process' input/output data flows must exactly match the sum of child-level flows
Check for orphaned processes — No isolated processes with no connections
Verify data store usage — All reads/writes are through processes, never directly between data stores
Data Dictionary Accuracy
Document all data elements appearing on any flow or in any data store
Specify types and constraints — No ambiguity about format, length, null-ability
Link sources and destinations — Every element must have defined producer(s) and consumer(s)
Review with stakeholders — Data dictionary is the contract between analysts and developers
Stakeholder Review
Present to business users first — Verify processes match business logic before detailing
Use plain language labels — "Validate Customer" not "Func_ValidateCustomer"
Walk through scenarios — Trace a sample transaction through all levels
Document assumptions — Capture any interpretations or deviations from expected behavior
Common Mistakes to Avoid
Mistake
Consequence
How to Avoid
Missing or incomplete data stores
Data appears without source; inconsistent system state
Ask "where is this data retrieved from?" for every flow
One-way data flows (no input or output)
Process cannot function; violates conservation rule
Every process needs input AND output; verify both
Direct communication between data stores
Violates DFD rules; unclear how data moves
All data store interactions MUST go through a process
External entities communicating directly
System boundary becomes blurred; data flow outside system
External entities only connect to system (processes), never to each other
Unbalanced decomposition
Parent and child levels have different inputs/outputs; inconsistency
When decomposing, ensure IN and OUT flows are preserved
Vague process names
Unclear what transformation occurs; hard to implement
Use verb+object: "Calculate Fees", "Validate Customer" (not "Process Data")
No data dictionary
Developers must guess data formats; errors and inconsistencies
Always create and maintain a data dictionary alongside DFD
Too many processes on one level (10+)
Diagram becomes unreadable; hard to understand relationships
Decompose further; aim for 5-7 per level maximum
Summary
Data Flow Diagrams are a powerful tool for understanding and documenting how systems handle data. They abstract away implementation details to focus on the logical flow of information. By following the rules (conservation of data, no direct store-to-store communication, balancing across levels) and combining DFDs with data dictionaries, stakeholder reviews, and supporting diagrams (ERDs, use cases, activity diagrams), you can create clear, maintainable documentation that bridges the gap between business requirements and technical implementation.
Key Takeaways:
DFDs model what data flows where, not when or how
Use hierarchical decomposition (Level 0 → 1 → 2+) to manage complexity
Always include a data dictionary defining every element
Validate balancing and conservation of data between levels
Choose between Yourdon/DeMarco or Gane-Sarson notation consistently
Combine with Use Case diagrams, ERDs, and Activity diagrams for complete analysis
Limit 5-7 processes per level; avoid common mistakes (missing stores, one-way flows, unbalanced decomposition)