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.
|