What is a Use Case?
A use case describes how a person who will use that system or process will accomplish a goal. It is typically used with software systems but can be used in reference to any process. The use case is used to describe the steps in how you would achieve something, for example, how a developer would achieve a new system. It identifies the errors that could occur during the process and design features to resolve those errors. Instead of using models and diagrams to explain how a system or process would be accomplished, a use case is a textual description that captures the user system interaction. The description of a use case needs to be specific in terms of how the user will interact with the software. It isn’t like a business process that looks at the bigger picture of an organisation.
What is included in a Use Case?
The three main elements that make a use case are:
- An Actor – in other terms, the user, which can be a single person or group of people who are interacting with the process or system.
- The System – the process that is required to accomplish the final goal.
- The Goal – What you deem to be a successful user outcome.
A more complex use case will include these three elements:
- Stakeholders – These are the people who have an interest in how the process or system will turn out, even if they are not the direct users.
- Preconditions – These are the things that must be true before the use case can run and be implemented.
- Triggers – This may be an event that occurs in order for a use case to begin.
Before you start to write a use case, you need to identify the requirements which are needed to accomplish your goal. This would include meeting with those who will use the system and design the system, so they understand the goals. The user is the best source as sometimes the designer may not be able to represent all of the possible real-world scenarios.
Writing a use case is a bit like writing a flow chart without the lines and yes and no answers. It is a sequence of tasks that need to be completed to reach your end goal. But within those tasks, you need to identify errors that occur, no matter how large or small they could be which may delay you from accomplishing the outcome. If an error does occur, you must note down the description of the error, what the actor did to rectify this error and the outcome of how you are moving forward to carry on the process.
Why are they used?
It is beneficial for business analysts to custom use cases as it is an easier way of communicating to the team about the systems that needs to be created. It is an efficient way of clarifying what you’re building is right and that it matches what the business actually needs for when the developers sit down and code. As a business analyst, you do not need to have technical knowledge to create a use case. You need to ensure that you’re clear about what the technology needs to do, rather than worrying about how the technology works. Using a use case as an observable functionality tool that is used to communicate effectively to developers is one of the main things a business analyst should take from the tool.
Use cases can be employed during several stages of software development, for example, planning system requirements, designs, testing and creating an outline for online help. Keeping your use case more balanced will help not to lose focus on the final outcome, as putting too much into a use case can sometimes render the useful techniques of a use case.
Use cases are useful for business analysts to conduct as they are a great tool to help ask smart questions which may uncover gaps in thinking and understanding requirements. The use case will also help a business analyst to identify what you want to bring to the table and will help them to understand technology without having to build the technology.
Read more about business analysts.