Of all the techniques in this methodology, the use case document does the most work. It is started during the estimate, grows through pre-production, guides playtesting in production, and becomes the basis for validation at release. It turns a list of requirements into a picture of real people doing real tasks with your software.
The Template
A use case document has a predictable structure, so anyone on the project knows where to look. Download the template (Word)
- Title and picture. A clear project name, and an image of the real-world subject. It sounds trivial, but it sets the scene for everyone who opens the document.
- References. Links to the requirements, project overview, estimate, architecture and any background reading. If requirements don’t exist yet, say so; you may be proposing them.
- Mission. One or two sentences on who the customer is, what outcome they need, and why they are paying for it.
- Mission objectives or storyboard. What the users need to practice or accomplish in the real world, written or drawn.
- Solution overview.
- Product configuration: the physical setup, such as desktop PCs, VR headsets, replica controls, room size limits.
- User roles: who uses the system and what each does. Typically trainees, an instructor or administrator, and role players.
- Architecture: a simple diagram of the hardware and software involved.
- Risks: what could make this project fail: technical unknowns that make it hard to estimate, user risks that could lead to a poor experience, and anything else.
- High-level use case. The overall scenario from start to finish.
- Feature-specific use cases. One per major feature, each with:
- Goal: what the user is trying to do
- Relevant requirements: for traceability
- Steps: numbered, from the user’s point of view, what they do and what they see
- Notes and visual aids: sketches, screenshots, reference photos
- Placeholders and deprecated sections. Mark use cases still to be written, and keep rejected ideas in a clearly labeled section rather than deleting them. They explain past decisions.
On contract work, keep the signed version unchanged, and create a development version that covers only the scope actually being built, linked to the original.
A Worked Example
Here is a short, fictional example: a training simulator for wildland firefighting crews.
| Mission | A regional fire service wants crews to practice coordinating on a fire line before the season starts, without the cost and risk of live burns. |
|---|---|
| Mission objective | Crew leaders practice positioning crews, communicating by radio and reacting when the wind shifts. |
| Product configuration | Desktop PCs with mouse, keyboard and headsets in a classroom, one per trainee, plus an instructor station. |
| User roles | Crew leader (trainee): directs the crew and talks to dispatch. Crew members (trainees): dig line and operate equipment. Instructor: sets up the scenario, controls the weather and plays dispatch. |
| Risks | Fire spread may need a new simulation model. Radio communication may need integration with the customer’s real radios. |
Use case: Wind shift on the fire line
Goal: The crew leader recognizes a wind shift and moves the crew to safety.
- The instructor loads a hillside scenario with an active fire and sets a light westerly wind.
- The crew leader briefs the crew by radio and assigns positions along the line.
- Crew members dig line; each sees the fire’s edge and smoke drifting east.
- The instructor shifts the wind to the south. The smoke and fire spread visibly change direction.
- The crew leader notices, orders the crew to the safety zone, and reports to dispatch.
- The instructor pauses the scenario and replays it from above, showing each crew member’s route.
Even this short example raises the questions that drive an estimate. How realistic does fire spread need to be? Do the radios need to be real? Does the replay need to record every crew member? Those questions are the point: they surface before anyone has written a line of code.