The following people use the use-case model:
- The customer approves the use-case model. When you have that approval, you
know the system is what the customer wants. You can also use the model to
discuss the system with the customer during development.
- Potential users use the use-case model to better understand the system.
- The software architect uses the use-case model to identify architecturally
- Designers use the use-case model to get a system overview. When you refine
the system, for example, you need documentation on the use-case model to aid
- The manager uses the use-case model to plan and follow up the use-case
modeling and also the subsequent design.
- People outside the project but within the organization, executives, and
steering committees, use the use-case model to get an insight into what has
- People review the use-case model to give appropriate feedback to
developers on a regular basis.
- Designers use the use-case model as a basis for their work.
- Testers use the use-case model to plan testing activities (use-case and
integration testing) as early as possible.
- Those who will develop the next version of the system use the use-case
model to understand how the existing version works.
- Documentation writers use the use cases as a basis for writing the
system's user guides.
textual description that serves as a brief introduction to the model.
value, of type "short text".
textual description that contains information not reflected by the rest of
the use-case model, including:
· Typical sequences in which the use cases are employed by users.
· Functionality not handled by the use-case model.
value, of type "formatted text".
packages in the model, representing a hierarchy.
via the association "represents", or recursively via the
use cases in the model, owned by the packages.
recursively via the aggregation "owns".
actors in the model, owned by the packages.
relationships in the model, owned by the packages
diagrams in the model, owned by the packages.
use-case view of the model, which is an architectural view showing the
significant use-cases and/or scenarios.
The use-case model primarily sets the functional requirements on the system,
and is used as an essential input to analysis and architectural design. It can
be used early in the inception phase to outline the scope of the system, as well
as during the elaboration phase. The use-case model is refined by more detailed
flows of events during the construction phase. The use-case model is
continuously kept consistent with the design model.
Because it is a very powerful planning instrument, the use-case model is
generally used in all phases of the development cycle.
A system analyst is responsible for the
integrity of the use-case model, and ensures that the use-case model as a whole
is correct, consistent, and readable. The use-case model is correct when it
describes the system's functionality, and only this functionality.
Note that details of use-case packages, use cases, actors, relationships, and
diagrams are the responsibilities of the corresponding requirements specifier. For
more information, refer to Role: Requirements Specifier. The use-case view is the responsibility of the software architect. For more
information, refer to Role: Software Architect.
Tailor to support project needs. This may include
including only a subset of the sub-artifacts (properties), tailoring the level
of formality in which the sub-artifacts are created and managed, and tailoring
of the individual sub-artifacts. Document tailoring decisions in the
Artifact: Use Case Modeling Guidelines.
© 1987 - 2001 Rational Software Corporation