Data Flow Diagram

What this diagram shows

A data flow diagram (DFD) visualises how data moves through a system from entry point to storage and back out again. It maps sources (external entities), processes that transform or act on data, data stores where information sits, and flows showing movement between them. DFDs ignore technical implementation details like databases or programming languages, focusing instead on what data goes where and why. This makes them ideal for showing business logic or system behaviour at a conceptual level before building anything.

Key components

• External Entity — A person, organisation, or system outside your boundary that sends data in or receives data out.
• Process — A task or function that accepts input data, performs work, and produces output data.
• Data Store — A place where data rests between processes, such as a database, file, or cache.
• Data Flow — An arrow showing the movement of named data between entities, processes, and stores.
• Context Level (Level 0) — The top-level DFD showing the entire system as one process and its connections to the outside world.
• Decomposition Levels (1, 2, ...) — Detailed breakdowns of a process into sub-processes, each level adding specificity without changing inputs or outputs.
• Balancing Rule — The requirement that data flowing in and out of a process or decomposed level must remain consistent across all representations.

When to use it

Use a DFD when you need to document how information flows through a business process or software system before implementation. They work well for requirement gathering, communicating system design to non-technical stakeholders, and identifying data dependencies. DFDs are particularly useful for legacy system documentation, compliance audits that need to track data movement, and early-stage system analysis where you want to avoid premature technical choices.

Common mistakes

• Mixing different abstraction levels in one diagram by showing both high-level processes and detailed database tables, which destroys clarity.
• Labelling flows with vague names like 'data' or 'request' instead of specific payloads such as 'customer order', 'invoice PDF', or 'transaction ID'.
• Creating processes that are too coarse ('handle all customer requests') or too fine ('write record to buffer'), making the diagram either useless or unreadable.

Adapting it to your system

Start by drawing your system boundary as a single process and list all external entities that touch it. Create a context diagram showing only that boundary and the entities. Then pick the most important processes and decompose them into a Level 1 DFD, naming each process clearly with a verb and object (e.g. 'Validate Payment', 'Generate Invoice'). Add data stores where processes need to persist or retrieve information. Label each flow with the actual data structure or document name. Repeat decomposition for complex processes, ensuring inputs and outputs balance at each level.