Skip to main content
Back to module
Solution Design & Integration · Systems Architecture

Context and data-flow diagrams

Reading34mLesson 2 of 3 in this module

Draw a context diagram and a level-0 data-flow diagram for a business process.

Why it matters

Stakeholders agree with long text documents and then discover, months later, that they understood them differently. A diagram that fits on one page is much harder to misread. Context diagrams and data-flow diagrams (DFDs) are the analyst's fastest way to agree on scope ("what is inside our system and what is outside") and on what data moves where.

The core idea

A context diagram (also called a level-0 DFD in some textbooks, or a system context diagram) shows:

  • One process: the system you are building, drawn as a single circle or rounded box.
  • External entities: people, organisations or other systems that send data to it or receive data from it, drawn as rectangles.
  • Data flows: labelled arrows showing what data moves, and in which direction.

It deliberately shows nothing inside the system. Its job is scope: anything not on the diagram is not part of the project.

A data-flow diagram opens the box. A level-0 (or level-1, depending on the textbook) DFD splits the system into its main processes and adds:

  • Processes: numbered verbs ("1.0 Register customer"), each transforming input into output.
  • Data stores: places data rests, such as a table or file, drawn as an open-ended rectangle labelled D1, D2...
  • Data flows: labelled with nouns ("customer details", "points balance").

DFDs show data, not control. There are no decisions, loops or timing: that is what activity diagrams and BPMN process maps are for.

Rules that catch mistakes

  • Every process must have at least one input and one output. A process with only inputs is a black hole; one with only outputs is a miracle.
  • Data cannot flow directly between two external entities, or between two data stores, or from an external entity straight into a store. A process must sit in between.
  • Flows into and out of a lower-level diagram must balance with the level above: if the context diagram shows "order" going in, the DFD must too.
  • Label every flow with a specific noun. "Data" or "info" means you have not decided what moves.

Worked example: Harbor Outfitters loyalty

The CRM project's context diagram, written as text:

External entities: Customer, Store staff (POS), Web shop, ERP, Email service

Customer   --sign-up details-->        [CRM loyalty system]
Customer   <--points statement--       [CRM loyalty system]
POS        --sale (customer id, total)--> [CRM]
POS        <--points balance--          [CRM]
Web shop   --new web customer-->        [CRM]
ERP        <--customer account details-- [CRM]
Email svc  <--marketing list, opt-ins--  [CRM]

The level-0 DFD opens it into four processes and two stores:

1.0 Register customer    in:  sign-up details, new web customer
                         out: customer record -> D1 Customers
                              customer account details -> ERP
2.0 Award points         in:  sale (from POS), customer record (D1)
                         out: points transaction -> D2 Points ledger
3.0 Report balance       in:  points transactions (D2)
                         out: points balance -> POS, points statement -> Customer
4.0 Build mailing list   in:  customer record with consent (D1)
                         out: marketing list -> Email service

Check it against the rules: every process has inputs and outputs; the POS never writes straight into D2 (process 2.0 does); the flows to and from external entities match the context diagram. Drawing process 4.0 also raised a real requirement: consent must be stored on the customer record, or the mailing list breaks privacy law.

Tools

Paper and a pencil are fine for a first draft. For sharing, use any diagramming tool: diagrams.net (draw.io, free in the browser), Lucidchart, Miro or Visio. Pick one symbol set (Gane-Sarson or Yourdon-DeMarco) and stick to it.

Common mistakes

  • Drawing control flow (if/then, loops) on a DFD.
  • Unlabelled or vaguely labelled arrows.
  • External entities connected directly to data stores.
  • A context diagram cluttered with internal detail, which defeats its purpose.
  • Not walking stakeholders through it; a diagram nobody has reviewed has not been agreed.

Quick recap

  • A context diagram shows one system, its external entities and the data flows between them: it defines scope.
  • A DFD breaks the system into numbered processes and data stores; it shows data, not control.
  • Check for black holes, miracles, illegal direct flows and unbalanced levels.

Try it

In the Do tab you draw both diagrams for a process you know.

Also in this lesson: