Artifact:
Use Case
Use Case
|
A use case
defines a set of use-case instances, where each instance is a sequence of
actions a system performs that yields an observable result of value to a
particular actor.
|
UML
representation:
|
Use Case
|
Role:
|
Analyst
|
Enclosed
in:
|
Software
Requirements Specification
|
More
information:
|
-
Guidelines:Use Case
-
Checkpoints:Use Case
|
|
Input to Activities:
-
Review Requirements
-
Use-Case Design
-
Use-Case Analysis
-
Detail a Use Case
|
Output from Activities:
-
Find Actors and Use Cases
-
Detail a Use Case
|
Templates, Case-Study, Report..
The Word template can be bought through a template package. Case studies and reports are freely available in the table below.
Word
Template
|
Case
Study
|
Report
|
|
|
|
Purpose
The following people will use the use cases:
-
Customers
will use the use cases to understand the
system's behavior, and, since they must approve the use case's flow of
events, customer will also use the use cases to approve the result of
use-case modeling.
-
Potential
users
will use the use case to understand the
system's behavior.
-
Designers
will use the use cases to identify
architecturally significant functionality.
-
People who
analyze
,
design
, and
implement
the system will use the use case to understand the required system behavior
and to refine the system.
-
Use-case designers
will use the use cases' flows of
events to find classes. (These are the most important artifacts for use-case
designers.)
-
Testers
will use the use cases as a base for identifying
test cases.
-
Managers
will use the use cases to plan and follow up the
use-case modeling.
-
Reviewers
will use the use cases to
understand what sequence of use should be described in the documentation
(such as the system user guide).
Properties
Property Name
|
Brief Description
|
UML Representation
|
Name
|
The
name of the use case.
|
The
attribute "Name" on model element.
|
Brief
Description
|
A
brief description of the role and purpose of the use case.
|
Tagged
value, of type "short text".
|
Flow
of Events
|
A
textual description of what the system does in regard to the use case (not
how specific problems are solved by the system). The description is
understandable by the customer.
|
Tagged
value, of type "formatted text".
|
Special
Requirements
|
A
textual description that collects all requirements, such as non-functional
requirements, on the use case, that are not considered in the use-case
model, but that need to be taken care of during design or implementation.
|
Tagged
value, of type "short text".
|
preconditions
|
A
textual description that defines a constraint on the system when the use
case may start.
|
Tagged
value, of type "short text".
|
postconditions
|
A
textual description that defines a constraint on the system when the use
cases have terminated.
|
Tagged
value, of type "short text".
|
Extension
points
|
A
list of locations within the flow of events of the use case at which
additional behavior can be inserted using the extend-relationship.
|
Tagged
value, of type "short text".
|
Relationships
|
The
relationships, such as communicates-associations, include-, generalization-,
and extend-relationships, in which the use case participates.
|
Owned
by an enclosing package, via the aggregation "owns".
|
Activity
Diagrams
|
These
diagrams illustrate the structure of the flow of events.
|
Participants
are owned via the aggregation "types" and
"relationships" on a collaboration traced to the use case.
|
Use-Case
Diagrams
|
These
diagrams show the relationships involving the use case.
|
Participants
are owned via the aggregation "types" and
"relationships" on a collaboration traced to the use case.
|
Other
Diagrams
|
Other graphical illustrations of the
use case.
|
Tagged value, of uninterpreted type.
|
Brief Outline
The template provided for a
Use-Case Specification contains the textual properties of the use
case. This document is used with a requirements management tool, such as
Rational RequisitePro, for specifying and marking the requirements within the
use case properties.
The diagrams of the use case can be developed in a visual modeling tool, such
as Rational Rose.
Timing
Use cases are identified and possibly briefly outlined early in the inception
phase, to help in defining the scope of the system. The use cases that are
relevant for the analysis or the architectural design of the system are then
described in detail within the Elaboration phase. The remaining use cases are
described in detail within the Construction phase.
Responsibility
An
Analyst
is responsible for
the integrity of the use case, which ensures that:
-
the use case fulfills its requirements (that is, it correctly describes
the functionality that is relevant to the use case, and only this
functionality)
-
the flow of events is readable and suits its purpose
-
the use-case relationships originating from the use case are justified and
kept consistent
-
the role of the use case where it is involved in communicates-associations
is clear and intuitive
-
the diagrams describing the use case and its relationships are readable
and suit their purpose
-
the special requirements are readable and suit their purpose
-
the preconditions are readable and suit their purpose
-
the postconditions are readable and suit their purpose
It is recommended that the person who is responsible for a use
case is also responsible for its enclosing use-case package.
Tailoring
Decide the extent to which Use Cases will be elaborated:
-
describe only major flows?
-
describe only the most important use cases?
-
fully describe preconditions and postconditions?
Some projects apply use cases informally to discover requirements, but
document and maintain these requirements in another form. How you tailor Use Cases
may depend on project size, experience, your tool set, customer relationship,
and so forth. See
Guidelines: Use Case
for
guidance related to Use Case tailoring.
|