Guideline: Detail Use Cases and Scenarios |
This guideline provides guidance on detailing use cases and scenarios.
Relationships
Related Elements | Detail Requirements
Main Description
#### Efficiency Because use cases model requirements, they are highly dynamic by nature. The more we examine a requirement, the more we learn, and the more things change. To further complicate the issue, changes to one use case can lead to changes in others. Therefore, we want a flexible, highly efficient method for writing use cases that eliminates unnecessary busy work and re-writing. An iterative, breadth-first approach, in which the use case is continuously evaluated before adding detail, is an effective way to write use cases. This breadth-first approach has two aspects: 1) writing the set of use cases; and 2) writing individual use cases. Use cases exist in sets and the relationships between the various use cases and/or actors is important. As one learns more about the actors, one also learns more about the system's boundaries and transactions. Likewise, as one learns more about the system's transactions, one learns more about its actors. Therefore, it is more efficient to write several use cases simultaneously than sequentially. This way, we can identify and understand the impacts of the various use cases upon each other as we write them, rather than as afterthoughts requiring re-writing or elimination of previous work. Similarly, it makes sense to write each individual use case iteratively. Starting with the main scenario, one can then identify various alternative and error flows the use case might follow, evaluate, rearrange or eliminate them, then flesh out the details of the surviving scenarios. The level of detail captured depends upon a number of factors. See Guideline: Use Case Formats for guidance on selecting the correct format for your use cases. #### Detail flow of events of the main scenario As a starting point, use the step-by-step description of the main scenario created during Task: Find and Outline Requirements. Then, gradually add details to this scenario, describing what is done in the Use Case, not how problems internal to the system should be solved. A flow of events description explores: How and when the Use Case starts When the use case interacts with the actors, and what data they exchange When the use case uses data stored in the system, or stores data in the system How and when the use case ends It does not describe: The GUI Technical details including hardware or software issues Design issues #### Identify Alternate flows A use case consists of a number of scenarios, each representing specific instances of the use case corresponding to specific inputs from the actor or specific conditions in the environment. Each scenario describes alternate ways that the system provides a behavior, or it may describe failure or exception cases. As you detail the main scenario, identify alternate flows by asking questions such as: Are there different options available depending on input from the actor? (ex. the actor enters an invalid PIN number while accessing an ATM) What business rules may come into play? (ex. the actor requests more money from the ATM than is available in her account) What could go wrong? (ex. no network connection available when required to perform a transaction) It is best to develop these scenarios iteratively as well. Begin by identifying them. Examine each candidate scenario to determine whether it is relevant, that it can actually happen, and that it is distinct from other scenarios. Eliminate redundant or unnecessary scenarios, and then start fleshing out the more important ones. #### Structure the use case It is useful to structure the use case according to scenarios to simplify communications and maintenance, and to permit the use cases to be implemented iteratively. In addition to structuring the use cases according to scenarios, it is often useful to structure the scenarios themselves into sub-flows. This provides an additional level of granularity for planning work and tracking progress. Unless a sub-flow involves only a minor part of the complete flow of events -- which can be described in the body of the text -- it is recommended that you describe each sub-flow in a separate section to the Flow of Events section. Examples of sub-flows that should be in a separate section include: Sub-flows that occupy a large segment of a given flow of events. Exceptional and alternate flows of events. This helps the use case's basic flow of events to stand out more clearly. Any sub-flow that can be executed at several intervals in the same flow of events. For more information, see Concept: Use Case, Flow of Events - Structure section. #### Describe special requirements Any requirements that are related to the use case, but are not taken into consideration in the Flow of Events of the use case, should be captured as well. Such requirements are likely to be nonfunctional. Typically, non-functional requirements that refer to a specific use case are captured in the special requirements section of the use case. For more information, see Concept: Use Case, Special Requirements section. If there are non-functional requirements that apply to more than one use case, capture these in the Artifact: Supporting Requirements. For more information on supporting requirements see Concept: Supporting Requirements. #### Describe preconditions and postconditions A precondition on a use case explains the state the system must be in order for the use case to be possible to start. Take care to describe the system state. Avoid describing the detail of other incidental activities that may have taken place prior to this use case. A postcondition on a use case lists possible states the system can be in at the end of the use case. The system must be in one of those states at the end of the execution of the use case. It is also used to state actions that the system performs at the end of the use case, regardless of what occurred in the use case. Neither preconditions nor postconditions are should be used to create a sequence of use cases. As a general rule, there should never be a case where you have to first perform one use case, then another, in order to have a meaningful flow of events. If that is the case, correct the problem by reviewing the use cases. For more information see Concept: Use Case, Preconditions and Postconditions section.
More Information
Concepts | Use Case Supporting Requirements
Guidelines | Use Case Formats
This program and the accompanying materials are made available under the Eclipse Public License v1.0 which accompanies this distribution. View copyright information here: OpenUP Copyright