Process Modeling: Flowcharts & DFDs

DFD Level 2 & Balancing

18 min Lesson 7 of 10

DFD Level 2 & Balancing

A Level-1 DFD breaks the system into its major processes. But analysts quickly discover that some of those processes are still too large to specify directly — they hide significant complexity. Level-2 decomposition solves this by expanding one Level-1 bubble into its own mini-DFD, revealing the internal logic of that single process in detail. And because each expansion introduces new flows and stores, a discipline called balancing keeps every level consistent with the one above it.

When to Go Deeper

Not every Level-1 process needs a Level-2 diagram. A rule of thumb: if a process cannot be described clearly on a single index card, or if it involves more than one distinct sub-function, decompose it. Conversely, a primitive process — one that performs exactly one logical transformation — should never be decomposed further; write its process specification (mini-spec) instead.

Primitive Process: A process that is simple enough to be described with a short algorithm or decision table. It has no further DFD children — only a process specification (mini-spec / structured English).

Numbering Convention

Process numbering makes the hierarchy explicit. If Level-1 has processes 1.0, 2.0, 3.0, then decomposing process 2.0 produces children numbered 2.1, 2.2, 2.3, and so on. This decimal scheme instantly tells a reader which parent owns any given child process, regardless of how deep the analyst goes (2.3.1, 2.3.2, …).

The Balancing Rule

Balancing is the most important correctness check in a leveled DFD set. The rule is simple: every data flow that crosses the boundary of a parent process must also appear, with the same name and direction, on the child diagram.

Every flow entering process 2.0 on Level 1 must enter somewhere on the Level-2 diagram for 2.0.
Every flow leaving process 2.0 on Level 1 must leave somewhere on the Level-2 diagram.
Data stores that are internal to process 2.0 (used only by its children) appear on Level 2 but are hidden from Level 1 — that is perfectly fine.
Data stores shared with other Level-1 processes must appear on both levels with consistent names.

Balancing Violation: If Level 1 shows a flow called Appointment Request entering process 2.0, but that label does not appear anywhere on the Level-2 diagram, the model is unbalanced. Either the Level-1 flow is missing from Level 2, or the Level-2 diagram has renamed it — both are errors.

Case Study: Clinic Booking System

Recall the clinic booking system from the previous lesson. Its Level-1 DFD included process 2.0 — Process Appointment, which received Appointment Request from the Patient and produced Confirmation and Schedule Update as outputs. That process is complex enough to warrant decomposition. Below is the complete Level-2 diagram for process 2.0.

Level-2 DFD expanding Process 2.0 into four sub-processes (2.1–2.4). The three flows that cross the boundary — Appointment Request, Confirmation, and Schedule Update — match exactly what Level 1 shows for process 2.0.

Reading the Level-2 Diagram

Walk through it process by process:

2.1 Validate Request receives the raw Appointment Request from the Patient (the same flow that entered 2.0 on Level 1) and cross-checks it against D1 Patient Records to confirm the patient exists and the request is complete. It outputs a Validated Request.
2.2 Check Availability queries D3 Schedule (an internal store visible only at this level) and identifies an Available Slot.
2.3 Allocate Slot claims the slot in D3 Schedule and passes Booking Details downstream. It also produces Schedule Update, which exits the boundary to reach Doctor — exactly as Level 1 shows.
2.4 Send Confirmation formats and dispatches the Confirmation back to the Patient — again matching Level 1.

Internal vs. Shared Stores: D3 Schedule only appears inside the Level-2 diagram — no other Level-1 process touches it, so it is legitimately hidden. D1 Patient Records, however, is also used by other Level-1 processes, so it appears on both levels. Check both cases when balancing.

Balancing Checklist

After drawing any Level-2 diagram, run through this checklist:

List every flow entering and leaving the parent process on Level 1.
Verify each flow appears on Level 2 — same label, same direction, entering or leaving the boundary.
List every shared data store connected to the parent process on Level 1.
Verify each shared store appears on Level 2 with the same identifier and name.
Internal stores (used only within this process) need not appear on Level 1 — they are a detail hidden by abstraction.

Going Deeper: Level 3 and Beyond

The same rules apply if any Level-2 process is still too complex. Process 2.2 could be expanded into a Level-3 diagram containing children 2.2.1, 2.2.2, and so on. In practice, most business systems are fully specified by Level 2 or Level 3. If you find yourself needing Level 4 or beyond, reconsider whether the system is too large in scope for a single DFD set, or whether a different architectural artifact (such as a sequence diagram) would serve better.

Practical Depth: The Gane-Sarson method recommends stopping decomposition when a process can be described by no more than one page of structured English. That is your signal that the process is a primitive and needs a mini-spec, not another DFD level.

Common Balancing Mistakes

Renamed flows: Using Booking Request on Level 2 when Level 1 calls it Appointment Request — a silent rename that breaks traceability.
Missing flows: A Level-1 output that simply does not appear on Level 2 because the analyst forgot it.
Extra flows: Flows on Level 2 that cross the parent boundary but do not appear on Level 1 — these represent undocumented system behaviour.
Wrong direction: A flow that enters the parent on Level 1 but exits on Level 2 (or vice versa), indicating a logic error in one of the levels.

Catching these mistakes early — during peer review or with a structured walkthrough — is far cheaper than discovering inconsistencies during design or coding. Balanced, leveled DFDs form the authoritative process model that the rest of the specification depends on.