Identify Common Requirements
The first step in structuring the Use-Case Model is to understand the requirements that are common to more than one Use Case.
Review each use case, taking notes of any commonality.
Use these notes in the later steps (creating included, extended, and generalized use cases) to minimize redundancy. The
goal is to make the requirements more understandable and easier to maintain, NOT to define a functional decomposition
that is carried forward into the design.
Common requirements aren't always handled best by creating new use cases. Consider moving common content into other
requirements work products, such as the Glossary
and Supplementary Specifications and reference as needed from use cases.
Establish Include-Relationships Between Use Cases
If a use case contains a segment of behavior of which only the result, not the method for getting the result, is of any
importance to the rest of the use case, this behavior can be factored out to a new inclusion use case. The
original use case then becomes the base use case in an include-relationship with the inclusion use case. See
also Guideline: Use-Case Model and Guideline: Include-Relationship.
An include-relationship between two use cases means that a use-case instance following the description of the base use
case also needs to follow the description of the inclusion use case in order to be complete.
The include-relationship can help clarify a use case by:
Isolating and encapsulating complex details so they do not obscure the real meaning of the use case.
Improving consistency by including behavior which are included in several base use cases.
Generally, more than one use case must include an inclusion use case to make it worth it to maintain an extra use case
and the include-relationship.
Only the base use case knows of the relationship between the two use cases; no inclusion use case knows what other use
cases includes it.
Describe the include-relationship by briefly stating the purpose of the inclusion, as well as the location in the base
use case at which the inclusion is to be inserted.
When describing the flow of events of the base use case, you should refer to the inclusion at the location in which the
inclusion is inserted.
Establish Extend-Relationships Between Use Cases
If a use case has segments of behavior that are optional or exceptional in character, and that do not add to the
understanding of the primary purpose of the use case, factor those out to a new extension use case. The original
use case then becomes a base use case, to which the extension use case has an extend-relationship. See also Guideline: Use-Case Model and Guideline: Extend-Relationship.
In the base use case you declare extension points, which define where in the base use case extensions may be made. See
also Guideline: Use Case.
Complex sub-flows and optional behavior are the first candidates for being partitioned out into extension use cases.
Often this behavior can be quite complex and hard to describe: including it in the flow of events of a use case can
make the "normal" behavior harder to see. Extracting it should improve the comprehensibility of the use-case model.
Make sure that the flow of events of the base use case is still complete and understandable by itself, without any
reference to the extension use case.
Only the extension use case knows of the relationship between the two use cases. The base use case only knows it has
extension points, it doesn't know what extension use cases are using them.
Briefly describe every extend-relationship you define. Define the conditions that must be met for the extension to
occur. Make sure to define the extension point in the base use case at which the extension should be inserted.
If you do not define any conditions, it means the extension always is performed.
If the extension use case has several behavior segments that are to be inserted at different extension points in
the base use case, make sure to define these segments and the extension point for each segment in the base use
Establish Generalizations Between Use Cases
If two or more use cases have similarities in structure and behavior, you can factor out the common behavior to create
a new parent use case. The original use cases will then be child use cases in
generalization-relationships with the parent. The child use case inherits all behavior described for the parent use
case. See also Guideline: Use-Case Model and Guideline: Use-Case Generalization.
A generalization-relationship between two use cases means that when a use-case instance follows the description of a
child use case, it also needs to follow the description of the parent use case in order to be considered complete.
Generally, for it to be worth it to maintain a parent use case and a generalization-relationship with a child, there
needs to be at least two child use cases inheriting from the same parent. An exception is if you have two use cases
where one is a specialization of the other, but both need to be independently instantiable.
Only the child use case knows of the relationship between the two use cases; no parent use case knows what child use
cases are specializing it.
To assist others in understanding the model, you should briefly describe the generalization-relationship. Explain why
you created the generalization-relationship.
In the flow of events of the child use case you need to explain how the child will modify the inherited behavior
sequences by inserting new segments of behavior.
Establish Generalizations Between Actors
Actors will have common characteristics that you should model by using actor-generalizations. This part of the work is
best performed after you have made your first attempts at a use-case model.
Write a brief description of the actor-generalizations, and include them in use-case diagrams for further
For more information, see Guideline: Actor-Generalization.
Organize the Use-Case Model Content into Packages
Evaluate Your Results
You should continuously discuss the incorporation of include-, extend-, and generalization-relationships with the
customer and the users, and see that they have a clear understanding of the resulting use cases and actors, and that
they agree on their descriptions.
Check the use-case model at this stage to verify that your work is on track, but do not review the model in detail. You
should review and discuss the newly incorporated use cases and relationships with the customer and users so that they
have a clear understanding of the use cases and agree on their descriptions.
For specific recommendations on what to look for during this review, see Checklist: Use-Case Model.