Use Cases: Fundamentals — Part 1/2

No matter if Product Manager, Product Owner or Business Analyst: We hardly can get around the one core task, which is to specify Use Cases.

Use cases describe what a system does for someone. A use case is a sequence of actions that lead to an observable result. The result is valuable for someone. This someone is called the actor. The actor triggers something, and the use case describes how the system reacts to this trigger and what it does for the actor.

This article will describe the most common techniques and standards.

Regardless of hardware, whether it be departments or software, we want to manage a process chain. We want to break it down into business processes. The goal of this breakdown is value creation — operational value add.

In other words, we are replacing the traditional top-down/bottom-up way of thinking about the boss and employees and departments with a “west-east view.” A view from the supplier to the client, i.e., if we are active in the manufacturing industry. We buy raw materials somewhere and process them in several steps — hoping that the end product will bring more money than the costs of purchasing and our work.

That is an added value. If we are in the service industry, then it goes from customer to customer. The customer inquires. We have several processing steps that hopefully add value, so we can charge more money for the result than we put in work.

We should continuously think laterally from the outside through the system instead of thinking in internal structures.

Our goal is to classify all functional requirements in the form of processes. Moreover, we portray these processes as a use case model.

It consists of two main components:

  • UseCase Diagrams
  • and the corresponding UseCase Specifications

The diagram is the graphical overview of the desired functionality. It contains the actors that act as triggers and want something from the system. On the other hand (inside the system), the use cases (or business cases) that fulfil these wishes of the actors. The actors are connected to the processes via associations.

This image shows us which actor would like to have carried out which process. And since there is not much in this ellipse representing the use case except a name, we need a use case specification as a colloquial description of what the system should do from the actor’s point of view.

Let’s take a closer look at the main elements of this Use Case Diagram.

Let’s start with the actors. The most important you shall know about actors: Actors are outside the scope, but in context. So you see how important it was that we drew the line at the beginning of the project to know what is outside and what is inside.

Since by definition, actors are always outside this boundary, they want something from our system. Ivar Jacobson has invented stick figures as a notation for the actors. The idea comes from the fact that often the system under consideration is a computer with software.

And the actor is the one with his fingers on the keyboard who operates this system. But the system cannot be just a computer with software. The system can be a whole computer center. The system can be a whole company or a main department. Of course you can imagine a neighboring department behind the stickman as a trigger or you can see a customer who wants something from the whole system.

Maybe you also have processes that are not triggered by humans but by other software systems. The output from a (neighboring) software system is input and trigger for them. If, for example, a result comes out of SAP, we shall do a post-processing in our system; this would be the stickman “SAP” (or any other software system). So triggers cannot only be people or organizations. Triggers can also be other software systems.

Trigger can also be hardware. Triggers can be sensors that measure temperatures or pressures. Whatever causes your system to perform a process is “actor” in the sense of Ivar Jacobson. Therefore, the stick figure as symbol is a bit misleading.

Just remember: The trigger is always in context, always comes from
outside and want something from my system, no matter if you look at the Business Scope or have reduced it to the Product Scope. It is definitely always outside, in context.

The counterpart inside are the use cases or application cases or business transactions or business processes. These specify a sequence of steps that our system performs to create added value for one or more actors.

A Use Case is a step sequence of actions that is executed,
to generate an observable result. And this observable result will hopefully bring added value to one or the other. Think of the advantage for somebody. Who benefits from? We wouldn’t want to have the functionality if nobody got anything out of it.

So the actor triggers something and the use case is the system’s reaction to this trigger; the functionality that the system shall execute to create an added value for the actor. And now it depends on your scope.

If your whole company is the scope, then the Use Case goes right through the whole company. If only this department is the scope, then the use case goes across this department.

So please never sit the following three people at the same table:
an overall system manager for a software and hardware project together with the head of software development and the designer responsible for the user interface to discuss use cases.

Each of the three will have a different scope in mind: the overall system, only the software or only the user interface. And they will never be able to agree on what the use case is now.

So you always need your limits for a reasonable use case discussion:
Where does this use case begin and where does it end? But you can apply the technology to any system you like: to large systems, for medium systems and also for parts of them, for small systems.

Lead Business Consultant • Germany