|
Is it easy to understand what the system does by reviewing the model
-
There are no long chains of include and extend relationships, such as when an included use case is extended, or
when an extended use case includes other use cases. These can obscure comprehensibility.
-
There are minimal cross-dependencies where an included, extending, or specialized use case must know about the
structure and content of other included, extending or specialized use cases.
|
Have all use cases been identified
-
The use cases identified collectively account for all required behavior of the system.
-
All features identified in the Vision document for this iteration have been addressed by at least one use case.
-
All non-functional requirements that must be satisfied by a specific use case have been captured in that use case
-
The use-case model contains no superfluous behavior (gold-platting).
|
Are all relationships between use cases required
There is a justification for all include-, and extend- relationships
|
Are use case packages used appropriately
-
Cross-package dependencies have been reduced or eliminated to prevent model ownership conflicts
-
Packaging is intuitive and makes the model easier to read
|
Do all model elements have appropriate names
Each use case should have a name that indicates what is achieved by its interaction with the actor(s).
No two use cases can have the same name.
Each actor has a name that effectively describes the role.
|
|
