What should Use Case Documentation include?
It documents each use case as a flow of actions from the actor's viewpoint — how it starts, how it ends, the normal sequence, and the exceptions — with special emphasis on the actor-to-system interface.
The diagram only shows that an actor uses a use case; the documentation is where you nail down how the interaction actually runs, so developers and testers have something concrete to build and verify against. The core fields are:
| Element | Description |
|---|---|
| Initiation | How the use case is started (the trigger) |
| Termination | How the use case ends (success and failure exits) |
| Control flow | The normal, happy-path sequence of steps |
| Exceptions | When things go wrong and how the system reacts |
It's also standard to record pre-conditions (what must hold before the UC can begin) and post-conditions (what's guaranteed true once it finishes), since these become the contract a tester checks.
Why the emphasis on the interface and on exceptions: the actor-system boundary is exactly where untrusted input enters and where error handling is most security-relevant — a use case that documents only its happy path leaves every failure mode unspecified, and unspecified failure modes are where attackers live.