Data Flow Diagrams (DFDs)

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

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

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

                      ┌───────────────────┐
                      │   Customer        │
                      └────────┬──────────┘
                               │
                Order Request  │  Order Confirmation
                    │          │          ▲
                    │          │          │
                    │          ▼          │
                ┌───────────────────────────────┐
                │                               │
                │    Order Management System    │
                │           (0.0)               │
                │                               │
                └───────────────────────────────┘
                    │          ▲          │
                    │          │          ▲
         Inventory  │          │          │  Payment Status
        Update ▼    │          │          │
                ┌─────────────┐│  ┌──────────────┐
                │  Supplier   ││  │  Payment Bank│
                └─────────────┘│  └──────────────┘
                               │
                         Payment Request

Level 1: Major Processes

┌──────────────────────────────────────────────────────────────┐
│                     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
───────────────────

Level 2: Decompose Process 1.4 (Process Payment)

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
───────────────────

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
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)

Process Numbering System

Hierarchical Numbering reflects the decomposition tree:

1.0, 2.0, 3.0 — Top-level processes (Level 1)
1.1, 1.2, 1.3 — Decomposition of 1.0 (Level 2)
1.1.1, 1.1.2 — Decomposition of 1.1 (Level 3)

Do NOT reuse numbers. Each process has a unique path that shows its position in the hierarchy.

6. Example: University Registration System

Level 0: Context Diagram

              ┌─────────┐
              │ Student │
              └────┬────┘
                   │
         Course Registration
         Request / Confirmation
                   │
                   ▼
         ┌──────────────────────┐
         │ University           │
         │ Registration System  │
         │       (0.0)          │
         └──────────────────────┘
                   │
        ┌──────────┼──────────┐
        │          │          │
        ▼          ▼          ▼
    ┌────────┐ ┌──────────┐ ┌──────────┐
    │Registrar│ │  Finance │ │Department│
    │ Office  │ │ System   │ │ Chair    │
    └────────┘ └──────────┘ └──────────┘

Level 1: Major Processes

        ┌──────────────┐
        │   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
───────────────────

7. Example: E-Commerce Order Processing (Full 3-Level DFD)

Level 0: Context

┌─────────────┐          ┌─────────┐
│  Customer   │          │ Supplier│
└────┬────────┘          └────┬────┘
     │ Order               │ Inventory
     │ Inquiry             │ Status
     │ ▼                   │ ▼
     │ ┌────────────────────┐
     │ │ E-Commerce Order   │
     │ │ Processing System  │
     │ │       (0.0)        │
     │ └────────────────────┘
     │ │
     │ └──────┬─────────────────┐
     │        │                 │
     ▼        ▼                 ▼
Order Conf.  Payment Req.   Shipment Notif.
     │        │                 │
     │        ▼                 ▼
     │     ┌─────────┐      ┌─────────┐
     │     │  Bank   │      │Shipping │
     │     │         │      │Company  │
     │     └─────────┘      └─────────┘
     │
     ▼
Customer

Level 1: Main Processes

                  ┌─────────────┐
                  │  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
───────────────────

Level 2: Decompose 1.3 (Process Payment)

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
───────────────────

8. Example: Healthcare Patient Management System

Level 0: Context Diagram

      ┌────────┐              ┌──────────┐
      │ 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)

Level 1: Major Processes

           ┌─────────┐          ┌────────┐
           │ 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
───────────────────

9. Data Dictionary

A Data Dictionary is a critical companion document to DFDs. It defines every data element, flow, and store in the system with precise specifications.

Purpose

Eliminate ambiguity in data element names
Specify data types, formats, and constraints
Document data sources and destinations
Support developers in implementation
Enable traceability between analysis and design

Standard Data Dictionary Format

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

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

11. Best Practices for DFD Design

Process Numbering and Organization

Hierarchical numbering reflects decomposition: 1.0 → 1.1, 1.2, 1.3 → 1.2.1, 1.2.2
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)