What are use cases? Definition and examples

What are use cases? Definition and examples 994 537 Christian

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:

  1. Uses cases Definition
  2. What are the benefits of use cases?
  3. How to write use cases?
  4. Important questions for formulation
  5. These are the advantages
  6. Use cases in practice
  7. Examples
  8. Use Case vs. User Story: What’ the difference? 
  9. Conclusion

 

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.

Discribtion of a use-case

Use cases: Beneficial for a variety of systems | source: canva.com

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 Meaning

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.

 

What are the benefits of use cases?

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.

Man stands in front of a visualized business strategy

Use cases: An important part of working strategies for systems of all kinds | source: canva.com

 

How to write use cases?

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
  • Participants
  • 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.

Ready for take off?

Are you looking for an efficient way to improve communication in your company? Then only with the innovative digital signage software by FRAMR! Try it for FREE.

Important questions for formulation

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?

 

What are the advantages of use cases?

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.

 

Are there also disadvantages?

Depending on the prerequisites and requirements, there are also disadvantages with use cases. The focus of use cases is on the main functionality, therefore details are neglected and unexpected scenarios remain overlooked.

Another disadvantage is the complex, partly statistical nature of use cases. The number of use cases and their interactions increase rapidly, making management difficult. It is further complicated by the fact that use cases do not capture all changes.

 

Use cases in practice

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.

 

Use Case examples

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.

 

Use Case vs. User Story: What’s the difference?

Use cases and user stories are two different techniques used in software development to describe requirements and functionalities. Both techniques aim at understanding the needs of users and planning the development of software products.

The differences are based on four levels:

  • Abstraction level: Use cases describe the interaction between users and systems over several steps and scenarios. User stories, on the other hand, are less abstract and focus on a specific user requirement.
  • Structure: Use Cases are well structured with a description, precondition, trigger, main flow, and alternative flows. User stories, on the other hand, are less structured and are often written according to the format “As a [user], I want [feature] so that [benefit].
  • Details: Use Cases are very detailed and usually include multiple scenarios. User Stories are less detailed so they remain more adaptable.
  • Use in agile development: Use cases tend to be used less in agile development methods such as Scrum. They are too extensive for this. User stories, on the other hand, are used more frequently because they are flexible and can be easily implemented in short development cycles.

 

Final advice for usage

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.

 

Conclusion

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.

Contact us