Checklist: Use Case
This checklist helps make sure that all use cases are described and structured correctly.
Relationships
Related Elements
Main Description


Check Items
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 Guideline: 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