We have said that a Use Case is a sequence of actions (complete with all alternative flows) describing system behavior that yields a result of value to an actor.
UML does not specify any particular format for the Use Case Text, and there are many different formats. An appropriate format should be selected and adhered to for every organization and/or project.
The actual text itself can be extremely informal, as long as it uses the Domain Model vocabulary in consistent fashion, and includes all of the alternative flows also (otherwise it wouldn’t be a Use Case).
It is very important to note, however, that the elaboration of a Robustness Diagram for each Use Case greatly improves the quality of the Use Case Text, since these diagrams validate the business logic and guarantee a consistent use of terminology over the complete set of Use Case in a project.
Many frameworks have prescribed the use of a formal Use Case Text Template, also. These might be very useful for those just starting out.
We have based our own standard Use Case Text Template on the work presented in the video Writing Good Use Cases, which is based on the present work of Ivar Jacobson and others at RUP:
(Note: for examples see Depot UC1, Depot UC2, Depot UC3).
(Also see Annotated Use Case Text Template)
(text)
(text)
(text)
...
(text)
At BF NameN …
...
At BF NameN …
At BF/AF NameN …
...
At BF/AF NameN …
(text)
(text)
(text)
(text)
...
(text)
(text)
See also on this web Requirements for a Use Case to be a Use Case.
One Use Case Text Template that has been placed in the public domain for many years is that published for many years on “Alistair Cockburn’s site”http://alistair.cockburn.us/, on the page entitled Basic Use Case Template:
|
USE CASE # |
< the name is the goal as a short active verb phrase> |
|
|
Goal in Context |
<a longer statement of the goal in context if needed> |
|
|
Scope & Level |
<what system is being considered black box under design> <one of : Summary, Primary Task, Subfunction> |
|
|
Preconditions |
<what we expect is already the state of the world> |
|
|
Success End Condition |
<the state of the world upon successful completion> |
|
|
Failed End Condition |
<the state of the world if goal abandoned> |
|
|
Primary, Secondary Actors |
<a role name or description for the primary actor>. <other systems relied upon to accomplish use case> |
|
|
Trigger |
<the action upon the system that starts the use case> |
|
|
DESCRIPTION |
Step |
Action |
|
1 |
<put here the steps of the scenario from trigger to goal delivery,and any cleanup afte> |
|
|
2 |
<...> |
|
|
3 |
||
|
EXTENSIONS |
Step |
Branching Action |
|
1a |
<condition causing branching> : <action or name of sub.use case> |
|
|
SUB-VARIATIONS |
Branching Action |
|
|
1 |
<list of variation s> |
|
|
RELATED INFORMATION |
<Use case name> |
|
Priority: |
<how critical to your system / organization> |
|
Performance |
<the amount of time this use case should take> |
|
Frequency |
<how often it is expected to happen> |
|
Channels to actors |
<e.g. interactive, static files, database, timeouts> |
|
OPEN ISSUES |
<list of issues awaiting decision affecting this use case > |
|
Due Date |
<date or release needed> |
|
...any other management information... |
<...as needed> |
|
Superordinates |
<optional, name of use case(s) that includes this one> |
|
Subordinates |
<optional, depending on tools, links to sub.use cases> |
This is somewhat different to what has become the “standard” RUP template, but is an interesting alternative, nonetheless. Characteristically for Alexander Cockburn, it leaves wide open the possibility for Use Case Hierarchies.
Also useful is his Resources for writing use cases page.
Finally, see also article Writing good requirements is a lot like writing good code, by Jim Heumann, Requirements management evangelist, IBM. (Author of the video Writing Good Use Cases, cited in our short discussion on UML).
Content
Victor Kane (ProjectMaster) and awebfactory.com.ar