Checkpoints: Use Case
- Is each concrete use case involved with at least one actor?
If not, something is wrong; a use case that does not interact with an
actor is superfluous, and you should remove it. For more information, see Guidelines:
Use Case.
- Is each use case independent of the others? If two use cases
are always activated in the same sequence, you should probably merge them
into one use case.
- For an included use case: does it make assumptions about the
use cases that include it? Such assumptions should be avoided, so that the
included use case is not affected by changes to the including
use cases.
- Do any use cases have very similar behaviors or flows of
events? If so - and if you wish their behavior to be similar in the future
- you should merge them into a single use case. This makes it easier to
introduce future changes. Note: you must involve the users if you decide
to merge use cases, because the users, who interact with the new, merged
use case will probably be affected.
- Has part of the flow of events already been modeled as
another use case? If so, you can have the new use case use the old one.
- Is some part of the flow of events already part of another
use case? If so, you should extract this subflow and have it be used by
the use cases in question. Note: you must involve the users if you decide
to "reuse" the subflow, because the users of the existing use
case will probably be affected.
- Should the flow of events of one use case be inserted into
the flow of events of another? If so, you model this with an
extend-relationship to the other use case.
- Do the use cases have unique, intuitive, and explanatory
names so that they cannot be mixed up at a later stage? If not, you change
their names.
- Do customers and users alike understand the names and
descriptions of the use cases? Each use-case name must describe the
behavior the use case supports.
- Does the use case meet all the requirements that obviously
govern its performance? You must include any (nonfunctional) requirements
to be handled in the object models in the use-case Special
Requirements.
- Does the communication sequence between actor and use case
conform to the user's expectations?
- Is it clear how and when the use case's flow of events starts
and ends?
- Behavior might exist that is activated only when a certain
condition is not met. Is there a description of what will happen if a
given condition is not met?
- Are any use cases overly complex? If you want your use-case
model to be easy to understand, you might have to split up complex use
cases.
- Does a use case contain disparate flows of events? If so, it
is best to divide it into two or more separate use cases. A use case that
contains disparate flows of events will be very difficult to understand
and to maintain.
- Is the subflow in a use case modeled accurately?
- Is it clear who wishes to perform a use case? Is the purpose
of the use case also clear?
- Are the actor interactions and exchanged information clear?
- Does the brief description give a true picture of the use case?
| |
|
