Checklist: Use Case |  |
This checklist provides questions to verify that use cases are described in a consistent and complete manner.
Relationships
Related Elements | Use Case Requirements Use-Case Model Find and Outline Requirements Find and Outline Requirements Detail Requirements Detail Requirements
Check Items
Is the use-case name meaningful and unambiguous?
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?
Does the brief description clearly describe the primary goal of the use case?
Is it clear from the brief description what the main purpose of the use case is? Is the "observable result of value" obvious?
Are associated Actors and information exchanged clearly defined?
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)?
Are the pre-conditions specified?
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)?
Are the basic flow and alternative flows complete, correct, and consistent?
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?
Are the post-conditions specified?
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 applicable nonfunctional requirements captured?
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.
More Information
Checklists | Qualities of Good Requirements
This program and the accompanying materials are made available under the Eclipse Public License v1.0 which accompanies this distribution. OpenUP Copyright. OpenUP/DSDM Copyright.