Alternate & Exception Flows

Alternate & Exception Flows

A use case scenario that only describes the sunny-day path — the steps taken when everything works perfectly — is incomplete. Real systems must handle choices, detours, and failures. Use case writing gives you two structured mechanisms for this: alternate flows (valid but non-default paths) and exception flows (error or failure paths). Mastering these turns a superficial scenario into a specification strong enough to drive design and testing.

The Three Paths Through a Use Case

Every use case scenario has three categories of flow:

• Main (Basic) Flow — the primary success scenario; the path taken when all preconditions are met and no errors occur.
• Alternate Flows — valid, intentional variations. The actor or system makes a different choice, but the outcome is still acceptable. Example: paying by credit card vs. paying by wallet balance.
• Exception Flows — something goes wrong. The system must detect the condition and respond gracefully. Example: payment gateway timeout, or a drug interaction warning during prescription entry.

Notation Conventions

Alternate and exception flows are written inside the same use case document that holds the main flow. They are numbered with a branch identifier and a step offset:

• A1 — first alternate flow; steps within it are A1.1, A1.2, …
• E1 — first exception flow; steps E1.1, E1.2, …
• Each flow header states: where it branches from (e.g., "At step 4 of Main Flow") and the trigger condition.
• Each flow ends with: resume at step N of Main Flow, use case ends in success, or use case ends in failure.

Worked Example: Online Clinic Appointment Booking

Use Case: Book Appointment. Actor: Patient. System: Clinic Portal.

Main Flow

1. Patient selects a doctor and a preferred date.
2. System displays available time slots.
3. Patient selects a slot and confirms.
4. System processes the booking fee via the stored payment method.
5. System sends a confirmation email. Use case ends in success.

Alternate Flow A1 — No Stored Payment Method (triggers at step 4)

1. System detects no stored payment method on the patient account.
2. System prompts patient to enter card details.
3. Patient enters card details and submits.
4. Resume at step 4 of Main Flow.

Alternate Flow A2 — Patient Requests Different Slot (triggers at step 3)

1. Patient chooses "view more times" instead of confirming.
2. System displays the next available week.
3. Resume at step 3 of Main Flow.

Exception Flow E1 — Payment Gateway Timeout (triggers at step 4)

1. System receives no response from payment gateway within 10 seconds.
2. System cancels the tentative slot reservation.
3. System displays: "Payment could not be processed. Please try again or contact support."
4. Use case ends in failure.

Exception Flow E2 — Selected Slot Taken by Another Patient (triggers at step 3)

1. System detects the slot was concurrently booked by another patient.
2. System displays a "slot no longer available" message and refreshes the list.
3. Resume at step 3 of Main Flow.

Visualising Flows with an Activity Fragment

The diagram below maps the same "Book Appointment" case onto an activity-style flow, showing where the alternate and exception branches split off from and rejoin (or terminate) the main path. Decision diamonds represent the trigger conditions described in the scenario text.

Writing the Flows in a Use Case Document

The structured template below shows how the flows appear in a formal use case document. Notice that each alternate and exception flow cites a specific trigger step number from the main flow — this precision is what makes the document unambiguous to developers and testers.

Identifying All the Flows: Practical Techniques

Analysts often struggle to enumerate every alternate and exception flow. Use these systematic triggers to find them:

• "What if the actor changes their mind?" — leads to alternate flows (cancel, go back, choose a different option).
• "What if the data is invalid?" — leads to exception flows (invalid email, date in the past, field missing).
• "What if an external system fails?" — leads to exception flows (payment gateway, email service, third-party API).
• "What if two users act simultaneously?" — leads to concurrency exception flows (race conditions on shared resources).
• "What if permissions are insufficient?" — leads to exception flows (unauthorised access, expired session).

Common Mistakes

• Calling everything an exception: An actor choosing a different valid path (pay by invoice instead of card) is an alternate flow, not an exception.
• Forgetting to state the outcome: Every flow must end with "resume at step N", "ends in success", or "ends in failure".
• Ambiguous trigger step: Writing "when payment fails" without citing the step number makes the document harder to trace and test.
• Missing the re-entry point: An alternate flow that loops back must state exactly which step it returns to.

With alternate and exception flows fully documented, your use case scenario becomes a testable contract. Each flow maps directly to at least one test case — a connection you will explore in Lesson 9.