WHAT ARE USE CASES?
DEFINITION & EXAMPLES
Below you will learn everything you need to know about use cases. Definition, advantages, examples and more.
In this article:
- Uses cases Definition
- What are the benefits of use cases?
- How to write use cases?
- Important questions for formulation
- These are the advantages
- Use cases in practice
- Use Case Examples
- Final advice for usage
In a nutshell:
- Use cases are application scenarios which describe the externally visible behavior of a system from the user’s perspective.
- There are two known approaches for use case scenarios.
- The goals of use cases should be specified as good as possible.
Use Cases: Build the fundament for your product- or business development
What must a system do? This is a question that keeps many companies busy when developing new products or ideas. The integration of new systems, participants and system borders provide a good overview in the stage of development, even for systems with more complex requirements. This ultimately ensures that there are no unexpected hurdles or even serious errors when using an application.
The opportunities to perform use cases are different but many like to use diagrams because they give a good overview. Other than that, diagrams come with the advantage to give visual insights of details and relevant requirements. That results in the perfect fundament for development of your products or business models. Before that, it’s important to know what use cases are and which benefits businesses have, how the requirements are defined and what use cases look like in practice.
Use cases describe the documentation of system functions. It doesn’t matter if the system exists or if it’s still in the stage of planning, because regardless of this, the goal is pursued to describe the externally visible behavior of the system from the user’s perspective.
Users don’t necessarily need to be real persons, even systems and roles can be participants for use cases. These participants interact with a system to reach a pre-defined goal. The process is carried out according to a defined sequence, taking into account alternative sequences.
Originally, use cases were often applied in software development. As the requirements of processes within a system increased regardless of the industry, use cases are applicable in many different areas.
What are business use cases?
Business use cases are a specified variety of classic application cases and describe the interaction with business processes or business units. Stakeholders define goals and business use cases help to understand these goals and to elaborate them. One concrete difference between classic application cases and business use cases is the duration – system use cases are normally completed within a short period of time whereas business use cases take between several weeks or even months.
Use cases always pursue a goal, mostly the optimization of existing systems. That comes with the danger that the use case might end up in failure or even demolition. The interaction between participant and system pursues the goal to consider all eventualities and possible scenarios within a system in order to determine the necessary requirements. These scenarios aren’t always defined precisely which often leads to interruptions during the stage of testing. That causes higher costs through which use cases are interrupted or only partly completed. Basically, the benefit is to optimize systems from a participant’s point of view but a pre-defined goal isn’t always reachable because a few of the tested scenarios end with the result that not all requirements are fulfilled.
The original use case concept of Ivar Jacobson, which he created in 1987, can be divided in two different approaches.
The first approach is use case specification, which includes natural language information, so-called “narratives”. This information is written as a textual example and includes the following elements:
- Name of the use case
- Trigger event
- Description of process
- Detailed description of the single steps
- Description of alternative processes
- Conditions, that are relevant before and after the use case
- Presentation of hurdles and possible mistakes
The second approach is the use case diagram. This approach is systematically the same but diagrams are easier to understand because of visualization. Another difference to use case specification is that descriptions aren’t only related to procedures but to connections between the quantity of use cases and involved participants.
The choice doesn’t have to be either specification or diagrams. Both methods and their approaches complement each other in the use case process and in combination they provide exact evaluation of goals to determine the requirements of a system.
To write a use case properly, you can use specific questions to create the process as effective as possible in order to reach the desired goal.
The following 10 questions help you to create use cases
- Which participants use the system and what are their goals?
- How complex are the requirements with which the participants have to deal?
- Which goal must be achieved?
- How often is the use case performed?
- What are the requirements the use case has to fulfill?
- What are the requirements for a successful execution?
- Which scenarios are possible and what do alternative scenarios look like?
- What are the possible mistakes of every step of the application case?
- What are the different steps a participant has to go through?
- What are the reactions of a system to the interactions of a participant?
First of all, use cases provide clarity. The interaction between participant and system ensures that the system behavior is communicated understandable for users and that the requirements of a system with relations are clear. Use cases are easy to create and understandable for all involved participants. That provides businesses with more flexibility in defining system goals and the following execution.
The good overview also grants insights into details, for example information about a use case or a system. These insights give participants a better orientation through which the requirements are better defined.
The interaction between specification and diagram also allows a transparent mediation of details, which, thanks to visualization, are easy to understand.
Relations, systems, participants – at first glance, use cases sound very theoretical. Asking for a more practical approach is therefore quite justified here. Principally, use cases always have a practical component because the objective provides for testing functions within a system. Application examples range from using a coffee machine up to software testing, which is why systematic functions fulfill all the requirements for a use case. Your take-away for the practical use is: Use cases always pursue a specific goal which tests the relation between system and participant. As soon as the requirements, so participant and system, are given, a use case is possible.
To give you better insights into the practical side of use cases, we will take a closer look at an example for using a digital signage menu to complete an order in a restaurant.
Name of the use case: Using a digital signage menu in a restaurant and ordering food with it.
Participants: Two test subjects. One regularly goes out to eat at a restaurant, the other one for the first time.
Trigger Event: The digital signage menu is probably not intuitive enough.
Short description: Two participants test the functions of a digital signage menu, of which the operation probably has a mistake or is not intuitive enough.
Description of the single steps: The participant goes to the menu / hardware. He operates the hardware with his fingers and selects the dishes of choice. He reaches the checkout area via a field. He completes the order and pays. The participant is assigned an order number.
Description of alternative steps: The participant accidentally chooses the wrong meal and has to go back to the start. He wants to leave the checkout area to expand his order.
Pre- and post-conditions: It should be possible to easily and intuitively place an order.
System boundary and mistakes: Touchscreen won’t accept the input correctly.
That was more of a simplified example but that doesn’t matter. With this example you should develop a feeling how use cases work in a practical manner and especially how they work. Particularly complex applications require a detailed description with many participants and pre-defined alternative scenarios.
Try it yourself: Think of a scenario that suits your business and write it down on paper! You will be surprised which alternatives you can think of and how precisely such a process can be described.
Planning and transparency are important for successful use cases. Provide the involved participants with all the relevant information and involve as many employees as possible. But more employees also means that processes become more complex. However, the results promise a more detailed description of requirements.
Take the perspective of the participants and what goals they pursue. Through that, you will recognize the relation between the involved participants and the system. Furthermore it is important to define the pre- and post-conditions. Here is to be defined exactly, which requirements need to be fulfilled at the beginning and at the end.
The more precisely the working processes are defined, the better. It is not recommended to use automated or standardized processes because they don’t ensure an individual judgment of requirements.
Use cases offer a good opportunity to define systems and their functionality and to understand them better. The complex requirements come with danger of failures or unexpected obstacles but with the help of use cases it is possible to foresee these eventualities, test them and optimize the involved processes. Especially the optimization of business processes comes with advantages because companies can consider the wishes and goals of stakeholders more precisely.
Finally, we will answer frequently asked questions about use cases.
There is no specific format which you have to consider when creating a use case. Usually, use cases are shown as diagrams or textual workflows. Both methods complement each other to determine the requirements for a system as accurate as possible.
There are four different types of use cases: includes, extents, communicates and generalizes.
The trigger event describes what causes the use case to start. There is no guarantee that the trigger event will happen but only an indicator that this event will lead the use case to start.