Process Modeling: Flowcharts & DFDs

Common DFD Mistakes

18 min Lesson 8 of 10

Common DFD Mistakes

Even experienced analysts slip into recurring traps when drawing Data Flow Diagrams. Four errors account for the vast majority of invalid DFDs produced in practice: black holes, miracles, crossing flows, and naming errors. Each one signals a gap in your understanding of the system — or a gap in your communication with stakeholders. This lesson teaches you to recognise these mistakes instantly, understand why they are logically wrong, and correct them before your model misleads the development team.

Why correctness matters: A DFD is a contract between the analyst and the developer. An error in the diagram — a missing output, a fabricated input, a vague label — translates directly into missing code, incorrect assumptions, or wasted meetings. Catching mistakes at the modelling stage costs minutes; catching them in testing costs days.

Mistake 1: Black Holes

A black hole is a process that consumes inputs but produces no outputs. Like an astronomical black hole, data enters and never escapes. This almost always means either (a) the analyst forgot to draw the outgoing flows, or (b) the process has no real business purpose and should be removed.

Consider a clinic appointment system. The process Validate Patient ID receives a patient ID from the patient entity. If you forget to draw the output — a validation result sent to the Schedule Appointment process — you have a black hole. The validation result exists in reality; the diagram just failed to capture it.

Black Hole vs Corrected DFD Wrong — Black Hole Patient Patient ID 1.0 Validate Patient ID No output! ✗ ! Correct — Output Added Patient Patient ID 1.0 Validate Patient ID Valid/Invalid 2.0 Schedule Appointment
Left: a black hole — the Validate Patient ID process receives data but emits nothing. Right: corrected by adding the outgoing "Valid/Invalid" flow.
Quick test: For every process bubble on your DFD, ask "what does this produce?" If you cannot name at least one outgoing data flow, you have a black hole.

Mistake 2: Miracles

A miracle is the opposite problem: a process that produces outputs without receiving any inputs. It "generates" data from nothing — like a magic trick. In practice this means the analyst forgot to draw the source of the data, or accidentally omitted an input flow.

In an online store system, the process Generate Invoice must produce an invoice — but it cannot do so unless it receives order details. If no input flow is drawn to Generate Invoice, the diagram implies that the invoice appears from thin air. The fix is to trace back every output to its real data source and add the missing input flow.

Common cause: Miracles often appear when analysts decompose a level-0 diagram and forget to pass the parent flow into the child processes. Always check that decomposed processes inherit the inputs of their parent.
Miracle vs Corrected DFD Wrong — Miracle 3.0 Generate Invoice Invoice Customer No input! ✗ ? Correct — Input Added D1 Orders Order Details 3.0 Generate Invoice Invoice Customer
Left: a miracle — Generate Invoice produces an invoice with no incoming data. Right: corrected by adding "Order Details" from the Orders data store.

Mistake 3: Crossing Flows

Crossing flows occur when two data-flow arrows physically intersect on the diagram, making it hard to trace which flow goes where. They do not represent a logical error — the underlying system may be perfectly valid — but they make the diagram illegible and increase the chance of misinterpretation.

The standard solution is to duplicate an external entity or data store on the diagram. Gane-Sarson notation explicitly allows you to draw the same entity or store more than once (usually with a small diagonal slash or asterisk in the corner to signal the duplicate), routing arrows cleanly without crossing.

In a library system, both the Issue Book process and the Return Book process might need to read from the Members data store. If you draw a single Members store in the centre, the arrows fan out and overlap. By placing a second copy of Members near each process, both sets of arrows travel in a single clean direction.

Redraw rule: If crossing flows appear even after rearranging elements, duplicate the external entity or data store rather than leaving the arrows tangled. Legibility is a first-class quality attribute of a DFD.

Mistake 4: Naming Errors

Weak or incorrect names are the most pervasive DFD errors because they pass visual inspection but fail the moment a developer reads them. There are three sub-categories:

  • Vague process names: Names like "Process Data", "Handle Request", or "Do Something" tell the reader nothing. Each process name must be a verb-object phrase that states what transformation occurs: "Validate Booking Request", "Update Member Record", "Calculate Shipping Cost".
  • Noun-only process names: A process named "Invoice" is a noun — it sounds like a data store. Processes must be named with active verbs: "Generate Invoice".
  • Unlabelled or vaguely labelled data flows: An arrow with no label, or labelled "Data", "Info", or "Message" obscures the DFD's purpose entirely. Every flow must carry a specific noun that describes the information it carries: "Appointment Confirmation", "Rejected Payment Notice", "Book Availability Status".
Naming Errors vs Correct Names Wrong — Poor Names User Data ✗ 1.0 Process Request ✗ (no label) ✗ D1 Info ✗ Noun-only name = vague Unlabelled flows Vague store name Correct — Specific Names Member Loan Request 1.0 Validate Loan Request Validated Loan D2 Loans Verb-object process names Labelled with specific noun Descriptive store
Left: poor names — vague process label, no flow label, ambiguous store. Right: corrected with verb-object process names and specific data-flow labels.

A Systematic Review Checklist

Before finalising any DFD level, run through this five-point check:

  1. No black holes. Every process has at least one outgoing data flow.
  2. No miracles. Every process has at least one incoming data flow.
  3. No tangled flows. No two arrows cross; if they do, duplicate the entity or store.
  4. Specific flow labels. Every arrow carries a precise noun — not "data", not blank.
  5. Verb-object process names. Every process bubble uses an action verb plus a specific object.
Peer review tip: Hand your DFD to a colleague who was not in the requirements meetings. Ask them to read it aloud: "Process X receives Y and produces Z." If they cannot complete that sentence for every process, your diagram has a mistake to fix.

Real-World Example: Clinic Booking System Audit

Suppose a junior analyst draws a DFD for a clinic booking system with four processes: Receive Request, Check, Book, and Send Confirmation. A quick review reveals:

  • Receive Request has no output — black hole. Fix: add a flow "Booking Request" to Check Availability.
  • Check — vague name — naming error. Fix: rename to "Check Schedule Availability".
  • Book has no input — miracle. Fix: add incoming flow "Available Slot" from the Schedule data store.
  • The flows from Book to both the Patient entity and the Appointments data store cross each other — crossing flows. Fix: duplicate the Appointments store on the right side of the diagram.

Four mistakes in a single small diagram. This is not unusual in a first draft; the important thing is knowing what to look for.

Summary

In this lesson you learned to identify and correct the four most common DFD errors:

  • Black hole: process with inputs but no outputs — add the missing outgoing flow.
  • Miracle: process with outputs but no inputs — trace the data source and add the missing incoming flow.
  • Crossing flows: tangled arrows — reposition elements or duplicate entities/stores.
  • Naming errors: vague processes, noun-only names, or unlabelled flows — use verb-object process names and specific nouns on every arrow.
Next up: Lesson 9 compares Flowcharts, DFDs, and other modelling notations side by side — helping you choose the right tool for each analysis situation.
Previous Lesson DFD Level 2 & Balancing
Next Lesson Flowcharts vs DFDs vs Other Models
Back to Course