Structured Analysis

Context Diagramsstructured analysisthe level 0 view: one process, all external entities, and the data crossing the boundary. Data Flow Diagramsstructured analysislevelled DFDs: processes, stores and flows, with balancing rules and worked examples. Data Dictionarystructured analysisprecise definitions of every data flow and store, using the classic composition notation.

Structured analysis is a classic method for describing what an information system does by following its data: who sends data in, what transforms it, where it is stored and what comes out. This section teaches its diagrams and supporting documents.

1. Overview and Notation

Structured analysis was developed in the 1970s by Tom DeMarco, Ed Yourdon, Larry Constantine, and Chris Gane and Trish Sarson, among others. It models a system as a network of processes connected by flows of data, and refines that model top-down. It predates UML and object-oriented design, but it remains very useful today, especially for data engineers, because data pipelines, integrations and compliance reviews are fundamentally about where data goes. Privacy and security teams also use data flow diagrams for threat modelling and data-protection assessments.

Structured analysis is one family of diagrams among several; see the Diagramming hub for how it relates to UML, C4 and others.

Structured Analysis Notation (Yourdon / DeMarco) Customer External entity outside the system 2.0 Bill Process transforms data D1 Orders Data store data at rest invoice Data flow named data in motion Gane-Sarson notation draws processes as rounded rectangles; the meaning is the same.

Only four symbols are needed. An external entity (terminator) is a person, organisation or system outside your boundary that sends or receives data. A process transforms incoming data into outgoing data and is named with a verb phrase. A data store holds data at rest, such as a table or file. A data flow is a named arrow showing a packet of data moving between the other three. Data never flows directly between two external entities or two stores; a process must be involved.

2. The Method, Top Down

Top-Down Levelling Context diagram whole system = one process Level 1 DFD major processes 1.0 to 5.0 Level 2 DFDs explode 2.0 into 2.1, 2.2 Data dictionary defines every flow and store Process specs logic of each bottom process Flows must balance: a child diagram has exactly the inputs and outputs of its parent process.
  1. Context diagram. Draw the entire system as a single process, surrounded by every external entity and the flows between them. This fixes the scope.
  2. Levelled DFDs. Explode the single process into a level 1 diagram of five to nine major processes and the stores between them. Explode any complex process again into level 2, numbering children 2.1, 2.2 and so on.
  3. Data dictionary. Define every flow and store precisely, for example invoice = invoice_id + customer_id + {line_item} + total.
  4. Process specifications. For each bottom-level process, describe its logic in structured English, a decision table or pseudocode.

The key rule is balancing: when a process is exploded, the child diagram must have the same inputs and outputs as the parent. This keeps levels consistent and catches missing data early.

3. Which Artifact Answers Which Question

ArtifactAnswersAudience
Context diagramWhat is inside the system, and who does it talk to?Everyone, including non-technical stakeholders
Data flow diagramWhich processes transform which data, and where is it stored?Analysts, data engineers, security reviewers
Data dictionaryWhat exactly is in each flow and store?Developers, data modellers
Process specificationWhat does this step do, precisely?Developers, testers
ER diagram (companion)How are stored entities related?Data modellers, DBAs
DiagrammingSectionall diagram families Entity-Relationship Diagramsmodellingmodelling the data stores Logical Data Modelmodellingfrom ER diagram to tables UML Activity Diagramsumla control-flow alternative

5. Further Reading