The client’s operations director is halfway through acceptance testing when she stops. “This works if our finance manager approves it,” she says, “but she is on leave for most of December, and many of our requests arrive when the retainer is already used up. What happens then?” Nobody in the room knows. The requirement said “Manager approves the request.” The build does exactly that. It is still not what the client needs.
Knowing how to write use cases properly closes this gap: the main success path is only the beginning. Permissions, exceptions and business rules often decide whether the delivered result works in the client’s real operation, and they are the parts most often left unwritten.
The short answer: to write a use case that makes requirements testable, name one actor, one goal, the trigger, the preconditions and the success outcome. Write the main path as a short numbered sequence, then work through every step asking what could be different, and record those alternative and failure paths. Finally, turn each path and business rule into a true-or-false acceptance criterion with named test evidence.
Use case, user story, process map or acceptance test: which one do you need?
Confusing these four artefacts is how gaps appear between them.
| Artefact | Question it answers | Typical level |
|---|---|---|
| Process map | How does work flow across the whole business area? | Many activities, many roles |
| Use case | How does one actor reach one goal, including when things go differently? | One goal, several paths |
| User story | What does a user need next, and why? | One slice of value to plan and deliver |
| Acceptance test | How will we check that a specific criterion is met? | One condition, one expected result |
The IIBA puts it neatly: use cases define specific processes as sequential steps with alternate flows where necessary, while a process model collects the narratives for a whole business unit (IIBA: Why model business processes?). A process map shows where the use cases are, a use case exposes the paths and rules, user stories slice the work, and acceptance tests check each slice.
A use case is not a screen specification. “The user clicks Submit on the Request form” may change next sprint; “The client contact submits the request” stays true however the screen looks.
How to write use cases in six steps
On a small team one person may do every step, but the review and approval points should still involve different people.
| Step | Owner | Evidence | Decision point |
|---|---|---|---|
| 1. Choose the goal and decide the depth | Analyst or project manager | Process map, request list, charter scope | Full use case or brief criteria only? |
| 2. Write the header | Analyst | Discovery notes, interviews | Is the success outcome observable? |
| 3. Write the main success path | Analyst with a client user | Observed or described real work | Would the user recognise this as their work? |
| 4. Add alternative and failure paths | Analyst with client user and tester | Exceptions, workarounds, past incidents | Which paths are in scope for this release? |
| 5. Extract business rules and constraints | Analyst, confirmed by client authority | Contract, policy, regulation | Who owns each rule? |
| 6. Write criteria and trace them to tests | Analyst and tester | Draft test cases | Can every criterion be judged pass or fail? |
1. Choose one goal and decide how much to write
Name the goal from the actor’s point of view: “Get approved work started on a retainer request”, not “Request module”. Approvals, money, permissions or several roles earn a full use case; a one-path change does not.
2. Record actor, goal, trigger, preconditions and success outcome
The actor is a role, not a named person. The success outcome must be observable: “The request is approved and scheduled, and the client can see its status” can be checked; “The request is handled” cannot. Add a minimum guarantee: what must hold even if the goal fails, such as “no unapproved work is billed”.
3. Write the main success path
Five to nine numbered steps, alternating between actor and system (or team), each stating intent and result. If it needs twenty steps, you probably have two goals.
4. Walk every step and ask what could be different
This is where testability comes from. At each step ask: what if information is missing, permission is lacking, the limit is reached, the approver is away, or it arrives out of hours? Number each variation against its step (4a, 4b) and state how it ends: rejoins the main path, ends differently, or stops safely. The discovery practices in understanding the client’s business before you plan the solution surface the workarounds people already use when the official process breaks.
5. Connect business rules and constraints to the steps
Pull rules into a numbered list (BR1, BR2) referenced from the steps, so one rule can change without rewriting every path. An analyst can write a rule down, but only the client can decide it. Include non-functional constraints that affect acceptance, such as response times, audit records or access restrictions.
6. Turn paths and rules into acceptance criteria
The ISTQB acceptance testing syllabus describes acceptance criteria as measurable statements that are either true or false, produced by decomposing requirements into a more atomic and testable form, with acceptance tests derived from them. Criteria should state what shall be achieved rather than how, and cover non-functional requirements too (ISTQB Acceptance Testing syllabus, 2019, sections 0.2, 1.1.2 and 2.1).
A practical rule: every alternative path and every business rule should produce at least one criterion. If a path has no criterion, nobody will test it, and the client will find it for you.
Hypothetical example: a retainer service request
Hypothetical example. An IT consultancy supports a client on a 40-hour monthly retainer. Client staff raise requests; the consultancy classifies them, checks the allowance, obtains approval where needed and records the outcome.
| Field | Content |
|---|---|
| Use case | UC-03: Get a retainer request approved and scheduled |
| Primary actor | Client requester (any named client contact) |
| Supporting actors | Consultancy service lead; client approver (finance manager) |
| Trigger | A client contact submits a work request |
| Preconditions | Requester is a registered contact; the retainer is active for the current month |
| Success outcome | Request is classified, approved within the rules, scheduled with an owner, and its status is visible to the requester |
| Minimum guarantee | No work beyond the allowance starts without recorded approval; every request has a recorded outcome |
Main success path
- Requester submits the request with a description and required-by date.
- Service lead classifies it as in-retainer work and estimates the effort.
- Service lead checks the remaining allowance (BR1).
- Estimate fits the allowance (BR1), so no client approval is needed.
- Service lead schedules the work and assigns an owner.
- Requester is notified of the owner and planned date.
Alternative and failure paths
- 2a. Request is outside the retainer scope. Service lead records the reason and offers a separate quote. Use case ends; the request is not scheduled under the retainer.
- 2b. Description is insufficient to estimate. Service lead asks specific questions and records a follow-up date. Resumes at step 2 when answered.
- 4a. Estimate exceeds the remaining allowance. Service lead sends the estimate and overage to the client approver (BR2) and records the decision (BR4). On approval, resumes at step 5. On rejection, the requester is told and the request is closed or deferred to next month.
- 4b. Approver does not respond within the expected window (BR6). Service lead sends one reminder and tells the requester the request is waiting for approval. Work does not start (BR3).
- 4c. Allowance is exhausted and the named approver is unavailable. See the exception below.
Business rules
- BR1 (owner: client retainer sponsor). Remaining allowance equals 40 hours minus time logged and time committed to approved work this month. An estimate equal to the remaining allowance counts as fitting.
- BR2 (owner: client retainer sponsor). Work that would exceed the allowance requires approval from the client’s named approver before it starts.
- BR3 (owner: client retainer sponsor). Unapproved over-allowance work may not start, except requests classified as a service outage, which may proceed up to 4 hours and must be reported to the approver the same day.
- BR4 (owner: client finance manager). Every approval or rejection is recorded with the approver’s name and date.
- BR6 (owner: client retainer sponsor). The approver is expected to respond within two business days. (BR5 is reserved for the proposed delegate rule below.)
Open questions
- OQ1. May the client name a delegate approver? Owner: client retainer sponsor. Decide by: before build starts.
The difficult exception
It is 10 December. The allowance is used up, the finance manager is on leave until 6 January, and the operations director asks for an urgent report change needed for a board meeting on 17 December. It is not an outage, so BR3’s exception does not apply.
Walking path 4c exposes a question nobody asked in discovery: can anyone else approve? The retainer agreement names one approver and no delegate. This is not a decision the analyst or service lead can make. The correct action is to record it as OQ1, owned by the client’s retainer sponsor with a decision date, and to propose a rule: “BR5. The client may name one delegate approver in writing; a delegate’s approval is recorded as for BR4.” Until that is agreed, path 4c ends with the request waiting and the requester told why and who can unblock it.
Writing this before build costs a short conversation. Discovering it in December costs an unhappy director and an argument about who pays. It also belongs in your project risk identification.
From use case to acceptance: a simple traceability table
For most client work, a table with one row for each path and each rule, linking it to a criterion and its evidence, is enough; you do not need a dedicated traceability tool.
| Source | Acceptance criterion (true or false) | Test or evidence | Owner |
|---|---|---|---|
| Main path, BR1 | A request estimated within the remaining allowance is scheduled without an approval step | Test: 34 hours logged or committed, 6-hour request (exactly at the limit) | Tester |
| 2a | A request classified as outside retainer scope is not scheduled against the allowance and has a recorded reason and quote offer | Test | Tester |
| 2b | A request returned for clarification shows the questions asked and a follow-up date | Test | Tester |
| 4a, BR2 | A request whose estimate exceeds the remaining allowance cannot be scheduled until an approval is recorded | Test: 35 hours logged or committed, 6-hour request | Tester |
| 4b, BR6 | The requester can see that the request is waiting for approval, and a reminder is sent after two business days without a response | Test plus client user walkthrough | Client SME |
| BR3 | An outage request may start without approval, its time is capped at 4 hours pending approval, and the approver is notified the same day | Test: outage with allowance exhausted | Tester |
| BR4 | Each approval or rejection shows the approver’s name and date | Record inspection after test run | Service lead |
| 4c (before BR5 is agreed) | While no delegate rule is agreed, an over-allowance request with the approver absent stays unscheduled and the requester is told who can unblock it | Test | Tester |
| 4c, BR5 | Only the named approver, or a delegate named in writing, can approve an over-allowance request | Test after rule is agreed; signed delegate letter | Client sponsor |
Notice the edge values: 34 hours logged or committed leaves exactly 6, so a 6-hour request sits just inside the limit; at 35 it is just beyond. Testing either side of a limit is where allowance rules usually break.
The same method outside software: approving an advisory deliverable
Hypothetical example: an advisory firm needs its pricing report accepted by the client’s commercial director. Main path: draft issued, client reviews, comments resolved, final issued, acceptance recorded.
| Source | Acceptance criterion | Evidence | Owner |
|---|---|---|---|
| Main path | Every client comment has a recorded response: accepted, changed or explained | Comment log | Engagement manager |
| Alternative: reviewer disagrees with the data | A disputed figure is either corrected or its source is cited in the report | Revised appendix | Analyst |
| Rule: acceptance authority | Acceptance is recorded by the commercial director or a delegate named in the engagement letter | Signed acceptance note | Client sponsor |
If you have written a project charter for the engagement, the acceptance authority should already be named there. The use case makes it testable.
A use-case worksheet you can copy
Use this worksheet to document use cases for any goal that involves several roles, approvals or limits. Delete prompts that do not apply.
| Section | What to write | Quality check |
|---|---|---|
| Goal | One goal, in the actor’s words | Could you finish the sentence “the actor wants to…”? |
| Actors | Primary role, supporting roles | Roles, not names or systems |
| Trigger and preconditions | Starting event; what must already be true | Can a tester set these up? |
| Success outcome and minimum guarantee | Observable end state; what must hold even on failure | Could someone check it without asking you? |
| Main path | 5 to 9 numbered steps of intent and result | No screen or button names |
| Alternatives and failures | Numbered against the step they branch from, each with an ending | Missing data, permissions, limits, absence, timing considered? |
| Business rules and constraints | Numbered rules with the client owner of each | Every rule referenced by at least one step |
| Open questions | Question, owner, decision date | None owned by “the team” in general |
| Criteria and evidence | True-or-false statements linked to paths and rules | Every path and rule has at least one |
Before calling it ready, ask a client user to walk a recent real case through it and a tester to explain how they would fail each criterion. If either struggles, it is not finished.
Limits and the most common failure
Use cases describe behaviour toward a goal. Process flow still needs a process map, look and feel needs design work, and data migration is better specified separately. A use case records the agreed understanding; it is not a contract.
The most common failure is writing only the happy path and calling it complete. The second is writing screen specifications that must be rewritten whenever the design changes. The third is forty-page documents for small requests, which teach the client to stop reading. Match depth to consequence.
Keep use cases next to the work they describe
A use case helps only if the people building, testing and supporting the solution can find it. In Chronodesk project management, a built-in wiki keeps specifications attached to the project, alongside the tasks on Kanban and Gantt views where the team also logs time. The method works in any tool, though; what matters is that the criteria are agreed before build.
Your next step
Pick one current requirement that involves an approval, a limit or a permission. Write its header and main path, then spend twenty minutes with a client user asking “what if?” at each step. Put the answers in the worksheet, and take any rule the client must decide to your next status meeting with a named owner and date.
If the client rules depend on how their operation really works, start with understanding the client’s business; if the charter already names acceptance authority, reuse it from your project charter.
Frequently asked questions
What is the difference between a use case and a user story?
A user story states who needs something and why, and is refined through conversation and acceptance criteria. A use case describes how one actor reaches one goal step by step, including alternative and failure paths. Many teams use both: stories to plan, use cases when the paths and rules are complicated enough to write down.
Can use cases be used in agile projects?
Yes. A use case need not be complete before work starts. Sketch the main path and list the alternatives early, then slice it into user stories: the main path first, then one story per alternative path or rule, each carrying its traced criteria. The use case becomes the map showing which slices are still missing.
Who should write and approve use cases on a client project?
Whoever does the analysis drafts them: a business analyst, consultant or project manager. A client subject-matter expert checks the paths match real work, a tester checks each criterion can be tested, and a client representative with authority confirms the business rules. Even on a small team, rule decisions should sit with the client.
Do small requests need a formal use case?
No. Two or three acceptance criteria on the request are usually enough. A useful test is to ask what happens if the request is delivered wrongly: if the fix is quick and cheap, skip the use case; if it would mean rework, a billing dispute or a failed audit, write one.