Use Case Narrative Components

A Use Case Narrative is a textual description of a use case that provides a detailed and structured explanation of the interactions between actors and the system. The elements of a Use Case Narrative are:

1. Use Case Name: A brief, descriptive name of the use case.
2. Primary Actor: The main actor who initiates the use case.
3. Goal: A brief description of the primary actor's goal or objective.
4. Preconditions: The conditions that must be true before the use case can start.
5. Triggers: The event that initiates the use case.
6. Description: A step-by-step narrative of the interactions between the actors and the system, including:
   • Basic Course: The typical flow of events.
   • Alternative Courses: Variations in the flow, such as error handling or exceptions.
   • Special Requirements: Any additional requirements or constraints.
7. Postconditions: The conditions that must be true after the use case is completed.
8. Extensions: Additional information, such as:
   • Related Use Cases: References to other related use cases.
   • Rationale: Explanations for design decisions or trade-offs.
   • Assumptions: Any assumptions made about the actors, system, or environment.

By including these elements, a Use Case Narrative provides a clear and comprehensive understanding of the functional requirements and behavior of the system from the user's perspective.

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.

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.

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:

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

1. 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.
2. 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.
3. 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.