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