<Project Name>
Use-Case Specifications
Version <1.0>
[Note: The following template is provided for use with the
Unified Process for EDUcation. Text enclosed in square brackets and displayed
in blue italics (style=InfoBlue) is included to provide guidance to the author
and should be deleted before publishing the document. A paragraph entered
following this style will automatically be set to normal (style=Body Text).]
[To customize automatic fields in Microsoft Word (which
display a gray background when selected), select File>Properties and replace
the Title, Subject and Company fields with the appropriate information for this
document. After closing the dialog, automatic fields may be updated throughout
the document by selecting Edit>Select All (or Ctrl-A) and pressing F9, or
simply click on the field and press F9. This must be done separately for
Headers and Footers. Alt-F9 will toggle between displaying the field names and
the field contents. See Word help for more information on working with fields.]
Revision History
|
Date |
Version |
Description |
Author |
|
<dd/mmm/yy> |
<x.x> |
<details> |
<name> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Table of Contents
1.2 General Actors Descriptions
1.4 Diagrams of the Use-Case Model
2.3.1 < First Special Requirement
>
2.6.1 <Name of Extension Point>
[The following template is provided for the Use-Case
Specifications, which contains the textual properties of the use case.
The use-case diagrams can be developed in a visual modeling
tool, such as Rational Rose. A use-case report, with all properties, may be
generated with Rational SoDA. ]
[This section contains an overview of the
use-case model. This includes a list of
names and brief descriptions of all use cases and actors, along with applicable
diagrams and relationships. Refer to the
Use-Case-Model Survey Report.]
[Introduction to the use-case model]
[List Project actors and provide a brief
description (role played).]
[This section presents the use-case packages
hierarchically, explains the dependencies among them, and shows the content of
each package recursively. If the model has several levels of packages, those at
the top-level are presented first. The packages within these are presented
next, and so on, all the way down to the packages at the bottom of the
hierarchy.
§
Description
A Brief Description explaining the package's
function and role in the system. The description must be understandable to any
developer who wants to use the package.
§
Use Cases
A list of the use cases owned by the package
(name only since descriptions and details are shown further in this document
§
Actors
A list of actors owned by the package,
including the name and brief description (role involved) of each actor in this
package
§
RelationShips
A list of relationships owned by the
package, including the name and brief description of each relationship.
§
Packages Owned
A list of the packages directly owned by the
package, with each package presented in the same hierarchical manner as shown
in the Packages Diagram below.
[Include the Package Diagrams (Including a
visual representation of the sub packages it owns]
§
Description
§
Use Cases
§
Actors
§
RelationShips
[...]
[...]
[Diagrams, primarily use-case diagrams and
use-case packages, of the entire use-case model are included here. If you are
including use-case diagrams directly within each use-case section or
subsection, briefly state so]
[The description briefly conveys the role and purpose of the
use case. A single paragraph will suffice for this description.]
[This use case starts when the actor does something. An actor
always initiates use cases. The use case describes what the actor does and what
the system does in response. It is phrased in the form of a dialog between the
actor and the system.
The use case describes what happens inside the system, but
not how or why. If information is exchanged, be specific about what is passed
back and forth. For example, it is not very illuminating to say that the actor
enters customer information. It is better to say the actor enters the
customer’s name and address. A Glossary of Terms is often useful to keep the
complexity of the use case manageable¾you may want to define
things like 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 only takes a few sentences to describe what happens when there
is an alternative. Do it directly within the Flow of Events section. If
the alternative flow is more complex, use a separate section to describe it.
For example, an Alternative Flow subsection explains how to describe
more complex alternatives.
A picture is sometimes worth a thousand words, though there
is no substitute for clean, clear prose. If it improves clarity, feel free to
paste graphical depictions of user interfaces, process flows or other figures
into the use case. If a flow chart 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 pages upon pages of text. Use the right
presentation medium for your problem, but be wary of using terminology,
notations or figures that your audience may not understand. Remember that your
purpose is to clarify, not obscure.]
[More complex alternatives are described in a separate
section, referred to in the Basic Flow subsection of Flow of Events
section. Think of the Alternative Flow subsections like alternative
behavior¾
each alternative flow represents alternative behavior usually due to 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.]
[There may be, and most likely will be, a number of
alternative flows in a use case. Keep each alternative flow separate to improve
clarity. Using alternative flows improves the readability of the use case, as
well as preventing use cases from being decomposed into hierarchies of use
cases. Keep in mind that use cases are just textual descriptions, and their
main purpose is to document the behavior of a system in a clear, concise, and
understandable way.]
[A special requirement is typically a nonfunctional
requirement that is specific to a use case, but is not easily or naturally
specified in the text of the use case’s event flow. Examples of special requirements
include legal and regulatory requirements, application standards, and quality
attributes of the system to be built including usability, reliability,
performance or supportability requirements. Additionally, other requirements¾such
as operating systems and environments, compatibility requirements, and design
constraints¾should
be captured in this section.]
[A precondition of a use case is the state of the system that
must be present prior to a use case being performed.]
[A postcondition of a use case is a list of possible states
the system can be in immediately after a use case has finished.]
[Extension points of the use case.]
[Definition of the location of the extension point in the
flow of events.]
[The relationships involving the use case are included here.
For communicates-associations, a brief description,
multiplicity, and associated actors are included. Also, the navigability of the
use-case role is included.
For include- and extend-relationships, a brief description
and associated use cases are included. ]
[Use-Case Diagrams local to the use case.]
[Other graphs that illustrate the use case.]
[....]