Use cases: actor and flows

A use case describes a goal-oriented interaction between an actor and a system. Use cases were introduced by Ivar Jacobson in the late 1980s; the text template used here follows Alistair Cockburn's widely used style. We will use six of its building blocks. The Primary Actor is the person or external system that triggers the interaction and has the goal (e.g. 'Customer'). External systems the use case relies on — for example a payment service or a bank's core system — are supporting (secondary) actors. 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. Use case or user story? A user story is a short placeholder for a conversation ('As a customer, I want to pay online, so that I don't have to visit the office'); a use case is a full scenario with every step, precondition and branch. Teams often write the story first and detail only the tricky stories as use cases.