During a requirement collection and the planning phase, business users or managers need to understand how the consumers will be interacting with a product that is being built. The details will include the users of the product, their way of interaction, and what the product does.
For stakeholder communication, product managers will need to understand how the consumers will interact with the product. This includes the users of the product, their way of interaction, and what the product does. The best way to virtually represent the information and bridge the gap between the business justification and the technical requirements is by creating a use case.
What is a use case?
A use case is a written description of how a user interacts with a system or product. It outlines the interaction between the users and the system as it responds to every request by the user.
Who creates use cases and why?
Business analysts — They document user-focused use cases that are completely focused on the user and their objectives
Technical persons — they add technical and design elements, which are product-focused use cases. This detail gives them an insight into the design, development, and testing of the product and its features
Benefits of use cases
Use cases add values as they explain how the system should behave and at the process level, it explains what could go wrong. They provide a list of goals, and this list can be used to explain the complexity of the system being developed.
What does a use case include? And what it does not?
A use case includes
- Who is the user of the product
- What the user wants to do or can do in your product
- The goal of the user
- The flow of the user to get a task done
- How the system responds to the action requested
A use case DO NOT include
- Implementation plan
- Details of the screen
Example
How to write a use case for a project?
Use cases are requirement artifacts, and they ease communication across technical and business teams. A use case document should establish and identify a few key components — these are:
- Actors: are users who perform an action when interacting with the system;
- Stakeholders: are primary actors who initiate the interaction with the system;
- System: a sequence of actions and interactions between actors and the system;
- Goals: The end result of the use case. A successful diagram should describe the activities and variants used to reach the goal;
- Preconditions: what should be true or happen before and after the use case is executed;
- Basic flow: a use case in which nothing goes wrong;
- Alternative flow: a deviation from the primary success scenario (basic flow) is the alternative path or alternative flow. These exceptions are when things go wrong at the system level;
To write a use case, refer to the following steps:
- Identify who is going to be using the product
- Pick one of the users from the list
- Define what that user wants to do with the product. Each thing the user does on the product becomes a use case.
- For each use case, decide on the typical flow of events when that user is using the product.
- Describe the basic course in the description for the use case. Describe it in terms of what the user does and what the system does in response that the user should be aware of.
- When the basic course is described, consider alternate courses of events and add those to «expand» the use case.
- Look for common points among the use cases. Extract these and note them as common course use cases.
- Repeat steps 2 through 7 for all other users
Use case template
Cards
