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 |
The goal and description are clearly mentioned. |
|
Actors – Customer, Customer Service Representative |
All other use case details such as Actors, |
Main Flow – Steps
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 |
|
Alternate Flow -cancel Tickets
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 |
The pre-conditions are missing. |
|
Main Flow Steps
Included Use cases |
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. |
|
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 |
|---|---|
|
. |
Some tips to follow to write useful use cases :
- Write the use case steps from the actor’s perspective.
- Use cases should not have design and architectural details. It should concentrate on the business process.
- It is better if the steps in the use case are written in a time-ordered way
- 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.
- 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.
- Choose a template (project defined, company defined or any detailed one) and follow the structure for all use cases.
- It is important to have use case diagrams.
- In Agile, we have user stories to capture requirements. User stories can be detailed out using lean use cases in an iterative fashion.
- 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 –
- Will the user know when the business flow present in the use case gets executed?
- Is it clear as to who will perform what step of the use case?
- Is the description of the business logic such that there is enough information for analysis, design, development and test?
- Are there proper references from main flow to alternate and exception flows?
- 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.
Comments