An elaborated requirement tells you what the system must do. It does not tell you what actually happens, step by step, when a person tries to do it, and those are different things.
The gap between them is where a surprising amount of delivery risk lives. A requirement can be completely specified and still leave four people with four different mental models of the sequence. Use cases close that gap by making the sequence explicit.
What a use case contains
Generated from the elaborated requirement, each use case carries:
- Primary actor and stakeholders. Who is doing this, and who else has an interest in the outcome.
- Preconditions. What must already be true before the flow can start. This is where unstated assumptions surface.
- Trigger. What starts it, and of what kind.
- Main flow. Numbered steps, each naming an actor and an action. Not prose.
- Alternate flows. The named divergences, each with the condition that causes it and its own steps.
- Outcome. What is true when it finishes.
Each step names its actor explicitly. That sounds like a formality until you read a flow where the actor changes three times and nobody had noticed, which is a common way integration defects get designed in.
Alternate flows are the point
If you only read one section of a generated use case, read the alternate flows.
The main flow is usually already in everyone's head. It is the thing the requirement was written about, the thing the demo will show. It is also the flow least likely to produce a defect, precisely because everyone has thought about it.
Alternate flows are the paths the requirement implied without stating: the payment declines, the session expires mid-flow, the record was deleted by someone else between step two and step five, the user has permission to start but not to finish. Each one is a branch that will exist in the code whether or not anyone specified it. If it is not specified, it gets invented by whoever writes that line.
For each alternate flow, ask whether the system leaves the user somewhere recoverable. A flow that correctly detects a failure and then strands someone with no way forward is a defect that passes every test written against the main flow.
Where the model stops and Python starts
Generation is a single Gemini call working from the elaboration. What it does not do is anything deterministic.
Use case identifiers are assigned in Python. Step numbering is normalised in Python. Persistence and routing are Python. The model's job is confined to the semantic work: identifying goals, actors, and the flows that branch off the main one.
This split runs through the whole product, and the reason is consistency. If a model assigns identifiers, they are usually fine and occasionally duplicated or skipped, and you cannot tell which run you got. Deterministic work belongs to deterministic code.
Using them downstream
Use cases are not a documentation deliverable that gets filed after review. They are an input to test design.
A main flow with five steps and three alternate flows is not one test. It is at minimum a test of the main path plus one per branch, and the branches carry the higher information. When test design runs against a requirement that has use cases attached, the flows are available as structure rather than something the test generator has to infer from prose.
Key takeaways
- Use cases make the sequence explicit, which a fully specified requirement still leaves ambiguous.
- Alternate flows are where the value is, because they are the branches nobody wrote down.
- Every step names its actor, which exposes handoffs that would otherwise pass unnoticed.
- Identifiers and step numbering are deterministic Python, not model output.
When to generate them
Not for everything. A requirement describing a single field validation does not need a use case, and generating one produces ceremony rather than clarity.
They earn their place when a requirement involves a sequence with more than one actor, a flow that can fail partway, or a process where the order of steps carries rules of its own. If you cannot describe the requirement without using the word "then", it probably warrants a use case.