A use-case
package is a collection of use cases, actors, relationships, diagrams, and
other packages; it is used to structure the use-case model by dividing it
into smaller parts.
UML
representation:
Package in
the use-case model, either its top-level package, or stereotyped as
«use-case package»
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 use the use-case packages:
System analysts use use-case packages to structure the use-case model.
Those who capture the requirements on the next version of the system use
the use-case packages to understand the structure of the use-case model.
Designers use use-case packages as a reference for other parts
of the system that they are working in.
Testers use use-case packages as input to planning test activities.
Properties
Property Name
Brief Description
UML Representation
Name
The
name of the package.
The
attribute "Name" on model element.
Brief
Description
A
brief description of the role and purpose of the package.
Tagged
value, of type "short text".
Use
Cases
The
use cases directly contained in the package.
Owned
via the aggregation "owns".
Actors
The
actors directly contained in the package.
-
" -
Relationships
The
relationships directly contained in the package.
-
" -
Diagrams
The
diagrams directly contained in the package.
-
" -
Use-Case
Packages
The
packages directly contained in the package.
-
" -
Timing
Use-case package partitioning is done as soon as the use-case model is too
large to maintain as a flat structure. This can be the case early in inception,
or later on in the elaboration or construction phases.
Responsibility
An Analyst is responsible for
the integrity of the package, which ensures that:
The package fulfills its requirements.
The package is as independent as possible of other packages.
The existence of the direct contents of the package (including its use
cases, actors, relationships, diagrams, and packages) is justified and kept
consistent.
It is recommended that the person responsible for a use-case
package is also responsible for its contained use cases. For more information,
refer to Guidelines: Use Case.
Tailoring
+ Provide a hierarchical model structure with separate functional
units. This is easier to understand than a flat model structure (without
packages) if the use-case model and the system is relatively large.
+ Offer a good opportunity to distribute work and responsibilities
among several developers according to their area of competence. This is
particularly important when you are building a large system. Use-case packages
also offer a secure basis if you need to ensure confidentiality among your
developers so that only a few know about the complete functionality of the
system.
+ Because use-case packages should be units of high cohesion, changing
one package will not affect other packages.
- Maintaining use-case packages means more work for the use-case
modeling team.
- Using use-case packages means that there is yet another notational
concept for the developers to learn.
If you use this technique you have to decide how many levels of packages to
use. A rule of thumb is that each use-case package should contain approximately
3 to 10 smaller units (use cases, actors, or other packages). The table below
gives some suggestions as to how many packages you should use given the number
of use cases and actors. The quantities overlap because it is impossible to give
exact guidelines.
Artifacts >
Requirements Artifact Set >
{More Requirements Artifacts} >
Use-Case Package
