A USE CASE is a description of a set of sequences of actions, including variants, that a system performs to yield an OBSERVABLE RESULT OF VALUE to a particular actor. THREE WORDS DO the work in that definition: SEQUENCES OF ACTIONS — it is a narrative, not a feature INCLUDING VARIANTS — the alternatives and failures are part of the use case, not appendices RESULT OF VALUE — it must complete something the actor wanted. "Log in" is usually NOT a use case, because logging in accomplishes nothing on its own; it is a precondition of the real goal. AN ACTOR is anything with behaviour that interacts with the system. Actors are ROLES, not people — one person may act as several actors, and one actor may be many people. PRIMARY ACTOR has a goal the system helps satisfy; the use case exists for them SUPPORTING ACTOR provides a service to the system (a payment gateway, an ID service) OFFSTAGE ACTOR has an interest in the outcome but does not interact — a regulator, an auditor. EASILY FORGOTTEN, and their interests are usually non-functional requirements or audit rules. A SYSTEM BOUNDARY must be decided before writing use cases: is the payment gateway inside the system (so paying is internal) or outside (so it is a supporting actor)? The same interaction is described differently depending on where the line is drawn, and drawing it is the first modelling decision. THE THREE LEVELS OF USE CASE (Cockburn), because a common error is mixing them in one model: SUMMARY / CLOUD spans multiple user sessions — "Manage the licensing lifecycle" USER GOAL / SEA what a primary actor accomplishes in one sitting; the SWEET SPOT and where a use case model should live — "Issue a licence" SUBFUNCTION / FISH a step that supports a user goal — "Validate a district code" THE ELEMENTARY BUSINESS PROCESS TEST for a user-goal-level use case: can one person, at one place, at one time, complete it, leaving the data in a consistent state? "Issue a licence" passes. "Validate a district code" fails (no value alone). "Manage licensing" fails (not one sitting).

THE FULLY DRESSED FORMAT — the standard template, and what each field is for. ───────────────────────────────────────────────────────────── USE CASE UC-05 Issue a Licence SCOPE Licence Management System LEVEL user goal PRIMARY ACTOR Counter Officer STAKEHOLDERS Counter Officer: wants to complete issuance AND INTERESTS quickly, without re-keying data Applicant: wants a correct licence today Revenue Department: wants the fee recorded against the correct district Auditor: wants a non-repudiable record of who issued what and when PRECONDITIONS the officer is authenticated and authorised; the application status is APPROVED; the fee is unpaid SUCCESS the licence exists with a unique number and GUARANTEE is printed; status is ISSUED; the fee is recorded; an audit entry exists MINIMAL no licence number is consumed without a GUARANTEE recorded issuance; the fee is either recorded or not taken TRIGGER the applicant presents an approved application at the counter ───────────────────────────────────────────────────────────── MAIN SUCCESS SCENARIO 1. Officer enters the application number. 2. System displays the approved application and the fee due. 3. Officer confirms the applicant's identity. 4. Officer records the fee payment. 5. System allocates a licence number and records status ISSUED with an audit entry. 6. System prints the licence. 7. System notifies the applicant by SMS. ───────────────────────────────────────────────────────────── EXTENSIONS 2a. Application not found → system reports it; officer re-enters or refers the applicant to enquiries. 2b. Application not APPROVED → system refuses and shows the current status; use case ends. 3a. ID service unreachable → officer may proceed with a manual check, recording the reason (see the supplementary spec on external dependencies). 3b. Identity mismatch → status returns to UNDER_REVIEW; no licence issued; use case ends in failure. 4a. Payment gateway times out after charging → the payment reference is queued for reconciliation; the officer may continue, and the fee is confirmed asynchronously. 5a. Licence number pool exhausted → system alerts the administrator; use case ends in failure with no number consumed. 6a. Printer fails → the number is already allocated, so the system permits REPRINT of the same number and never allocates a second. 7a. SMS provider rejects the number → the licence remains ISSUED; notification failure is logged, not rolled back. ───────────────────────────────────────────────────────────── SPECIAL REQUIREMENTS steps 1–6 shall complete within 20 s at the p95 (see supplementary specification); the audit entry shall be immutable ───────────────────────────────────────────────────────────── COUNT WHAT THE FORMAT PRODUCED: 7 main steps 8 extensions 4 stakeholders with distinct interests 2 guarantees, one for success and one for failure THE MINIMAL GUARANTEE IS THE MOST UNDERUSED FIELD in the whole template, and the most valuable. It states what holds even when the use case FAILS — and writing it is what forces you to think about the licence-number-consumed-but-not-issued case (5a) and the money-taken-but-not-recorded case (4a). Those are the defects that reach production. THE EXTENSIONS ARE WHERE THE REQUIREMENTS ARE. Note that 3a, 4a and 6a each encode a rule an officer knows tacitly and would never volunteer in an interview — exactly the finding from the elicitation topic. The main scenario is easy to get; the extensions are the work.

