Business vs. System Use Cases
In short A business use case describes what happens in the business when someone outside it seeks a result; a system use case describes how a user works with an IT system to support part of that. Keeping the two apart helps you scope a project before you specify software.
Based on: A. Belin, Business Analysis: The Initiation Phase (UML for IT business analysts), training slides, 2005, slides 35–70.
On this page
Key ideas#
Two kinds of use case#
The distinction is not part of core UML (it is added through UML extensions), but it is common practice, and Belin makes it explicit:
- A business use case describes interaction with the business as a whole, not with an IT system. It is the sequence of actions that gives a valuable result to a specific business actor. Belin’s example from insurance: lodging a claim.
- A system use case describes interaction with an IT system that supports part of the business process. In the same example: register a claim, check the case, assign a handler. Each usually has one primary actor, is completed in one session, and leaves the user feeling they achieved something meaningful for the business.
The ordinary use cases most teams write are system use cases in this sense.
Who appears on a business use case diagram#
- Business actors: people or organizations outside the business, such as customers and suppliers.
- Workers: people inside the business. An extended notation splits them into case workers, who deal with external actors, and internal workers, who deal only with colleagues.
- Associations connecting actors to the use cases they take part in.
From business to system use cases: the BOOM steps#
Belin’s training presents BOOM (Business Object Oriented Modeling), a five-step approach that places this work in a project:
- Initiation: model business use cases, set scope, make early architecture choices. Comparable to Envisioning in MSF and Inception in RUP. In detail: (a) business use case diagrams, with activity diagrams for their content; (b) system use cases, finding actors through a role map and grouping use cases into packages; (c) a first class diagram of key business classes; (d) baseline a preliminary business requirements document (BRD).
- Discovery: full analysis of system behaviour, key architecture decisions, the peak of requirements work. It covers use case descriptions, state diagrams for key business objects, class diagrams with attributes and operations, test cases, an implementation plan, and a second baseline.
- Construction: design, coding, integration and testing. On waterfall projects analysis is finished by now; on agile projects the Discovery steps repeat in each iteration.
- Final verification and validation: final testing before go-live; the analyst checks that every requirement has been tested.
- Closeout: support deployment and take part in the post-implementation review.
Choosing a workflow notation#
To describe the content of a business use case you need a workflow notation. Belin compares five; in summary:
| Notation | Strong point | Weak point |
|---|---|---|
| System flowchart | Intuitive; a symbol for each kind of input and output | Not UML; many symbols to learn |
| Swimlane workflow diagram | Shows who does what | Not UML |
| Sequence diagram | UML; precise about who initiates and who performs each action | Often unintuitive for business readers |
| Activity diagram | UML; simple symbols; handles branches and parallel work on one diagram | Can grow too complex if you put every case on it |
| BPMN process diagram | Rich enough for subtle workflow rules | Not UML; hard to read without training |
Belin’s conclusion: the activity diagram is the most useful of the five for an IT business analyst, because both analysts and end users can read it.
The main elements of an activity diagram are a start node, actions, control flows, decisions with guard conditions in square brackets, merges, events (which hold the flow until something happens), forks and joins for parallel work, and an end node. Partitions (swimlanes) show who performs each action: one lane per actor, worker or, if needed, system.
How to apply it#
- Draw the business use cases first. Ask what results outside parties want from the business.
- Describe each with an activity diagram in swimlanes, one lane per actor or worker.
- Mark the actions the IT system will support. Each cluster of supported actions done by one person in one session is a candidate system use case.
- List system use cases with their primary actors and group them into packages.
- Sketch the key business classes that the use cases mention, as a first data model.
- Baseline the business requirements document before detailed specification starts.
Example#
At The Workshop (a fictional bike-repair chain), the business use case is “Get a bike repaired”. The business actor is the customer; the workers are front-desk staff (case workers) and mechanics (internal workers); the parts supplier is a second business actor.
An activity diagram with lanes for customer, front desk, mechanic and supplier shows: book, drop off, diagnose, order part if needed, repair, notify, collect and pay. A fork lets the mechanic start other work while the part is on order; a join waits for both before the repair finishes.
From this, the analyst identifies system use cases: Book repair slot (customer), Record bike drop-off (front desk), Update repair status (mechanic), Order spare part (workshop manager) and Send ready notification (triggered by the status change). “Diagnose the fault” stays a manual step with no system use case.
Pitfalls#
- Writing the IT system into a business use case. At the business level, describe what happens, not which screen is used.
- Treating every business step as a system use case. Some steps stay manual; leaving them out of scope is a decision to record.
- Overloaded activity diagrams. Split by scenario when one diagram becomes hard to follow.
Sources and further reading#
- A. Belin. Business Analysis: The Initiation Phase (UML for IT business analysts), training slides. Luxoft, 2005, slides 35–70.