Scenario-based modelling: actors, use cases and exceptions

An actor is a role, not a person

Modelling requirements in UML begins with scenarios, and every scenario starts with an actor. An actor models any entity that interacts with the system by exchanging information — a role played by a human stakeholder, or an external device, or another software system. The word role is doing real work here. One physical person may be portrayed by several actors if they take on several roles relevant to different system functions, and one actor may be realised by many people. In BorrowBox, Member and Librarian are two actors; Priya, who volunteers on Saturdays, is both, and the model does not care. Locker Controller is also an actor even though nobody sits behind it, because it is outside the software boundary and it exchanges information across that boundary.

A related idea is the user profile: the same system modelled from the viewpoint of a different class of user. A depot administrator's view of BorrowBox — hardware health, jam reports, stock levels — is a different profile of the same functionality that a member sees as reserve, collect, return.

A use case is a contract for behaviour

A use case is a narrative describing how a class of user achieves a goal by using the system, told from that user's point of view. Cockburn's phrase for it is a contract for behaviour, which is the right register: it commits the actor to a sequence of actions and the system to a sequence of responses. It is written in the stakeholders' language, not in notation, which is exactly what makes it reviewable by the people who paid for the system.

To start writing one, list the functions or activities a specific actor performs — from the list of required system functions, from conversations, or from an activity diagram you already have. Then answer four questions: what to write about, how much to write, how detailed to be, and how to organise it. The first three are judgement; the fourth has a standard answer.

The formal template

An informal narrative is often enough. When the use case covers a critical activity, or a complex set of steps with many exceptions, promote it to the formal template:

• Goal in context — the overall scope of the use case: what the actor is really trying to achieve.
• Preconditions — what is known to be true before it starts.
• Trigger — the event or condition that gets it started.
• Scenario — the numbered actions the actor takes and the system responses to each.
• Exceptions — the situations uncovered as the preliminary use case was refined.
• Open issues — the questions not yet settled, kept visible rather than quietly resolved.

The primary scenario is the path where everything works. Secondary scenarios are the alternative paths an actor may legitimately choose. Exceptions are the failure conditions. The rationalisation rule governs which exceptions you write down: include one only if the software can both detect the condition and do something about it. A member dropping the drill on the walk home is a genuine risk, but the software neither detects nor handles it, so it is a business problem, not a use case exception.

The diagram is not the use case

A UML use case diagram draws actors as stick figures, use cases as ovals, and a box for the system boundary. It shows which actors reach which use cases and how the use cases relate. It carries almost no detail — no steps, no preconditions, no exceptions. Confusing the diagram with the use case is a reliable way to write a page of nothing on an exam. And note one honest limitation of the notation itself: because a use case is function- and behaviour-oriented, it is a poor vehicle for non-functional requirements. The door opens within three seconds of a valid scan has no natural home in a numbered step list.

Worked example — Collect a reserved tool

The figure below is the formal template filled in for the BorrowBox use case Collect a reserved tool. Read the exceptions column against the rationalisation rule: an expired token is detectable (the hold time is stored) and handleable (offer to re-reserve); a jammed door is detectable (the controller reports it) and handleable (assign another door); a copy already collected is detectable and handleable (show who has it, offer the waitlist). All three earn their place. A member who forgets to come does not — the reservation simply expires, which is the primary scenario of a different use case.