|Lesson 9|| The use case narrative, part 1|
|Objective||Describe the Elements of a Use Case Narrative|
Use Case Narrative Components
Although the use case diagram provides a convenient view of the main features of a system, it is too concise to describe what users are expecting.
So, as with most diagrams, we support it with a narrative.
Use Case Narrative - Part 1
A common question about use cases is "How do I show workflow or screen flow?"
The short answer is that you don't. A more appropriate question would be,
"How do I use the use case model to determine screen and workflow requirements?"
Although you can go directly to describing features, many people find it helpful to develop use cases first and then generate a list of features.
A feature may be a whole use case, a scenario in a use case, a step in a use case, or some variant behavior, such as adding yet another depreciation method for your asset valuations, that does not show up in a use case narrative.
Usually, features end up being more fine grained than use cases.
Check out the pre-conditions and assumptions. If one use case requires the user to provide data that belongs to another use case, or do something that another use case is responsible for, then logically the other use case must come first.
Quite often, screen and workflows are far more flexible than we think. Let the use case constraints tell you what the flow options are. Then design the flow or flows that are possible, letting the users make the final choice as to which flow is best in the current task.
Use case narrative
Describing a use case requires that we both frame the context of the use case and describe the dialog between the user (actor or use case)
and the use case. With this in mind, most use case narratives include the following elements:
- Assumptions: Conditions that must test true to use the use case. Testing these conditions is outside the scope of this use case (contrast this with the pre-conditions). As examples, consider authentication or authorization since these functions are typically handled by a standard security feature.
Place common use case assumptions into an overview document rather than include them in every use case narrative.
- Pre-conditions: Conditions that must test true to use the use case. Unlike assumptions, these conditions are tested by this use case before doing anything else. If the conditions are not true, the actor or other use case is refused entry.
- Process: A step-by-step description of the dialog between the use case (the system) and the user (actor or other use case). Very often it is helpful to model this sequence of events using a flowchart or activity diagram just as you might model a protocol for communication between two business units.
- Post-conditions: Conditions that must test true when the use case ends. You may never know what comes after the use case ends, so you must guarantee that the system is in a stable state when it does end.
In the next lesson, the writing of a use case narrative will be discussed.