The learner can write a use case with an actor, preconditions and postconditions, a main success scenario, and at least one alternative flow.
Anatomy of a Use Case
Anatomy of a Use Case
A use case (pioneered by Alistair Cockburn) describes a goal-oriented interaction between an actor and a system. Every well-formed use case has six building blocks.
The Primary Actor is the person or external system that triggers the interaction and has the goal (e.g. 'Customer'). Preconditions state what must be true before the use case can start (e.g. 'Customer is logged in'). The Trigger is the event that kicks off the use case (e.g. 'Customer clicks Place Order'). The Main Success Scenario (MSS) is the happy path — a numbered sequence of steps that lead from the trigger to the goal being achieved. Extensions (also called alternative flows) handle anything that can go wrong or deviate from the happy path, referencing specific MSS step numbers (e.g. '3a. Card is declined: system shows error and returns to step 3'). Finally, Success Guarantees (postconditions) state what is true after a successful run (e.g. 'Order is saved, confirmation email sent').
The key discipline is to keep the Main Success Scenario as the straight, uninterrupted happy path. Every branch — validation errors, timeouts, optional choices — lives in Extensions. This separation makes both the goal and the failure modes immediately visible to anyone reading the document.
Lesson notes
Anatomy of a Use Case
A use case (pioneered by Alistair Cockburn) describes a goal-oriented interaction between an actor and a system. Every well-formed use case has six building blocks.
The Primary Actor is the person or external system that triggers the interaction and has the goal (e.g. 'Customer'). Preconditions state what must be true before the use case can start (e.g. 'Customer is logged in'). The Trigger is the event that kicks off the use case (e.g. 'Customer clicks Place Order'). The Main Success Scenario (MSS) is the happy path — a numbered sequence of steps that lead from the trigger to the goal being achieved. Extensions (also called alternative flows) handle anything that can go wrong or deviate from the happy path, referencing specific MSS step numbers (e.g. '3a. Card is declined: system shows error and returns to step 3'). Finally, Success Guarantees (postconditions) state what is true after a successful run (e.g. 'Order is saved, confirmation email sent').
The key discipline is to keep the Main Success Scenario as the straight, uninterrupted happy path. Every branch — validation errors, timeouts, optional choices — lives in Extensions. This separation makes both the goal and the failure modes immediately visible to anyone reading the document.