Managing Software Requi=
rements;
Second Edition - A Use Case Approach - Appendix B – Use Case Specific=
ation
Template
Use-Case Specification Template
The following template is provided for a use-case specificatio= n, which contains the textual properties of the use case. This document may be created with a word processing system, requirements management tool, or oth= er documentation tool. The use-case diagrams can be developed in a visual mode= ling or graphical drawing tool.
Revision
History
|
= Date |
= Issue |
= Description |
= Author |
| mm/dd/yy |
x= .x |
D= etails |
A= uthor name |
| <= o:p> |
<= o:p> |
<= o:p> |
<= o:p> |
| <= o:p> |
<= o:p> |
<= o:p> |
<= o:p> |
|
<= o:p> |
<= o:p> |
<= o:p> |
<= o:p> |
Note: The revision history may be provided by a requirements management or configuration management tool.
Table of
Contents
Normally, a use-case specification = will not be long enough to warrant a table of contents for the use case. But this element may be required if the use case presents unusual problems in finding portions of the specification.
Use-Case =
Name
Brief
Description
State the role and purpose of the u= se case. A single paragraph should suffice for this description.
System or
SubSystem
Give the name of the system or subs= ystem to which the use case applies.
Flow of E=
vents
Basic Flow
This use case starts when the actor= does something. An actor always initiates use cases. The use case should describe what the actor does and what the system does in response. The use case shou= ld be phrased in the form of a dialogue between the actor and the system.
The use case should describe what h= appens inside the system but not how or why. If information is exchanged, be speci= fic about what is passed back and forth. For example, it is not very illuminati= ng to say that the actor enters customer information—it is better to say that the actor enters the customer’s name and address. A glossary is often useful to keep the complexity of the use case manageable; you may wan= t to define customer information there, to keep the use case from drowning in details.
Simple alternatives may be presented within the text of the use case. If it takes only a few sentences to descri= be what happens when there is an alternative, do it directly within the flow-of-events section. If the alternative flows are more complex, use a separate section. For example, an alternative flow describes how to describe more complex alternatives.
A picture is sometimes worth a thou= sand words, although there is no substitute for clean, clear prose. If doing so improves clarity, feel free to include graphical depictions of user interfa= ces, process flows, or other figures in the use case. If a technical method, suc= h as an activity diagram, is useful to present a complex decision process, by all means use it. Similarly for state-dependent behavior, a state transition diagram often clarifies the behavior of a system better than do pages upon pages of text. Use the right presentation medium for your problem, but be w= ary of using terminology, notation, or figures that your audience may not understand. Remember that your purpose is to clarify, not to obscure.
Alternative Flows
1.&n= bsp; Fir= st alternative flow: More complex alternatives should be described in a separate section, which is referred to in the Basic Flow section. Think of = the Alternative Flows sections as alter= native behavior; each alternative flow represents alternative behavior (many t= imes because of exceptions that occur in the main flow). They may be as long as necessary to describe the events associated with the alternative behavior. = When an alternative flow ends, the events of the main flow of events are resumed unless otherwise stated.
Alternative flows may, in turn, be broken down into subsections.
2. Second alternative flow: There may be, and most likely will be, a number of alternative
flows in a use case. Keep each alternative separate, to improve clarit=
y.
Using alternative flows improves the readability of the use case and
prevents use cases from being decomposed into hierarchies of use cases. Kee=
p in
mind that use cases are just textual descriptions and that their main
purpose is to document the behavior of a system in a clear, concise, and
understandable way.
Special Requirements
These are typically nonfunctional requirements that are specific to a use case but are not easily or naturally specified in the text of the use case’s event flow. Examples of speci= al requirements include legal and regulatory requirements, application standards, and quality attributes of the system to be built, including usability, reliability, performance, and supportability requirements. Other requirements, such as operating systems and environments, compatibility requirements, and design constraints, should also be captured in this secti= on.
1.&n= bsp; First special requirement
2.&n= bsp; Second special requirement
Pre-conditions
A pre-condition of a use case is the state of the system that must be present prior to a use case being performe= d.
1.&n= bsp; Pre-condition 1
2.&n= bsp; Pre-condition 2
Post-conditions
A post-condition of a use case is a= list of possible states the system can be in immediately after a use case has finished.
1.&n= bsp; Post-condition 1
2.&n= bsp; Post-condition 2
Extension Points
Extension points are named markers = that reference a location or set of locations within the flow of events of the u= se case, at which additional behavior can be inserted.
1.&n= bsp; Extension point 1
2.&n= bsp; Extension point 2