Techniques BABOK Guide v3, 10.47
Use Cases and Scenarios
In short A use case describes how an actor, a person or another system, uses the solution to reach a goal: a numbered main scenario plus the alternative and failure paths. It gives you functional requirements that business people can read and testers can turn into tests.
Based on: IIBA, BABOK® Guide v3, technique 10.47 “Use Cases and Scenarios”; A. Cockburn, Writing Effective Use Cases, ch. 2, 5, 11; D. Paul, D. Yeates, J. Cadle (eds.), Business Analysis (BCS), 2nd ed., ch. 11; Yu. A. Maglinets, Analysis of Requirements for Information Systems (in Russian), lectures 4–5; RUP document templates.
On this page
What it is#
In the BABOK® Guide, a use case describes how an actor interacts with a solution to accomplish a goal, through a main sequence of steps and alternative sequences. A scenario is one path through a use case: the main success scenario, or one alternative or failure path.
A contract for behavior. Alistair Cockburn (ch. 2) sees a use case as an agreement among stakeholders who have interests in the system. Some interact directly, above all the primary actor, who wants the goal. Others stay offstage, such as a regulator or the finance team, but the system must still protect their interests. Every use case ends in success or failure of the goal, so Cockburn’s template has two guarantees: minimal guarantees (what is protected even if the goal fails) and success guarantees (what is true when it succeeds).
Goal level. Cockburn (ch. 5) names levels such as summary, user goal (“sea level”), and subfunction. Write most use cases at user-goal level: something the primary actor completes in one sitting and walks away satisfied. “Log in” is not a user goal. A well-calibrated use case has roughly 3 to 10 steps. See Cockburn’s Three Named Goal Levels.
The diagram. The BCS book (ch. 11) describes the UML use case diagram: actors as stick figures (an external system as a box marked <<actor>>; time can also be an actor), use cases as ovals named verb-noun, a system boundary with the actors outside, and association lines. <<include>> moves shared steps into a use case that several others reuse; <<extend>> moves an optional, sizeable piece of behavior into its own use case. The diagram does not show the order of use cases. It is useful in workshops and for prioritizing the whole scope.
Formats. Cockburn’s fully dressed template (ch. 11) is the basis of the template below. The RUP template is leaner: name and description, flow of events, special requirements, preconditions, postconditions, extension points. Two- or three-column tables (step, actor, system) also work. Maglinets, retelling Cockburn, links formality to criticality: the more a failure would cost, up to risk to life, the more formal the description.
When to use it#
- Interactive functionality with branches and error handling.
- When you need a stable, readable specification, such as an SRS, a contract, or a regulated system.
- To find missing requirements: extensions surface the “what if” cases.
- BABOK tasks such as Specify and Model Requirements (7.1) and Maintain Requirements (5.2).
Prefer user stories for small increments discussed just in time in an agile team, process models for work spanning many actors and days, and decision tables for complex conditions.
How to do it#
- Find the actors from the scope model and stakeholder list.
- List each actor’s goals and name use cases as verb plus object at user-goal level.
- Draw the use case diagram to agree the scope.
- Write the main success scenario: 3–10 steps, each saying who does what, with no screen details.
- Brainstorm extensions: at every step, ask what could differ or fail. Number them by step (3a, 3b).
- Add preconditions, trigger, and guarantees.
- Factor out shared steps into included use cases and rules into the rules catalog.
- Review with users and testers, and derive one test scenario per path.
Template#
Use case: UC-<id> <Verb + object>
Level: user goal | summary | subfunction Scope: <system>
Primary actor: <role>
Stakeholders and interests:
- <stakeholder>: <what must be achieved or protected>
Preconditions: <what is already true>
Trigger: <event that starts the use case>
Minimal guarantees: <true even if the goal fails>
Success guarantees: <true when the goal is met>
Main success scenario:
1. <Actor> <does something>.
2. System <responds>.
3. ...
Extensions:
2a. <Condition>:
2a1. <Step>.
2a2. <Return to step n / use case ends>.
Special requirements: <non-functional requirements for this use case>
Open issues: <list>
Example#
A use case for The Workshop, a fictional chain of bike-repair workshops (compare the user story for a related feature on the User Stories page):
Use case: UC-03 Book a repair slot Level: user goal
Primary actor: Customer
Stakeholders and interests:
- Workshop manager: no double bookings
- Front desk: every booking appears on the daily schedule
Preconditions: none (guest booking allowed)
Trigger: Customer chooses "Book a repair"
Minimal guarantees: no slot stays reserved without a confirmed booking
Success guarantees: slot reserved, booking on schedule, confirmation sent
Main success scenario:
1. Customer selects a workshop and a repair type.
2. System shows free slots for the next two weeks.
3. Customer picks a slot and enters name, phone, and bike details.
4. System holds the slot and shows a summary.
5. Customer confirms.
6. System records the booking and sends a confirmation.
Extensions:
2a. No free slots: System offers the nearest workshop with free slots;
customer picks one (back to step 2) or leaves (use case ends).
3a. Slot taken meanwhile: System says so; back to step 2.
5a. Customer does not confirm within 10 minutes: System releases the slot.
6a. Confirmation cannot be delivered: System shows the booking reference
on screen and flags the booking for a front-desk call.
Common mistakes#
- Screen details in steps (“clicks the green button”) → describe intent (“customer picks a slot”).
- Wrong goal level → fold subfunctions such as “Log in” or “Enter phone number” into user-goal use cases.
- Too many steps → more than about ten usually means screen detail or a level that is too low.
- No extensions → they are where most missing requirements hide.
- Only a success outcome → state minimal guarantees for failure too.
- Overusing include and extend → keep the diagram readable; the text carries the detail.
- A diagram with no text → ovals alone are not requirements.
Sources and further reading#
- IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015, technique 10.47 “Use Cases and Scenarios”.
- A. Cockburn. Writing Effective Use Cases. Addison-Wesley, 2000, ch. 2 (use case as a contract for behavior), ch. 5 (goal levels), ch. 11, section 11.1 (fully dressed template).
- D. Paul, D. Yeates, J. Cadle (eds.). Business Analysis, 2nd ed. BCS, The Chartered Institute for IT, 2010, ch. 11 (use case diagrams, include and extend).
- Yu. A. Maglinets. Analysis of Requirements for Information Systems, lecture notes (in Russian). Siberian Federal University, 2007, lectures 4–5.
- IBM Rational Unified Process (RUP) document templates: Vision, Software Requirements Specification, Requirements Management Plan.
- Business analysis training materials (paired use case and user story example).