Decomposing: DFD Level 1

Decomposing: DFD Level 1

The Context Diagram (Level 0) gave us the 30,000-foot view: one process bubble representing the entire system, its external entities, and the flows connecting them. That single bubble is a black box — it tells stakeholders what the system exchanges with the outside world, but says nothing about how those exchanges are handled internally. The Level 1 DFD opens that black box by replacing the single bubble with a set of major processes — typically four to nine — each representing a coherent chunk of system responsibility. It is the most practically useful diagram in a DFD hierarchy, sitting at precisely the right level of detail for requirements validation and database scoping.

What Changes from Level 0 to Level 1?

Four things change when you decompose the context diagram into Level 1:

1. The single process bubble is replaced by numbered child processes (1.0, 2.0, 3.0 …).
2. Data stores appear for the first time. Level 0 hides them; Level 1 names every persistent store the system reads from or writes to.
3. Internal flows are drawn between the new processes and the data stores, showing how data moves inside the system.
4. External entities and boundary flows are preserved exactly — this is the balancing rule, and violating it is the most common Level 1 mistake.

Naming and Numbering Conventions

Consistent conventions keep diagrams readable across a team:

• Process numbers — use integers at Level 1 (1.0, 2.0, 3.0). Decimal suffixes are reserved for Level 2 children (1.1, 1.2, 2.1 …).
• Process names — always a verb-object pair: Validate Login, Process Order, Generate Report. A noun-only label (e.g., "Order Management") signals the bubble is really a sub-system, not a process.
• Data store names — plural nouns without verbs: D1 Appointments, D2 Patients, D3 Books. Prefix with D1, D2 etc. to distinguish stores from processes.
• Flow labels — noun phrases matching the data, not the action: Booking Request, not "Submit Booking".

Building a Level 1 DFD: Clinic Booking System

Let us walk through constructing a Level 1 DFD for the clinic appointment-booking system. The context diagram established three external entities — Patient, Doctor, and Health Authority — and the following boundary flows: Booking Request (in), Appointment Confirmation (out), Cancellation Notice (in), Schedule Availability (in from Doctor), Schedule Summary (out to Doctor), and Compliance Report (out to Health Authority).

Analysing those flows and the system's responsibilities, we identify five major processes:

• 1.0 Manage Patient Registration — creates and updates patient records.
• 2.0 Handle Booking Request — checks availability and creates appointments.
• 3.0 Manage Cancellations — removes or reschedules appointments.
• 4.0 Manage Doctor Schedule — updates and queries doctor availability.
• 5.0 Generate Reports — compiles data for the Health Authority and the practice manager.

Three data stores support these processes: D1 Patients, D2 Appointments, and D3 Doctor Schedules.

Reading the Diagram: What Every Element Means

Walk through the diagram systematically, element by element, when reviewing with stakeholders:

• Process 1.0 receives Patient Details from the Patient (a boundary flow) and writes a Patient Record into the D1 Patients store. This bubble is the registration gate — no other process stores patient records.
• Process 2.0 receives the Booking Request, reads patient data from D1 to verify the patient, checks slot availability in D3 Doctor Schedules, writes a new appointment to D2 Appointments, and sends an Appointment Confirmation back to the patient. Notice how this single bubble orchestrates three data stores — a hint that it may need further decomposition at Level 2.
• Process 3.0 receives the Cancellation Notice and removes or marks the record in D2.
• Process 4.0 receives Schedule Availability from the Doctor, updates D3, and returns a Schedule Summary to the Doctor.
• Process 5.0 reads from D2 Appointments and compiles the Compliance Report sent to the Health Authority.

A Second Example: Online Store Order Processing

To reinforce the technique, consider the Level 1 DFD for a simplified online store. The context diagram boundary flows are: Order (in from Customer), Order Confirmation (out to Customer), Shipment Notice (out to Customer), Stock Request (out to Supplier), Stock Delivery (in from Supplier), and Sales Report (out to Manager).

This suggests four major processes at Level 1:

1. 1.0 Process Order — validates the order, checks inventory in D1 Inventory, reserves stock, writes to D2 Orders, sends Order Confirmation.
2. 2.0 Manage Inventory — receives Stock Delivery from Supplier, updates D1 Inventory; also triggers Stock Request to Supplier when stock falls below threshold.
3. 3.0 Fulfil Shipment — reads from D2 Orders, updates order status, sends Shipment Notice to Customer.
4. 4.0 Generate Sales Report — reads from D2 Orders, compiles and sends Sales Report to Manager.

How Many Processes Is Too Many?

The classic guidance is four to nine processes at Level 1. Fewer than four usually means the bubbles are too coarse to be meaningful; more than nine makes the diagram cognitively overwhelming and is usually a sign the analyst has dropped to Level 2 detail prematurely. If you find yourself drawing twelve bubbles, look for pairs that can be merged into a single higher-level process and decomposed later.

Checklist Before Finalising a Level 1 DFD

1. Every boundary flow from the context diagram appears on Level 1 with the same name and direction — balanced.
2. Every process has at least one input flow and one output flow — no black holes or miracles.
3. All process labels are verb-object pairs.
4. All data stores are named and numbered (D1, D2 …).
5. No direct entity-to-entity flows that bypass the system (those belong outside the system boundary).
6. No control flows (decisions, conditions) — DFDs show data movement, not logic; use flowcharts or activity diagrams for logic.

A well-constructed Level 1 DFD is a powerful communication artefact. Developers see the data stores and begin thinking about the database schema. Testers see the boundary flows and start drafting test cases. Business users see familiar process names and confirm whether the scope is correct. In the next lesson we will push one of these processes downward into Level 2, learning how to maintain consistency — and exactly when to stop decomposing.