Process Modeling: Flowcharts & DFDs

Project: Model a Business Process

18 min Lesson 10 of 10

Project: Model a Business Process

This capstone lesson puts everything together. Working through a single realistic scenario — a clinic appointment booking system — you will produce three interlocking models: a flowchart that traces the step-by-step booking procedure, a context diagram (DFD Level 0) that positions the system in its environment, and a Level-1 DFD that reveals the system's internal processes. Reading all three side-by-side shows how each model answers a different question about the same business reality.

The Scenario

A private clinic wants to digitise its appointment booking. Patients phone or walk in to request a slot. A receptionist checks the doctor's availability, confirms the booking, and sends the patient a reminder. If no slot is free, the patient is placed on a waiting list. On the day of the appointment the receptionist marks the patient as arrived and the doctor updates the medical record after the consultation. Three external parties interact with the system: the Patient, the Doctor, and the Insurance Provider (which receives a claim after each consultation).

Why three models? A flowchart shows sequence and decisions. A context diagram shows system boundaries and external actors. A Level-1 DFD shows internal data flows between processes and stores. No single model does all three jobs well.

Model 1 — Flowchart: The Booking Procedure

The flowchart below traces what happens from the moment a patient requests an appointment to the moment the booking is confirmed or the patient is wait-listed. Notice the standard shapes: rounded rectangles for Start/End, rectangles for processes, a diamond for the availability decision, and parallelograms for inputs and outputs.

Flowchart — Clinic Appointment Booking Procedure Start Patient requests appointment Check doctor availability in the schedule Slot available? Yes No Confirm booking & send reminder Booking confirmation to Patient End Add to waiting list End
Flowchart: the clinic appointment booking procedure, showing the availability decision and both outcome paths.

Walk through the diagram: the patient's request is the input (parallelogram), the receptionist checks availability (rectangle), and the diamond splits the flow. The Yes path confirms the booking and notifies the patient; the No path adds the patient to the waiting list. Both paths reach a terminal. This tells the developer and analyst exactly what the software must do at runtime.

Modelling tip: draw the flowchart first — it forces you to agree on the exact sequence of steps before you think about data. Once the sequence is settled, the DFDs become much easier to draw correctly.

Model 2 — Context Diagram (DFD Level 0)

The context diagram abstracts away all internal detail. The clinic booking system is a single process (the centre bubble). Three external entities interact with it: Patient, Doctor, and Insurance Provider. The labeled arrows show which data flows across each boundary. There are no internal data stores at this level — those appear in Level 1.

Context Diagram — Clinic Appointment Booking System (DFD Level 0) 0 Clinic Booking System Patient Appt. Request Confirmation / Reminder Doctor Schedule / Record Update Appointment List Insurance Provider Consultation Claim
Context diagram (DFD Level 0): the clinic booking system with its three external entities and the data flows crossing the system boundary.

The context diagram answers the question: what is inside the system, and what is outside? Every data flow you see here must also appear in the Level-1 diagram — that is the balancing rule in action at the very first level transition.

Model 3 — Level-1 DFD: Internal Processes

The Level-1 diagram explodes the single bubble into the system's four main processes, introduces the three internal data stores, and shows how data moves among them. The same external entities and boundary flows from the context diagram appear here unchanged — balancing is maintained.

Level-1 DFD — Clinic Appointment Booking System Patient Doctor Insurance 1.0 Manage Appt. Request 2.0 Schedule Appointment 3.0 Record Consultation 4.0 Send Claim D1 Appointment Schedule D2 Patient Records D3 Doctor Schedule Appt. Request Confirmation Validated Request Write Read Avail. Query Slot Data Schedule Update Appt. Data Consultation Notes Write Read Consult. Summary Insurance Claim
Level-1 DFD: the clinic booking system decomposed into four processes and three data stores, with all boundary flows preserved from the context diagram.

Checking the Models for Correctness

Before submitting any model set, verify these four checks:

  1. Balancing: every flow crossing the context-diagram boundary (Appt. Request, Confirmation, Schedule Update, Appointment List, Consultation Claim) must appear on the Level-1 diagram with the same name. Open the two diagrams and tick them off one by one.
  2. No process without input and output: inspect each Level-1 bubble. Process 3.0 Record Consultation receives Appt. Data from Process 2 and Consultation Notes from the Doctor, reads and writes Patient Records, and produces the Consultation Summary for Process 4. Every input and output is accounted for.
  3. No data store without a reading process: data must flow out of every store at some point. D1 Appointment Schedule is written by Process 2 and read back by Process 2 (availability checks). D2 Patient Records is written and read by Process 3. D3 Doctor Schedule is written by the Doctor and read by Process 2.
  4. Flowchart decision coverage: every diamond has exactly two labeled exit paths. Check that both the Yes and No branches lead to a valid terminal — they do in the diagram above.
Common student mistake: drawing the Level-1 DFD first and then making up a context diagram that does not match. Always start with the context diagram and treat its boundary flows as fixed constraints that the Level-1 must honour.

What to Submit for Your Own Project

When you model a business process for a real project, deliver the same three-diagram package together with a short written narrative:

  • Scenario description — two or three paragraphs naming the actors, the business goal, and the main steps (like the clinic scenario above).
  • Flowchart — at least one decision diamond, correct shape usage, all paths reaching a terminal.
  • Context diagram — one process bubble, all external entities, all boundary flows labeled.
  • Level-1 DFD — between three and seven numbered process bubbles, all data stores named and connected, boundary flows from the context diagram preserved exactly.
  • Balancing checklist — a brief note confirming that every context-level flow appears on the Level-1 diagram.
Practice suggestion: try the same three-model exercise on a library book-borrowing system. Actors: Borrower, Librarian, Publisher (for acquisition). Processes: Search Catalogue, Issue Loan, Return and Fine, Order New Stock. This is a clean scenario with straightforward flows and gives you useful practice before tackling a more complex domain.

Completing this capstone exercise means you can model any business process at three levels of abstraction — sequential, contextual, and data-flow. That analytical clarity is the foundation of every requirements document, functional specification, and system design that follows.

Tutorial Complete!

Congratulations! You have completed all lessons in this tutorial.

Previous Lesson Flowcharts vs DFDs vs Other Models
Back to Course System Analysis
Back to Course