Imagine you are creating some kind of software, for example a mobile application for ordering food. What functionality should be implemented in this application? Let's create a restaurant search on the map. User will love it, or not… For sure you don’t want to spend money and time on useless features. Oh, let’s start with basic functions, such as allowing users to place food orders. But what else?
Here you need to define the requirements. These may cover various areas, such as what the business wants to get, what users want to get, and how the app works and looks like. To solve the mentioned problem (what to implement for the client) you can use one of the user requirements - use cases.
Use cases describe the expected ways in which a user (or other actor) can interact with an app (or other system) to get some result. A use case is an expected behavior of a system (what), not the exact implementation (how).
For example, in a mobile application for ordering food a user can choose a restaurant and some dishes, create an order, and so on. These are all different use cases.
Let’s find out what use cases are, why they were invented, and how they look like.
Who came up with use cases and why?
The Use cases approach was created over 30 years ago by Ivar Jacobson and published in the book “Object-Oriented Software Engineering - A Use Case Driven Approach” in 1992.
Remarkable thing here is that Ivar Jacobson is one of the pioneers in object-oriented architecture and one of the three principal authors (three amigos) of UML (Unified Modeling Language), which is still high-demand in requirements elicitation and software design.
Before Jacobson's work, use case requirements focused on the functions of a system, but Jacobson had a vision to enrich them with an understanding of the context and sequence of user actions. Initially, Jacobson used the terms "usage scenarios" or "usage cases" and then moved on to "use cases".
UML includes different diagrams, one of which is Use Case Diagram. As Jacobson's book gained popularity and UML became more widespread, the use case approach became more popular. By the way, the Use Case Diagram remains one of the most widely used diagrams in UML.
Since then, the use case approach has been developed and refined by many authors, including Ivar Jacobson himself. As a result, the approach has expanded beyond the classic use case diagram in UML, but the main concepts remain the same.
What is a Use Case?
A use case describes a scenario of interaction between different users with the system, leading to a result. Gurus of requirements Karl Wiegers and Joy Beatty define use cases like this in their book "Software Requirements":
A use case describes a sequence of interactions between a system and an external actor that results in the actor being able to achieve some outcome of value.
In the UML guide “Unified Modeling Language User Guide” Grady Booch, James Rumbaugh, and Ivar Jacobson provide the definition of a use case as:
A description of a set of sequences of actions, including variants, that a system performs that yields an observable result of value to an actor.
Jacobson himself describes use cases in the following statements in his book "Use Case 2.0":
- A sequence of actions a system performs that yields an observable result of value to a particular user.
- That specific behavior of a system, which participates in collaboration with a user to deliver something of value for that user.
- The smallest unit of activity that provides a meaningful result to the user.
- The context for a set of related requirements.
Let’s point out 4 main points from all these definitions:
✓ there is a system you study or design
✓ there are different actors, mainly users of the system
✓ you have to describe each interaction between a system and each actor
✓ and there is a result of each interaction that creates value for involved actor
Examples of use cases:
Who and where can use it?
The major feature of use cases isn't just that it's an easy to use and understand technique to work with users' requirements, but that it affects the whole development lifecycle.
Let’s see how and in what scenarios a use case approach can be valuable for different IT roles.
- Use cases help specify what functionality of the system is needed, so it's a helpful tool for business analysts and managers to elicit requirements from the user's perspective.
- By describing the key use cases of the system, software engineers can get a “slice” or a top-level view of all system’s functionality, and this helps them in finding and designing the application architecture.
- At the same time, quality analysts (testers) can make use of it too and identify tests based on use cases to check the implementation of the system.
- Additionally, use cases allow software engineers and architects to identify core components which guide the architecture work to achieve software reuse.
- Moreover, use cases break down the software into separate valuable scenarios – ready-to-use elements for backlog when planning sprints or to put on the Kanban board – being a useful tool for managers.
Use cases are valuable for all roles, but depending on the role, the filling of use cases might vary. While going from product managers and analysts to developers and QA, the focus goes from an abstract/business level (considering users and their goals) to product level with more technical details and enabling functionality.
In addition, not for all systems use cases approach will be sufficient. Use cases work well for exploring the requirements for applications and systems where a user controls a piece of hardware or interacts with it. On the other hand, there are also systems for which the requirements will be more specific. For example, computationally intensive systems or data warehousing. The complexity of these applications lies not in the user-system interactions, but in computations or algorithms performed. There might be a few simple use cases, but complex system requirements.
Text vs Diagram
Use cases can be depicted:
- as a diagram
- as a text
It’s easier to provide more information about a use case in a text or table view. Also, some people find it faster and easier to create and edit text than a diagram. On the other hand, diagrams help users absorb information better, and there are plenty of great editors to work with (such as draw.io or pluntUML).
Some authors suggest making a choice according to the following logic:
- diagrams – for modelling top-level behaviour,
- text (tables or just text) – for more detailed description of use cases.
However, there are no strict or generally accepted rules, so it's up to personal preference. Jacobson used sticky notes for tracking use cases in his book, which also worked well.
Note that both views (text and diagram) should be acceptable for understanding. If there is too much information, you should break it down into several levels of detail.
Conclusion
This marks the conclusion of the first segment of the Use Case Chronicles. The second part will concentrate on the structure of use cases in different views and examples.