Process Modeling: Flowcharts & DFDs

Drawing Effective Flowcharts

18 min Lesson 3 of 10

Drawing Effective Flowcharts

Knowing the symbols is only half the skill. The harder half is decomposing a messy, real-world business process into a clean, readable flowchart that a developer can code from and a manager can review in a meeting. This lesson walks you through exactly that — using a realistic order-handling scenario as our working example.

The Process We Will Model

Imagine you are the systems analyst for a mid-size online store. The operations manager hands you a description of their order-handling workflow:

"When a customer places an order, we first check whether all items are in stock. If anything is out of stock, we notify the customer and offer a cancellation or back-order option. If they cancel, we refund any pre-payment and close the order. If they choose back-order, we log it and wait. Once all items are available, we confirm the order and send it to the warehouse. The warehouse picks and packs the goods. Before shipping, the payment must be authorised. If payment fails, the order is held and the customer is contacted. Once payment is authorised, we ship the parcel and email a tracking number to the customer. The order is then marked complete."

This paragraph contains decisions, loops, parallel concerns, and multiple outcomes — exactly the kind of complexity a flowchart is designed to untangle.

Step 1 — Identify the Boundaries

Every flowchart needs a clear start event and one or more end events. Before drawing a single shape, list them:

Start: Customer places an order.
End 1: Order cancelled and refunded.
End 2: Order completed (parcel shipped, tracking sent).
End 3: Order placed on back-order (waiting for stock).

Multiple end events are perfectly normal. Forcing everything into a single endpoint creates a cluttered diagram. Separate terminators for each logical outcome keep the chart honest.

Step 2 — Extract the Decisions

Scan the description for conditional language: if, whether, when, once, unless. Each one is a diamond. Our process has three:

Items in stock? — Yes → continue; No → notify customer.
Customer choice? — Cancel → refund path; Back-order → wait path.
Payment authorised? — Yes → ship; No → hold order.

Tip — Decision labeling: Always label both branches of a diamond (Yes/No, or the specific outcome like Cancel/Back-order). An unlabeled branch is ambiguous and will produce conflicting interpretations among developers and stakeholders.

Step 3 — Sequence the Process Steps

Between the decisions, list the plain process steps in order. In standard notation these are rectangles. From the description we get:

Check stock availability
Notify customer (stock issue)
Log back-order
Issue refund
Confirm order
Send to warehouse / Pick and pack
Authorise payment
Ship parcel
Send tracking email
Mark order complete

Step 4 — Draw the Flowchart

With boundaries, decisions, and steps identified, we now assemble the diagram. Use rounded rectangles (terminators) for Start/End, rectangles for processes, and diamonds for decisions. Arrows carry the flow, and labels disambiguate every branch.

Order-handling flowchart: three distinct end states (Complete, Cancelled, Awaiting Stock) and a payment-retry loop.

Step 5 — Review the Diagram Against the Rules

Before presenting the flowchart to stakeholders, run it through this checklist:

Every decision has all branches labeled. Diamonds without labels are the single most common review comment.
No dead ends. Every shape must either lead somewhere or be an end terminator.
Loops are visible and intentional. The payment-retry loop in the diagram above is explicit — there is no hidden infinite loop.
Flow goes top-to-bottom, exceptions branch right. The main "happy path" runs straight down; exception paths branch off to the right. This is a widely accepted layout convention that readers scan naturally.
Consistent level of detail. If one rectangle says "Pick and Pack," the adjacent rectangle should not say "Authenticate the customer's OAuth2 token and log the JWT claim set." Mix of abstraction levels is a sign the model needs another pass.

Note — Happy Path vs. Exception Paths: The "happy path" is the sequence of steps that executes when everything goes right — all stock available, payment succeeds, parcel ships. Exceptions (out-of-stock, payment failure) branch away from it. Structuring your diagram this way makes the normal flow obvious to any reader and groups the error-handling logic separately.

Decomposing to the Right Level

A single flowchart should fit comfortably on one page (or screen). When you find yourself drawing more than about 15–20 shapes, consider decomposing. The "Pick and Pack" rectangle in the order-handling chart above could itself be the start point of a child flowchart that shows the warehouse worker's detailed steps: locate bins, scan items, weigh parcel, print label, move to dispatch. This hierarchical approach — a high-level parent chart with detailed child charts — is called nested or layered flowcharting and mirrors exactly how DFD levels work (you will apply that same idea in the next two lessons).

Warning — Over-decomposition: Do not create a separate child chart for a step that takes two seconds and never fails (for example, "Print Invoice"). Reserve decomposition for steps with real complexity, multiple failure modes, or steps owned by a different team or system.

Communicating with Stakeholders

A flowchart serves two audiences. Business stakeholders use it to confirm that the analyst has understood the process correctly — keep it free of technical jargon. Developers use it as the blueprint for implementing logic — make it precise enough that every branch condition is unambiguous. When the same diagram must serve both, favour clarity over completeness: add a written specification alongside it for the technical detail.

Walk through the diagram with the operations manager step by step, pointing at each shape. Ask: "Is this what happens?" and "What if this condition is not met?" Stakeholders frequently spot missing steps or incorrect branch conditions during a five-minute walkthrough that would otherwise surface as a bug after months of development.