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.
A Data Flow Diagram is a visual modeling technique that describes:
DFDs are a cornerstone of structured analysis methodology, enabling:
DFDs emerged in the late 1970s and early 1980s through the work of pioneers in structured analysis:
Every DFD consists of four fundamental symbols. Below are both major notations side by side:
YOURDON/DeMarco NOTATION | GANE-SARSON NOTATION
==================================|================================
1. EXTERNAL ENTITY | 1. EXTERNAL ENTITY
(Source/Sink of data) | (Source/Sink of data)
┌─────────────┐ | ┌─────────────┐
│ Customer │ | │ Customer │
│ (Rectangle)│ | │ (Rectangle)│
└─────────────┘ | └─────────────┘
Same in both notations | Same in both notations
|
2. PROCESS | 2. PROCESS
(Transforms data) | (Transforms data)
◯ 1.0 | ╭─────────╮
Validate | │ 1.0 │
Order | │ Validate│
| │ Order │
(Circle) | ╰─────────╯
| (Rounded Rectangle)
|
3. DATA STORE | 3. DATA STORE
(Persistent data) | (Persistent data)
════════════════ | ───────────────
D1 - Customer DB | D1 - Customer DB
════════════════ | ───────────────
(Two parallel lines) | (Two parallel lines, identical)
|
4. DATA FLOW | 4. DATA FLOW
(Movement of data) | (Movement of data)
────→ [Labeled Arrow] | ────→ [Labeled Arrow]
|
Same in both notations | Same in both notations
KEY DIFFERENCES:
• Yourdon/DeMarco: Processes are CIRCLES
• Gane-Sarson: Processes are ROUNDED RECTANGLES
• Both are ISO/IEC standards; use depends on team preference
• Gane-Sarson is slightly more visually distinct
1. External Entity (Square/Rectangle)
2. Process (Circle or Rounded Rectangle)
3. Data Store (Parallel Lines)
4. Data Flow (Arrow with Label)
DFDs are hierarchical, allowing progressive refinement from high-level context to detailed processes:
The entire system is represented as one single process. Shows:
The Level 0 process is decomposed into 5-7 major processes, each with:
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.
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.
┌───────────────────┐
│ Customer │
└────────┬──────────┘
│
Order Request │ Order Confirmation
│ │ ▲
│ │ │
│ ▼ │
┌───────────────────────────────┐
│ │
│ Order Management System │
│ (0.0) │
│ │
└───────────────────────────────┘
│ ▲ │
│ │ ▲
Inventory │ │ │ Payment Status
Update ▼ │ │ │
┌─────────────┐│ ┌──────────────┐
│ Supplier ││ │ Payment Bank│
└─────────────┘│ └──────────────┘
│
Payment Request
┌──────────────────────────────────────────────────────────────┐
│ Customer │
└──────────────┬───────────────────────────────────────────────┘
│
Order Request
│
▼
┌────────────┐
│ 1.0 Process│
│ Order │
└──────┬─────┘
│Order Details
│
┌────────┴────────┐
▼ ▼
┌─────────┐ ┌──────────┐
│ 1.1 Verify│ │ 1.2 Check│
│ Customer │ │Inventory │
└─────┬─────┘ └──────┬───┘
│ │
│ Verified │ Available
│ Customer │ Quantity
│ Info │
└────────┬───────┘
▼
┌──────────────┐
│ 1.3 Calculate│
│ Total/Fees │
└──────┬───────┘
│ Order Total
▼
┌──────────────────┐
│ 1.4 Process │
│ Payment │
└──────┬───────────┘
│ Confirmed
│
┌───────┴────────┐
▼ ▼
┌─────────┐ ┌──────────┐
│Bank │ │Supplier │
│(Payment)│ │(Inventory│
└─────────┘ │ Update) │
└──────────┘
│
│ Confirmation
▼
Customer
DATA STORES:
───────────────────
D1 - Orders
───────────────────
───────────────────
D2 - Customers
───────────────────
───────────────────
D3 - Inventory
───────────────────
DECOMPOSITION OF 1.4 - Process Payment
(Parent inputs/outputs MUST match child total flows)
FROM: Order Total (from 1.3)
│
▼
┌────────────────────────────────────────────┐
│ │
│ 1.4.1 Validate 1.4.2 Submit │
│ Payment Details Payment │
│ ◯ ◯ │
│ │ ▲ │
│ │ Valid Payment │ │
│ └───────┬────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────┐ │
│ │ 1.4.3 Handle │ │
│ │ Payment Response │ │
│ │ ◯ │ │
│ └───────┬──────────┘ │
│ │ Confirmation │
└────────────────┼────────────────────────┘
│
▼
TO: Customer (confirmation)
TO: Bank (if failed, retry logic)
DATA STORE IN THIS SUBPROCESS:
───────────────────
D4 - Payment Log
───────────────────
| 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 |
| Data Store | Plural nouns | D1 - Customers, D2 - Orders, D3 - Inventory |
| External Entity | Singular or plural noun | Customer, Bank, Supplier, Government Agency |
| Process Number | Hierarchical decimal notation | 1.0 (parent), 1.1, 1.2, 1.3 (children), 1.2.1, 1.2.2 (grandchildren) |
Hierarchical Numbering reflects the decomposition tree:
Do NOT reuse numbers. Each process has a unique path that shows its position in the hierarchy.
┌─────────┐
│ Student │
└────┬────┘
│
Course Registration
Request / Confirmation
│
▼
┌──────────────────────┐
│ University │
│ Registration System │
│ (0.0) │
└──────────────────────┘
│
┌──────────┼──────────┐
│ │ │
▼ ▼ ▼
┌────────┐ ┌──────────┐ ┌──────────┐
│Registrar│ │ Finance │ │Department│
│ Office │ │ System │ │ Chair │
└────────┘ └──────────┘ └──────────┘
┌──────────────┐
│ Student │
└───────┬──────┘
│ Course Registration Request
│
▼
┌──────────────────┐
│1.0 Process │
│Applications │
└────┬───┬────┬────┘
│ │ │
┌─────┘ │ └──────────┐
│ │ │
▼ ▼ ▼
┌─────────┐ ┌──────────┐ ┌──────────┐
│1.1 Verify│ │1.2 Enroll│ │1.3 Calc. │
│Prereq │ │in Courses│ │Fees │
└─────┬────┘ └────┬─────┘ └────┬─────┘
│ │ │
┌────┴────┐ ┌────┴────┐ ┌─────┴────┐
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
Prerequisite Course Enrollment Fee
Status Confirmation Calculation
│
└─────────────┬────────────┐
│ │
▼ ▼
┌──────────┐ ┌──────────┐
│1.4 Generate│ │1.5 Notify│
│Reports │ │Registrar │
└──────┬─────┘ └────┬─────┘
│ │
└──────┬────┘
│
Confirmation /
Registration Report
│
▼
┌──────────────────────┐
│ Registrar Office │
│ Finance System │
│ Department Chair │
└──────────────────────┘
DATA STORES:
───────────────────
D1 - Students
───────────────────
───────────────────
D2 - Courses
───────────────────
───────────────────
D3 - Enrollments
───────────────────
───────────────────
D4 - Prerequisites
───────────────────
───────────────────
D5 - Fees Schedule
───────────────────
┌─────────────┐ ┌─────────┐
│ Customer │ │ Supplier│
└────┬────────┘ └────┬────┘
│ Order │ Inventory
│ Inquiry │ Status
│ ▼ │ ▼
│ ┌────────────────────┐
│ │ E-Commerce Order │
│ │ Processing System │
│ │ (0.0) │
│ └────────────────────┘
│ │
│ └──────┬─────────────────┐
│ │ │
▼ ▼ ▼
Order Conf. Payment Req. Shipment Notif.
│ │ │
│ ▼ ▼
│ ┌─────────┐ ┌─────────┐
│ │ Bank │ │Shipping │
│ │ │ │Company │
│ └─────────┘ └─────────┘
│
▼
Customer
┌─────────────┐
│ Customer │
└──────┬──────┘
│
Order Request
│
▼
┌──────────────┐
│ 1.0 Manage │
│ Orders │
└──────┬───────┘
│ Order Details
┌────┴────┐
│ │
▼ ▼
┌─────────┐ ┌──────────┐
│1.1 Verify│ │1.2 Check │
│Order │ │Inventory │
└────┬─────┘ └────┬─────┘
│ │
┌────┴───────┬────┘
│ │
▼ ▼
┌─────────────────────┐
│ 1.3 Process Payment │
└────────┬────────────┘
│ Payment Auth
▼
┌──────┐
│ Bank │
└──────┘
│
Payment Confirmation
│
▼
┌─────────────────────┐
│ 1.4 Manage Inventory│
└────────┬────────────┘
│ Update Stock
▼
┌──────────────┐
│D3 - Inventory│
└──────────────┘
│
Stock Update Confirm
│
▼
┌─────────────────────┐
│ 1.5 Ship Order │
└────────┬────────────┘
│ Shipment Details
▼
┌──────────────────┐
│ Shipping Company │
└──────────────────┘
│
Tracking Number
│
▼
┌─────────────────────┐
│ 1.6 Notify Customer │
└────────┬────────────┘
│
▼
Customer
DATA STORES:
───────────────────
D1 - Orders
───────────────────
───────────────────
D2 - Customers
───────────────────
───────────────────
D3 - Inventory
───────────────────
───────────────────
D4 - Payments
───────────────────
FROM: Order Details (from 1.2)
│
▼
┌─────────────────────────────────────────────────┐
│ DECOMPOSITION OF 1.3: Process Payment │
│ │
│ Order Details │
│ │ │
│ ▼ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │1.3.1 Validate│ │1.3.2 Apply │ │
│ │Payment Info │────────│Discounts │ │
│ └──────────────┘ └──────┬───────┘ │
│ │ │ │
│ Valid Payment ▼ │
│ │ ┌──────────────┐ │
│ │ │1.3.3 Submit │ │
│ └─────────────────▶│to Bank │ │
│ └──────┬───────┘ │
│ │ Transaction │
│ ┌─────────────▼──────────┐ │
│ │1.3.4 Handle Response │ │
│ │(Approve/Decline) │ │
│ └────────────┬───────────┘ │
│ │ │
└─────────────────────────────────┼──────────────┘
│
Payment Confirmation
│
▼
(to 1.4)
DATA STORE:
───────────────────
D4 - Payments
───────────────────
┌────────┐ ┌──────────┐
│ Patient│ │ Doctor │
└───┬────┘ └────┬─────┘
│ Patient Request │ Patient Info
│ Medical History │ Prescription
│ │
│ ┌────────────────────┐
│ │Healthcare Patient │
│ │Management System │
│ │ (0.0) │
│ └────────────────────┘
│ │
└───┼──────────┬──────────────┐
│ │ │
▼ ▼ ▼
Appointment Prescription Insurance
Confirmation Authorization Claim
│ │ │
│ ▼ ▼
│ ┌──────────┐ ┌──────────┐
│ │ Pharmacy │ │Insurance │
│ │ │ │Company │
│ └──────────┘ └──────────┘
│
▼
Patient
EXTERNAL ENTITIES:
- Patient (source/sink of medical requests)
- Doctor (provides medical decisions)
- Pharmacy (dispenses medications)
- Insurance Company (processes claims)
┌─────────┐ ┌────────┐
│ Patient │ │ Doctor │
└────┬────┘ └───┬────┘
│ Medical Request │ Patient
│ History │ Examination
│ │
▼ ▼
┌──────────────────────────────┐
│ 1.0 Register & Assess │
│ Patient │
└──┬──┬──────────┬──────────┬──┘
│ │ │ │
▼ ▼ ▼ ▼
┌────────┐ ┌─────────┐
│1.1 │ │1.2 │
│Register│ │Assess │
│Patient │ │Symptoms │
└─┬──────┘ └────┬────┘
│ │ Medical Assessment
┌──────┴─────────┬──────┘
│ │
▼ ▼
D1 - Patients ┌──────────────────────┐
│ 1.3 Generate │
│ Prescription/Plan │
└────────┬─────────────┘
│ Treatment Plan
│
┌─────┴──────┐
│ │
▼ ▼
┌─────────────┐ ┌──────────────┐
│ 1.4 Send to │ │ 1.5 Process │
│ Pharmacy │ │ Insurance │
└──────┬──────┘ └────┬─────────┘
│ │ Claim
│ │
▼ ▼
┌──────────┐ ┌──────────┐
│ Pharmacy │ │Insurance │
└──────────┘ └──────────┘
│ │
Medication Approval Approval
│ │
└──────┬─────┘
│
▼
┌──────────────┐
│ 1.6 Follow-up│
│ & Report │
└────────┬─────┘
│
▼
Patient / Doctor
DATA STORES:
───────────────────
D1 - Patients
───────────────────
───────────────────
D2 - Medical Records
───────────────────
───────────────────
D3 - Prescriptions
───────────────────
───────────────────
D4 - Insurance Claims
───────────────────
A Data Dictionary is a critical companion document to DFDs. It defines every data element, flow, and store in the system with precise specifications.
| Field | Description |
|---|---|
| Data Element Name | Unique identifier in the system |
| Alias | Alternative names used in business or legacy systems |
| Data Type | e.g., Integer, String, Date, Decimal, Boolean |
| Length / Format | e.g., 10 digits, YYYY-MM-DD, max 255 characters |
| Constraints | Range, null/not-null, unique, foreign key, regex pattern |
| Description | Business meaning and context |
| Source | 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 |
========================================================================
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
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 |
| 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 |
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: