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.
VMWare, sap, data mining
strategic planning, thin client, firefox-a
strategic planning, thin client, firefox-a
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-- 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.
