Share with your network!

How to Write Effective Use cases

Use cases are used widely to document the business logic and system processes. But there are a lot of opinions on whether they are useful and how they should be structured. In some projects, the developers never look at the use cases saying they are verbose or they really don’t understand much from them. What can a business analyst do to make use cases really effective?

Most of us are aware that use cases describe the business process and are the specifications for the interactions between the system and actors for particular goals. A use case document is different from a requirements document and is not the same as a design document.

Let us look at the two examples of use cases for the requirement. Which of them do you think is a better one.

Example – 1

Use case details Comments

Use case Name – Order Tickets

The name is good. It clearly gives an indication of what the use case

Goal –The customer successfully books tickets for the football match on the website

Description- The actor visits the website, views the
schedule, selects the match
and seats, books the
ticket and makes the payment for the football match

The goal and description are clearly mentioned.
This will help the designers
and developers understand what is the
goal of their design documents and code

Actors – Customer, Customer Service Representative
Pre-conditions – The system is up and running.
Trigger – The actor has accessed the system to book tickets.
Post-Condition – The actor is able to book tickets. The system updates the information.

All other use case details such as Actors,
preconditions, post conditions and
trigger are mentioned which will help the
design and development of the application easier.

Main Flow – Steps

  1. The actor accesses the website and selects to book tickets
  2. System displays the booking information
  3. The actor confirms the match details (More details in UI specification)
  4. The actor confirms seat details (More details in UI Specification)
  5. System confirms availability
  6. System presents form to get user information
  7. The actor gives user information (Details in another use case)
  8. System presents form for payment information
  9. The actor gives payment information (Details in another use case)
  10. System confirms details and gives a booking ID
  11. The actor saves ticket
  12. The actor exits the system.

Included Use cases

  – Make Payment

  – Generate Booking ID

Extended Use cases

  – Generate Payment Failure Note

  – Print Ticket

The steps in the main flow are clear but
UI details are left out. UI details in use case
regarding seat selection and match
selection can make the use case unwieldy.
The use case clearly shows what the actor has to do and what the system will do
The payment process is detailed in a
different use case so that tasks can be
easily broken down into different design components.
Included and Extended use cases are named
so that one can
reference them for further details.

Alternate Flow

  -cancel Tickets

  1. Actor cancels transaction
  2. System cancels transaction

Exception Flow

 -Tickets not available for selected match/selected seats

1. The system displays an error message

Alternate and Exception Flows are detailed out.

* The use case can be more detailed in terms of the references and alternate and exception flows. This example is to highlight what should be encompassed in a well-written use case.

Example – 2

Use case details Comments

Use case Name –  Ticket Ordering

The name is not from a user perspective and seems like a business process definition.

Description– The actor  visits the website, views the schedule, selects the match and seats, books the ticket and makes the payment for the football match

The goal of the use case is missing. Designers, Test Analysts and developers will not understand why this functionality has to be developed.

Actors – Customer, Customer Service Representative
Trigger – The actor has accessed the system to book tickets.
Post-Condition – The actor is able to book tickets. The system updates the information.

The pre-conditions are missing.

Main Flow Steps

  1. The customer accesses the website and selects the option ‘Book Tickets’ ‘to book tickets
  2. System displays the list of matches in a dropdown.
  3. The Customer Service Representative selects from the dropdown
  4. The system displays the seat details in a map of the seats
  5. The actor selects seats. If the seats are not available and error message is displayed.
  6. The actor gives payment details
  7. The actor books the ticket else cancels the ticket.
  8. The system generates a booking id using the customer’s first name and a randomly generated 4 digit number

Included Use cases
– Make Payment

In the use case steps, there are some references to actual UI elements which can confuse the reader. Alternate flows are written within the main flow which makes it hard to understand the whole process.
The actor is referred to by many names – ‘Customer, Actor and Customer Service Representative which is confusing.
The generation of booking id is explained here though it is of no concern to the actors related to ordering tickets.
There are no alternate flows, exception flows and no mention of all related use cases.

This use case lacks clarity and detailing and will not help the team in developing the functionality properly.

What should be in a use case What should not be in a use case
  1. Name
  2. Description/Goal
  3. Pre conditions
  4. Trigger
  5. Basic Flow and Alternate Flows
  6. Exception Scenarios
  7. Post conditions
  8. Special requirements if any
  9. Link to the UI details and other related models/diagrams
  1. Implementation details
  2. Internal processing
  3. Non-functional requirements
  4. User Interface details should be done simultaneously with use cases but in a separate document

.

Some tips to follow to write useful use cases :

  1. Write the use case steps from the actor’s perspective.
  2. Use cases should not have design and architectural details. It should concentrate on the business process.
  3. It is better if the steps in the use case are written in a time-ordered way
  4. Depending on the requirements and complexity, decide if CRUD (Create, Read, Update and Delete) operations need to be kept in separate use cases or they can be combined on one.
  5. It is important to give references to and from alternate flows, exception flows, included use cases and extended use cases so that the business design is complete.
  6. Choose a template (project defined, company defined or any detailed one) and follow the structure for all use cases.
  7. It is important to have use case diagrams.
  8. In Agile, we have user stories to capture requirements. User stories can be detailed out using lean use cases in an iterative fashion.
  9. Validations should be detailed out.

After you have written a use case, ask these questions and it is an effective use case if the answer is “Yes” to all questions –

  1. Will the user know when the business flow present in the use case gets executed?
  2. Is it clear as to who will perform what step of the use case?
  3. Is the description of the business logic such that there is enough information for analysis, design, development and test?
  4. Are there proper references from main flow to alternate and exception flows?
  5. Is there a use case diagram present?

Use cases are an effective way to capture requirements and formally document business processes if they are well-written. The entire team should be coached to use use cases to do their tasks. Use cases and use case diagrams are a great way to discuss business processes with clients. It is better to have a standard use case template with guidelines on writing use cases. Use cases written this way will be valued by all project team members and stakeholders.