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?

Copyright  © 1987 - 2001 Rational Software Corporation

Rational Unified Process