THE THREE USE CASE RELATIONSHIPS — frequently examined, and frequently misused: INCLUDE «include» One use case unconditionally uses the behaviour of another. Factor out behaviour shared by several use cases. Issue a Licence ──«include»──▶ Record Payment Renew a Licence ──«include»──▶ Record Payment THE TEST: is the included behaviour genuinely shared, and does extracting it make the base use case easier to read? If it is used once, do not extract it. EXTEND «extend» One use case CONDITIONALLY adds behaviour to another at a defined extension point. The base use case is complete without it. Issue a Licence ◀──«extend»── Apply Senior Discount Direction matters: the ARROW POINTS TO THE BASE use case, because the extension knows about the base and not the reverse. GENERALISATION One use case is a specialised form of another, inheriting and overriding its behaviour. Used sparingly; it confuses readers more often than it helps. ACTOR GENERALISATION is also possible and often more useful: Reviewing Officer and Counter Officer both generalise to Officer, which owns the shared authentication behaviour. THE USE CASE DIAGRAM shows actors, use cases, the system boundary and these relationships. IT IS AN INDEX, NOT A SPECIFICATION — the value is in the written text, and the diagram exists so a reader can see the scope at a glance. ITS DELIBERATE LIMITATIONS, which you must be able to state: · it shows NO SEQUENCE — you cannot tell what happens first · it shows NO CONDITIONS or data · it CANNOT EXPRESS NON-FUNCTIONAL REQUIREMENTS. "Within 2 seconds" has no notation. This is why the supplementary specification exists, and why a project that captures only use cases has nothing to drive architectural design. THE TRAPS — the recognisable failure modes: FUNCTIONAL DECOMPOSITION IN DISGUISE A model of 60 use cases named "Validate Fee", "Compute Tax", "Format Receipt". These are subfunctions, not user goals, and the model has become a function list with a use-case diagram drawn round it. THE DIAGNOSTIC: apply the elementary business process test. If completing it gives the actor nothing, it is not a user-goal use case. CRUD USE CASES "Create Applicant", "Read Applicant", "Update Applicant", "Delete Applicant" — four use cases where one ("Manage Applicant Records") or none is appropriate. CRUD is a persistence concern, not a user goal. THE USER INTERFACE LEAKING IN "Officer clicks the Issue button and the modal appears." That fixes a UI design inside a requirement, removing design freedom for no requirement-level reason. Write "the officer requests issuance"; the widget is a design decision. MISSING EXTENSIONS A use case model of clean main scenarios and no failure paths is a description of the demo, not of the system. Roughly speaking the extensions outnumber the main steps in any real use case — in UC-05 above, 8 against 7. OVER-USE OF «include» AND «extend» A diagram with more relationship arrows than use cases is harder to read than the redundancy it eliminated. These relationships are an optimisation, applied only when they reduce total effort. USE CASES VERSUS USER STORIES — the comparison worth having: USER STORY "As a counter officer I want to issue a licence so that the applicant can drive legally." Deliberately brief — a placeholder for a conversation, with the detail in acceptance criteria. USE CASE the full narrative with all extensions, guarantees and stakeholders. They are not rivals: a story is a planning unit sized for an iteration; a use case is an analysis artefact that captures a complete interaction. A story's acceptance criteria are typically the use case's extensions, written as tests. THE EXTENSIONS ARE THE VALUABLE CONTENT IN BOTH FORMATS.