Sei sulla pagina 1di 4

BUSINESSBUSINESSBUSINESSBUSINESS ANALYSISANALYSISANALYSISANALYSIS –––– THETHETHETHE REALREALREALREAL WORLDWORLDWORLDWORLD

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

2

3

Alternate Flow

Return

 

Error-No such customer order exits.

1

   

1

 

BUSINESSBUSINESSBUSINESSBUSINESS ANALYSISANALYSISANALYSISANALYSIS –––– THETHETHETHE REALREALREALREAL WORLDWORLDWORLDWORLD

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:

9. The system sends the transaction to the credit card payment center and creates a new reservation with a unique reservation number.

name, email address, and billing address.

10. The system sends a confirmation email to the customer.

BUSINESSBUSINESSBUSINESSBUSINESS ANALYSISANALYSISANALYSISANALYSIS –––– THETHETHETHE REALREALREALREAL WORLDWORLDWORLDWORLD

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 (what is done)

Alternate

Includes Use

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 National Report - Detail:

4

 

State or ALL States

Program Area

Optional report format output

4.

National or State User selects options for National Report-Summary:

5

 

Program Area

Optional report format output

5.

National or State User selects options for State Report-Detail:

6

 

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

BUSINESSBUSINESSBUSINESSBUSINESS ANALYSISANALYSISANALYSISANALYSIS –––– THETHETHETHE REALREALREALREAL WORLDWORLDWORLDWORLD

 

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 (what is done)

Alternate Scenario (Entry Point)

Includes Use Case (abbrev)

1a.

National or State User chooses not to run reports.

10

 

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
Primary Actor
Use Cases (Business Processes)
Date / Name