• Does the use case have a unique name?
• Is the name a verb + noun phrase (for example, Withdraw Cash)?
• Does the name accurately summarize the main purpose of the use case?
• Is the name Actor-independent?

• Is it clear from the brief description what the main purpose of the use case is?
• Is the "observable result of value" obvious?

• Is the use case associated with one or more Actors?
• Is the primary, or initiating Actor, defined?
• Is it clear who performs the actions in the use case?
• Is all information exchanged between the Actors and the system clearly specified?
• If a "time" actor is used, are you sure you did not miss an important Actor and associated use cases (such as administrative or maintenance personnel who define schedule events)?

Does each precondition represent a tangible state of the system (for example, the Withdraw Cash use case for an automated teller machine has a precondition that the user has an account)?

• Is it clear how the use case starts?
• Is the triggering event clearly described?
• Does the flow have a definite ending?
• Does each step in the scenario contain the same level of abstraction?  
• Does each step in the scenario describe something that can actually happen and that the system can reasonably detect?
• Does each step make progress toward the goal?
• Are there any missing steps? Is it clear how to go from one step to the next? Does the sequence of communication between the Actors and the use cases conform to the users' expectations?
• Does each step describe how the step helps the Actors achieve their goals?
• Is each step technology-independent? Is it free of technical details and inadvertent design decisions?
• Are the steps correctly numbered?
• For each alternate flow, are the conditions for initiation of the flow clearly defined?
• For each alternate flow, is it clear how the use case ends or where in the basic flow that the use case resumes?

• If Minimal Guarantees are present, do they always happen when the use case completes, regardless of success? (A Minimal Guarantee represents a condition that will be true when the use case ends, regardless of how it terminates.)
• If Success Guarantees are present, do they always happen when the use case completes successfully? (A Success Guarantee represents a condition that will be true when the use case ends successfully, regardless of which path it takes.)

• Are nonfunctional requirements (such as performance criteria) that are applicable to the use case captured in the use case?
• Are these nonfunctional requirements applicable to many use cases? It they are, consider capturing them in the supporting Requirements Specification to simplify maintenance.