BUSINESS ANALYSIS – THE REAL WORLD

Chapter 26 - Use Case Narratives / Scenarios

Many Business Analysts use a Use Case template to capture scenarios. Tailor
the template for use case definitions to your own project needs to provide
effective project documentation. Just be sure to understand that use cases are
only the starting point for analysis and understanding of software applications.
The following are some of the entries for a Use Case Narrative template:

• Use Case Name

• Explanation
• Actor List
• Assumptions about Use Case
• Pre-Conditions
• Normal Scenario
• Inputs
• Outputs
• Alternate Scenario
• Post Conditions
• Business Rules

Following is a very simple example:

Interview Use Case Scenario Template:

Use Case # 001
Purpose or Goal: Let the user view a stored customer
order.
User Actions System Response Alt Flow

1 User Enters Customer Number Customer Order is displayed. 1

Alternate Flow Return

1 Error-No such customer order
exits. 1
 BUSINESS ANALYSIS – THE REAL WORLD

Use Case Text Notation (Narrative)

Behind each Use Case is a series of actions to achieve the proper functionality,
as well as alternate paths for instances where validation fails, or errors occur.
These actions can be further defined in a Use Case description. Because this is
not addressed in UML, there are no standards for Use Case descriptions.
However, there are some common templates you can follow, and whole books
on the subject of writing Use Case descriptions.

Common methods of writing Use Case descriptions include:

• Write a paragraph describing the sequence of activities in the Use Case.

• Describe “Happy Path” (Normal Flow) first – All else is Alternate Flow.
• List two columns with the activities of the actor and the responses by the
system.
• Use a template to identify actors, preconditions, post-conditions, main
success scenarios, and alternative flows.

Remember, the goal of the process is to be able to communicate the

requirements of the system, so use whichever method is best for your team
and your organization to understand.

As an alternative, while taking notes during interviews, responses might be

captured in the following format:

This example will use the basic flow of the scenario of the overused “Make
Hotel Reservation”:

The use case begins when a customer wants to reserve a room(s).

1. The customer enters a request to reserve a room.

2. The system shows the type of rooms available and their prices.
3. The customer chooses a room type and specifies start and end dates.
4. The system checks availability for the room type.
5. If a room of that type is available, the system computes deposit charges
based on the room type and length of stay. It then prompts the customer to
confirm the reservation. (Alternate flow if the room is not available).
6. The customer confirms.
7. The system requests the customer's credit card payment details.
8. The customer submits credit card payment details as well as personal
details: name, email address, and billing address.
9. The system sends the transaction to the credit card payment center and
creates a new reservation with a unique reservation number.
10. The system sends a confirmation email to the customer.
 BUSINESS ANALYSIS – THE REAL WORLD

11. The system displays the reservation details, including the room type, start
and end dates, and reservation number.
12. The use case terminates.

Remember, the information that you document in a use case scenario includes
what actors are involved, the steps that the use case performs, business rules,
and so forth. For each action and communication in a Use Case develop a
scenario. A use case specification document should include the following:

Use Case ID, Use Case Name, Brief description, Assumptions, Actors,
Pre-conditions, Normal Scenario, Inputs, Outputs, Alternate Scenarios,
Post-conditions (see example following).

Sample Use Case Scenario to Generate Reports:

Use Case Name Generate Financial reports abbrev. I.D. UC04
Explanation: This use case describes the user producing reports.
Actor List (invoke or receive results)
1. User
Assumptions about Use Case (concerns, givens, constraints)
1. The report element table resides on the Web Server.
2. The report element table has been updated to reflect the latest changes
3. The reporting database has been created and the calculations performed.
Pre Conditions (situation before Use Case starts, if any)
1. The user signs on and is authorized and authenticated.
Normal Scenario (step by step description of the normal flow of events)
Action Alternate Includes Use
(what is done) Scenario Case
(Entry Point) (abbrev)
1. User selects report type: 1a
• National Reports - Detail
• National Reports – Summary
• State Reports – Detail
• State Reports - Summary
2. System displays the report type options selected.
3. National or State review team selects options for 4
National Report - Detail:
• State or ALL States
• Program Area
• Optional report format output
4. National or State User selects options for National 5
Report-Summary:
• Program Area
• Optional report format output
5. National or State User selects options for State 6
Report-Detail:
• Specific State
• Service Center or ALL Service Centers in state
• Optional report format output
6. National or State User selects options for State
Report-Summary:
• Specific State
 BUSINESS ANALYSIS – THE REAL WORLD

• Optional report format output

7. National/State User submits report options
8. System displays the report using the Review Element
Table and the Reporting Data Base to produce the
reports.
9. System launches the application for the chosen report
format (i.e. Browser, Excel or Adobe Acrobat)
10 End of Use Case.
Inputs
1. National office User selects report type
Outputs
1. Reports are displayed.
2. Exported reports to the chosen format.
Alternate Scenario(s) (step by step description of any alternate flow of events)
Action Alternate Scenario Includes Use Case
(what is done) (Entry Point) (abbrev)
1a. National or State User chooses 10
not to run reports.

Post Conditions (situation after Use Case ends)

1. Reports are displayed.
2. Reports are exported to the chosen format.

To facilitate traceability of requirements, a summary table of the use cases will

assist in tracking of all use cases:

Primary Actor Use Cases (Business Processes) Date / Name