A UML Use Case is an atomic system function with a well-defined and standardized specification, which is performed by or o behalf of a system user or ‘actor’. This article describes how a UML Use Case Specification should be written.
Use Case Templates
Use case specifications tend to be written in a standardized form, and over the years a number of use case specification templates have been created including the one you can download from
here. The article you are reading now uses a generic use case specification template that combines the most common elements from the available templates.
The generic template is comprised as follows:
1. Use Case Name
1.1 Brief Description
The description should briefly convey the role and purpose of the use case in a single paragraph.
2. Flow of Events
Use case must have one flow of events and maybe more, with each flow of events (or ‘scenario’) being realized (ideally) as a separate sequence diagram.
2.1 Basic Flow
A user case is always initiated by a human or system actor. The basic flow shows the actor’s actions and the system’s responses in the most common scenario for the use case. While the basic flow describes what the system does at each step – for example, displaying a form or debiting a bank account – it does not describe exactly how the behavior will be realized in code.
To aid with the subsequent realization of the use case as a sequence diagram it is useful to document the flow of events in the form of a numbered list. Each entry in the numbered sequence should use nouns and verbs from the problem domain to clarify which actors, business entities and user interface forms are interacting and what information they are exchanging. Consider the following use case step that will form part of the basic flow in our worked example:
5. The Destination Account receives a credit of the specified amount.
2.2 Alternative Flows
There may be a number of alternative flows that will be realized ultimately (and ideally) as entirely separate sequence diagrams. Note that these alternative flows should represent normal (but different) scenarios rather than exceptional or error conditions. When an alternative flow ends, the events of the main flow of events are resumed unless otherwise stated.
2.2.1 First Alternative Flow
This is the first alternative flow (if any).
2.2.2 Second Alternative Flow
This is the second alternative flow (if any).
3. Special Requirements
A special requirement is typically a non-functional requirement that is specific to a use case but which is not easily or naturally specified in the text of the use case’s event flow. These special requirements may be regulatory requirements, application standards, performance standards or design constraints.
3.1 First Special Requirement
This is the first special requirement (if any).
3.2 Second Special Requirement
This is the second special requirement (if any).
4. Pre-Conditions
A pre-condition describes something that must be true of the state of the system before the use case is performed.
4.1 First Pre-Condition
This is the first pre-condition (if any).
4.2 Second Pre-Condition
This is the second pre-condition (if any).
5. Post-Conditions
A post-condition describes something that must be true of the state of the system after the use case has been performed.
5.1 First Post-Condition
This is the first post-condition (if any).
5.2 Second Post-Condition
This is the first post-condition (if any).
6. Extension Points
An extension point represents a point in the use-case flow where some extension behavior may be invoked, with this extended behavior typically being factored out into a separate use case on the use case diagram.
6.1 First Extension Point
This is the first extension point (if any).
6.2 Second Extension Point
This is the second extension point (if any).
Worked Example
While the use case specification template descriptions detailed above provide a good basis for understanding the form and content of a use case specification, the only way to truly appreciate the UML Use Case Specification is via a concrete worked example.
For the purposes of devising a detailed Use Case Specification let’s conceive an entirely new use case to supplement those already included in our “banking” running example. This will be the Transfer Funds use case.
Use Case Specification: Transfer Funds
Version 1.0
1. Use Case Name: Transfer Funds
1.1 Brief Description
The Transfer Funds use case allows a banking Customer to transfer money from one of his (or her) bank accounts to another ; or the Bank Manager to transfer funds between any two accounts on behalf of a Customer.
1.2 Actor(s)
Customer, Bank Manager
2. Flow of Events
2.1 Basic Flow
The flow of events – which involves the actor selecting two accounts, entering an amount to transfer, and the funds transfer taking place – has been formalized in the following event sequence so as to facilitate the realization of this use case as one or more UML Sequence Diagrams.
1. The Customer (or Bank Manager) actor selects the Source Account via the Select Account use case which this use case <<uses>> or <<imports>>.
2. The Customer (or Bank Manager) actor selects the Destination Account via the Select Account use cases.
3. The actor enters an amount to transfer and confirms by pressing the Proceed button.
4. The Source Account incurs a debit of the required amount.
5. The Destination Account receives a credit of the specified amount.
2.2 Alternative Flows
2.2.1 First Alternative Flow
The actor may cancel the funds transfer by pressing the Cancel button rather than the Proceed button at step 3; in which case the use case ends.
3. Special Requirements
3.1 First Special Requirement
In order to comply with money laundering regulations, all inter-account transfers are limit to a maximum of $10,000. This system-wide amount may be varied as specified in business rule #1.
4. Pre-Conditions
4.1 First Pre-Condition
The actor must be logged into the banking web application via the Internet (for the Customer actor) or the bank intranet (for the Bank Manager actor).
5. Post-Conditions
5.1 First Pre-Condition
The total of the funds in the Source Account plus Destination Account must be the same when the use case concludes as it was before the use case began. No money should have been ‘lost in transit’, for example by having been debited from the Source Account yet not successfully credited to the Destination Account.
6. Extension Points
6.1 First Extension Point: Insufficient Funds
This extension is invoked if there are insufficient funds in the Source Account for the transfer to the Destination Account.
6.2 Second Extension Point
This extension is invoked to freeze the accounts and to log an error if the integrity of the total funds across both accounts has not been preserved during the transaction.
End-to-End UML Series Articles
Author : Tony Loton
Tony Loton has authored and co-authored the books “Professional UML with Visual Studio .NET”, “Professional Visual Studio 2005 Team System”, and “UML Software Design with Visual Studio 2010”