Every use case article on the internet gives you the same thing: a template with section headings and a login example. Preconditions, main flow, alternate flows, postconditions. You can find that template in thirty seconds, and it will not save you, because the template was never the hard part.
The hard part is that your first real use case will be wrong in ways the template cannot show you. It will have UI instructions dressed up as steps. It will mix alternate flows with exception flows. It will have a trigger that is not a trigger and postconditions that restate the last step. You will not see any of this, because it looks like the template.
So this article does something different. Below is one realistic use case written twice. First the way career switchers actually write it on attempt one, with every flaw annotated. Then the same use case rewritten properly, with the reasoning for each fix. Same fictional company throughout, and the finished version is downloadable as a PDF at the end, free, no email address required.
If you want to see a use case in the context of a full portfolio project, with the stakeholder register and requirements it traces back to, that is covered in the complete business analyst portfolio example. This article goes deep on the single artifact instead.
The project context
A use case without context is a login form. Here is the brief everything below hangs off:
FlexWell Gyms runs 40 branches. Members currently cancel by phoning their home branch or cancelling their bank mandate, which creates failed-payment chases and angry reviews. Cancellations arriving via the bank rather than the gym run at 31% of all cancellations. The business wants online self-serve cancellation with one save offer shown before the member confirms. Retention owns the save offer. Finance needs a clean final-payment calculation. The member portal exists; this flow is being added to it.
Notice the tension baked in: the business wants cancellation to be easy enough that members stop going via their bank, but retention wants one shot at saving them. That tension is what makes this worth writing a use case about, and it is exactly the kind of thing the bad version below fails to handle.
The bad version, annotated
This is not a parody. Every flaw below appears constantly in first attempts, and the whole thing looks fine at a glance because the section headings are right. The annotations are in bold brackets.
Use Case: Cancellation
[A1: "Cancellation" is a topic, not a goal. A use case is named actor plus verb plus object: what is someone trying to achieve? This name cannot tell you whether the use case covers a member cancelling online, a staff member processing a cancellation, or finance reversing one.]
Actor: User
[A2: Which user? FlexWell has members, branch staff, retention agents, and finance. "User" hides the most important scoping decision in the document. This use case will drift between actors precisely because nobody decided whose goal it serves.]
Preconditions: The user wants to cancel.
[A3: A precondition is a system-checkable state that must be true before the use case can start, such as "the member is authenticated" or "the membership status is Active". A desire is not checkable. This precondition also does real damage later: because nothing established what state the membership must be in, the flows below never handle members in a notice period, members who are frozen, or members mid payment dispute.]
Trigger: The user logs in.
[A4: Logging in is not the trigger for cancellation; thousands of members log in daily to book classes. The trigger is the member initiating cancellation. Confusing "the first thing that happens chronologically" with "the event that starts this use case" is probably the single most common trigger mistake.]
Main flow:
1. The user goes to the website and logs in with their email and password.
[A5: Authentication is its own use case. Including it here means every use case in the system repeats these steps, and when login changes to support SSO, forty documents are wrong.]
2. The user clicks on "My Account" in the top navigation bar, then clicks the "Membership" tab.
3. The user scrolls down and clicks the red "Cancel Membership" button.
[A6: Steps 2 and 3 are UI navigation, not behaviour. "Top navigation bar", "red button", "scrolls down": none of this is a requirement, all of it changes in the next redesign, and a developer reading it learns nothing about what the system must do. A step is an intent and a response: the member requests cancellation, the system responds with something.]
4. The system shows a popup asking "Are you sure?" and the user clicks Yes.
[A7: Two problems. First, "popup" is UI again. Second, and much worse: the brief says retention gets one save offer before confirmation, and this flow skips it entirely. The bad version has silently dropped the most commercially important requirement in the project. This is what happens when you write the use case from imagination instead of from the stakeholder needs: the happy path you imagine is not the happy path the business asked for.]
5. The system cancels the membership and sends an email.
[A8: "Cancels the membership" is doing an enormous amount of hidden work. What is the end date? The brief says finance needs a clean final-payment calculation: is there a notice period, a pro-rated final charge, a refund? One vague step is concealing three real requirements. And "sends an email" saying what?]
6. The user is logged out.
[A9: Why? No stakeholder asked for this. Invented steps sneak in because they feel like closure. Every step should trace to a need; this traces to nothing.]
Alternate flows:
A. The user enters the wrong password: the system shows an error.
[A10: Belongs to the login use case that should not be here at all (see A5).]
B. The payment system is down: the system shows an error and the user cannot cancel.
[A11: This is an exception flow, not an alternate flow, and the distinction is not pedantry. An alternate flow reaches the goal by another route; an exception flow fails to reach it. Filing failures under "alternate" means nobody has decided what the safe failed state is. Worse, "the user cannot cancel" is exactly the outcome the project exists to eliminate: a member who cannot cancel online goes back to cancelling via their bank, which is the 31% problem. The exception flow needed a real decision here, and mislabelling it let the author avoid making one.]
C. The user changes their mind and does not click the button.
[A12: Not a flow at all. The use case simply never starts. Padding like this appears when the author feels the alternate flows section looks thin.]
Postconditions: The membership is cancelled and the user gets an email.
[A13: Restates step 5 and stops. Real postconditions answer: what is true about the world afterwards, in every outcome? What is the membership status, the end date, the final payment state, the access rights? And there is no failure postcondition at all, because the failure path was mislabelled and never thought through (A11).]
Thirteen annotations, and the summary is shorter than the list: the bad version describes clicking, not behaviour; it serves no one actor; it lost a core business requirement; and it never decided what happens when things fail. The section headings were all correct. The template was followed. The template did not help.
The good version
Same company, same flow, written properly. Read it once top to bottom, then the reasoning below.
UC-01: Cancel membership online
Primary actor: Member Supporting actors: Billing service, retention offer service, email service Stakeholders and interests:
- Member: cancel quickly, know the end date and final payment, no phone call
- Retention: exactly one save offer presented before confirmation
- Finance: final payment calculated per the notice-period rule, no manual correction
- Branch operations: fewer bank-mandate cancellations and failed-payment chases
Preconditions:
- The member is authenticated in the member portal
- The membership status is Active or Frozen
- No payment dispute is open on the account
Trigger: The member initiates cancellation from their membership overview.
Main flow:
- The member requests cancellation of their membership.
- The system displays the consequences of cancelling: the end date per the 30-day notice period, the final payment amount, and the date access ends.
- The member confirms they wish to proceed.
- The system requests a save offer from the retention offer service and presents it to the member.
- The member declines the offer.
- The system asks the member to confirm cancellation, restating the end date and final payment.
- The member confirms.
- The system sets the membership status to Cancelled, records the end date, and schedules the final payment with the billing service.
- The system sends the member a cancellation confirmation stating the end date, the final payment amount and date, and how to rejoin.
- The system records the cancellation reason category and save-offer outcome for retention reporting.
Alternate flows:
- 4a. No save offer is available for this member. The retention offer service returns no offer (for example, the member has received one within the past 12 months). The system proceeds directly to step 6. (The member still reaches the goal; retention's one-offer rule is preserved in both directions: never zero when eligible, never two.)
- 5a. The member accepts the save offer. The system applies the offer, confirms the new terms to the member, and the use case ends with the membership remaining Active under the offer terms. (A success, but a different success: this exit satisfies the retention stakeholder rather than the cancelling member's original goal, and the postconditions below cover it separately.)
- 2a. The membership is Frozen. The system displays the consequences based on the frozen state: the notice period runs from the unfreeze date, and the final payment reflects the frozen rate. The flow continues at step 3.
Exception flows:
- 8a. The billing service does not acknowledge the final-payment scheduling. The system still sets the membership to Cancelled and records the end date, flags the account for finance review, informs the member that cancellation is confirmed and that final-payment details will follow by email within one business day, and raises an operations task. (Decision made explicit: the member's cancellation must never fail because of an internal billing fault, or they go back to cancelling via their bank, which is the 31% problem this project exists to fix. The failure is absorbed internally, not passed to the member.)
- 4b. The retention offer service does not respond within 3 seconds. The system proceeds to step 6 without an offer and logs the miss for retention. (Retention loses one save attempt; the member's cancellation is never blocked by retention's infrastructure. This ranks the stakeholders' interests, which is the analyst's job, and it is written down so retention can object now rather than in production.)
Postconditions:
- Success (cancellation): membership status is Cancelled with a recorded end date; access remains until that date; the final payment is scheduled or flagged for finance review; the member holds a written confirmation; the reason category and offer outcome are recorded.
- Success (saved): membership remains Active under the accepted offer terms; the offer redemption is recorded; no cancellation exists on the account.
- Failure: the membership status is unchanged, no partial cancellation state exists, and any incomplete attempt is logged.
Business rules:
- BR-01 Notice period is 30 days from confirmation, or from the unfreeze date for frozen memberships.
- BR-02 A member is offered at most one save offer per rolling 12 months.
- BR-03 The final payment is pro-rated to the end date per the standard rate card; frozen periods bill at the frozen rate.
Open question: May a member who accepted a save offer cancel again inside the same notice window, and if so, does BR-02 block a second offer? Owner: retention lead. Not blocking build of the main flow.
Why each fix matters
The name and actor scope everything else. "Cancel membership online", primary actor Member, immediately excludes staff-processed cancellations and finance reversals: those are different use cases with different flows. The bad version's drift, where login steps and payment errors and hypothetical non-actions all pile in, becomes impossible once one actor's one goal is fixed at the top.
Stakeholders and interests is the section templates skip, and it is where the analysis lives. Four stakeholders, four interests, and two of them are in tension. Writing them down forced the two decisions the bad version never made: the save offer belongs in the main flow (retention's interest), and no internal failure may block the member (the member's interest and the 31% problem). Every controversial line in the flows traces back to this section.
Steps are intent and response, not navigation. Compare bad step 3 ("scrolls down and clicks the red Cancel Membership button") with good step 1 ("the member requests cancellation"). The second survives a redesign, works for the mobile app, and tells the developer what matters: there must be a way to request cancellation. Ten steps, no screens, no buttons, and yet a developer could build from it and a tester could test against it.
Alternate reaches the goal, exception does not, and the sorting is a decision, not a label. Flow 5a (member accepts the offer) is alternate: someone succeeds, just not the way the use case's name suggests. Flow 8a (billing fails) is exception territory handled deliberately: the analyst decided the member-facing outcome still succeeds while the internal failure is contained. The bad version's flow B filed the same situation under "alternate", wrote "the user cannot cancel", and moved on. The label mistake and the thinking mistake are the same mistake.
Postconditions per outcome are what make the use case testable. Three postcondition sets, one per exit. A tester can now write: cancel with billing down, assert status Cancelled, assert finance flag raised, assert member email sent. Against the bad version's "the membership is cancelled and the user gets an email", there is nothing to assert when anything goes wrong, because nothing was decided.
The open question stays in. The rejoin-after-save-offer edge case is unresolved, has an owner, and is marked non-blocking. Removing it would make the document look more finished and be less honest. As with the portfolio artifacts, analysis with zero open questions was performed on a problem that did not exist.
Download the finished artifact
The good version above is available as a formatted PDF, the way it would land in a requirements pack or a portfolio: download the FlexWell use case PDF. Free, no email address, no signup. Use it as a reference for structure, then write your own on a different domain, because every reader of this page now has FlexWell.
That, incidentally, is a deliberate contrast. The standard move in this space is a blank template behind an email gate. A blank template is the thing this article opened by saying will not save you. A completed artifact you can hold next to your own attempt is worth more, so that is what is here.
Write one yourself, then check it against this list
Reading the annotations is not the same as catching the flaws in your own work. Pick a flow you know from any job you have had: a return at a retail counter, a shift-swap request, an expense claim. Write the use case, wait a day, then audit it against the bad version's thirteen annotations. A1, A2, A6, A11, and A13 are the five that survive almost every first attempt.
If you want the audit done for you, with a grade and specific feedback rather than a checklist, that is what BAvolta's Case Lab does: you work a realistic case end to end, produce the artifacts including a use case, and get structured critique on each one. The finished artifacts export to PDF, like the sample above, and land in your portfolio. Case Lab sits behind an account; to see how the material is built first, try a free lesson, no signup needed.
Frequently Asked Questions
What is the difference between an alternate flow and an exception flow?
An alternate flow is a different route to the same goal: the actor still succeeds, just not via the main path. An exception flow is a route to failure: the use case ends without reaching its goal, and the postconditions describe a safe failed state. If the actor still gets what they came for, it is alternate. If they do not, it is exception.
How long should a use case be?
As long as the behaviour requires and no longer. A well-scoped use case typically runs one to two pages: a main flow of five to twelve steps, a handful of alternate and exception flows, and explicit pre- and postconditions. If it is much longer, the scope is probably two use cases wearing one name.
Should use case steps mention buttons, screens, or specific UI elements?
No. Steps describe the interaction between actor and system in terms of intent and response, not interface. UI details change constantly and belong to design. A step like the member confirms the cancellation survives a redesign; the member clicks the red button in the top right does not.
How many use cases does a typical project need?
One per actor goal, not one per screen or feature. A membership cancellation project might need three to six: cancel membership, pause membership, process a save offer, reinstate a lapsed membership. If you have twenty, you have probably written scenarios or test cases and labelled them use cases.
Do agile teams still write use cases?
Many do, usually alongside user stories rather than instead of them. A user story captures the goal and the conversation; a use case captures the detailed behaviour, especially alternate and exception paths, which stories tend to leave implicit. On complex flows the use case is often what the story expands into once development gets close.
Is a use case the same as a user story?
No. A user story is a short placeholder for a conversation: as a member, I want to cancel online so that I do not have to phone. A use case is a structured specification of the whole interaction, including what happens when things go wrong. Stories fit in a backlog; use cases document behaviour.