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.
