A use case is written at THREE INCREASING DEGREES OF DETAIL (Larman's terminology), and the point is that you do not write them all at once. BRIEF A one-paragraph summary, usually of the main success scenario. Written during early requirements work, for ALL use cases, to get a quick sense of scope. "Issue a Licence: a counter officer verifies an approved application, records the fee, and the system allocates a licence number, records the issuance and prints the licence." CASUAL An informal paragraph format, covering several scenarios including some alternatives. Still prose, but the failure paths appear. "…if the identity service is unavailable the officer may perform a manual check, recording the reason. If the printer fails, the licence may be reprinted with the same number…" FULLY DRESSED All steps and variations written in detail, with the supporting sections — preconditions, guarantees, stakeholders and interests, special requirements. The template from ACtE0804. THE ECONOMICS OF WHEN TO WRITE EACH: inception → BRIEF for all use cases; fully dressed for perhaps 10% (the architecturally significant ones) each → FULLY DRESSED for the use cases in the NEXT iteration iteration, written just before design begins never → fully dressed for use cases that may be cut WHY: elaborating a use case costs real effort — perhaps 4–8 hours including the conversations — and a use case that is cancelled, deferred or substantially reconceived returns none of it. From the requirements management topic, volatile requirements should not be detailed early. A CONCRETE ESTIMATE. Suppose 30 use cases, 8 hours each to elaborate fully: elaborate ALL up front = 240 hours = 30 person-days if experience says 30% of use cases change substantially before being built, then 0.30 × 240 = 72 hours is rewritten or discarded elaborate JUST IN TIME = 240 hours spread over the project, with the 72 hours of churn avoided because the detail is written after the changes are known A 30% SAVING ON ELABORATION EFFORT, and — more valuable — the detail is written when the team knows most about the domain rather than least.

THE ELABORATION ACTIVITIES, in order, using UC-05 as the example. 1. CONFIRM THE ACTORS, THE GOAL AND THE LEVEL. Is this still a user-goal use case? Has the primary actor changed? Here: Counter Officer, user-goal level, unchanged. 2. WRITE THE MAIN SUCCESS SCENARIO as numbered steps. THE STYLE RULES that make steps designable: · each step is an ACTOR ACTION or a SYSTEM RESPONSE, and it is clear which · use the domain vocabulary from the glossary · avoid UI detail — "the officer requests issuance", not "the officer clicks the Issue button" · one step, one thing; a step containing "and" is usually two steps · state the DATA that moves, because that is what becomes a method parameter 3. WRITE THE EXTENSIONS, and this is the bulk of the work. The systematic way to find them — walk each step and ask four questions: (a) what if the actor supplies invalid data? (b) what if the system cannot do it — a resource is exhausted, an external service is down, a rule forbids it? (c) what if the actor abandons the interaction here? (d) what if two actors do this simultaneously? APPLIED TO STEP 5 ("system allocates a licence number and records status ISSUED"): (a) n/a — no actor data at this step (b) 5a. the licence number pool is exhausted → alert the administrator; no number consumed; failure (c) 5c. the officer's session expires mid-operation → the operation is atomic, so either it completed or it did not; no half-issued licence (d) 5d. TWO OFFICERS ISSUE THE SAME APPLICATION SIMULTANEOUSLY → only one succeeds; the second receives a conflict and sees the current status. THIS IS THE EXTENSION THAT REQUIRES THE `version` ATTRIBUTE from the design model topic. Question (d) is the one people never ask, and it is where concurrency defects come from. 4. IDENTIFY THE SPECIAL REQUIREMENTS — the non-functional constraints specific to this use case, which feed the supplementary specification. 5. DEFINE THE PRECONDITIONS AND THE GUARANTEES, including the minimal guarantee. From ACtE0804: this is what forces confrontation with the partially-completed cases. 6. CROSS-CHECK AGAINST THE DOMAIN MODEL. Every noun in the use case should be a concept, an attribute, or deliberately out of scope. A noun that is none of those is a gap in one artefact or the other. APPLIED: step 5 mentions "licence number", which requires a source — is there a LicenceNumberPool concept? It was not in the domain model. THE CROSS-CHECK FOUND A MISSING CONCEPT, which is exactly what it is for. 7. DERIVE THE ACCEPTANCE CRITERIA. Each extension becomes a test: given an approved application with an unpaid fee, when the officer issues it, then a licence number is allocated and the status is ISSUED given an exhausted number pool, when the officer issues, then no number is consumed and an administrator alert is raised given two simultaneous issuances of one application, when both are submitted, then exactly one succeeds THE EXTENSIONS ARE THE TEST CASES. This is the direct link from requirements to the test design of ACtE0803, and it is why extensions are the valuable part. 8. IDENTIFY THE SYSTEM OPERATIONS from the elaborated steps and draw the system sequence diagram — the handover to design.

THE RECURRING PROBLEMS IN ELABORATED USE CASES: UI DESIGN EMBEDDED IN THE STEPS "The system displays a modal with a green Confirm button." This fixes a design decision inside a requirement, and it means the use case must be rewritten when the UI changes even though the requirement has not. THE FIX: describe INTENT, not mechanism. "The system requests confirmation." STEPS THAT DESCRIBE INTERNAL PROCESSING "The system looks up the district, retrieves the fee rate, and multiplies by the category factor." That is design leaking into analysis. The use case should say "the system displays the fee due"; how it is computed belongs to the operation contract and the design. MISSING THE SIMULTANEITY CASE Question (d) above. Almost no use case written without a deliberate prompt contains a concurrency extension, and almost every real system needs one. EXTENSIONS THAT ARE ACTUALLY SEPARATE USE CASES If an extension has its own goal, its own stakeholders and several steps of its own, it is a use case. "5e. the applicant disputes the fee → a dispute process begins…" is a separate use case, referenced rather than inlined. THE HAPPY-PATH-ONLY USE CASE Main scenario complete, extensions absent. It describes the demonstration, not the system, and it will be signed off because it reads well. OVER-ELABORATION Thirty extensions covering every conceivable failure of every library. Elaborate the extensions that represent DIFFERENT BUSINESS OUTCOMES; group the ones that all mean "the request failed, report it and stop". THE QUALITY CHECKLIST for an elaborated use case — the questions worth asking in review: · is the primary actor's GOAL achieved by the main scenario, and is that goal worth a use case? · is every step either an actor action or a system response, unambiguously? · is the use case free of UI and internal-processing detail? · does every step that could fail have an extension, or a stated reason it cannot? · is there a CONCURRENCY extension where two actors could collide? · are the preconditions the minimum necessary, and are they checkable? · does the MINIMAL GUARANTEE hold on every failure path? · is every noun a domain-model concept or attribute? · can each extension be written as a test? · is the special-requirements section populated, or was it skipped? THE MOST PRODUCTIVE SINGLE QUESTION IN THE LIST: "does the minimal guarantee hold on every failure path?" It is a cross-check between two parts of the same document, and it is where the states that should be impossible get discovered — the licence number consumed without an issuance, the fee taken without a record. Those are the defects that survive testing and reach an auditor.