Is an actor always a stakeholder in a UseCase diagram?

Question

This is a question confused me for a rather long time.

For the definition of stakehoder, I can understand that a stakeholder is not always an actor. For example, to build a nuclear power station, the National Nuclear Safety Administration may be a stakeholder, but it does not interact with the station, so it's not an actor.

But on the other hand, is an actor always a stakeholder?

Consider this: we build a underground cable system, and some rat bite the cable. In usecase analysis, I would like to model the rat as an actor, but it is definitely not a stakeholder of this system.

Answer 1

Well, the rat has an interest in not being electrocuted. So, it is a stakeholder. The question is, how important you consider it to be. Probably not so much.

Also, you would not analyse the use case "satisfy hunger for cables". Rather you should analyse how to "protect cable against rat bites". Both are valid use cases, but I assume, that you don‘t want your system to be used in the first way and therefore you should not model it. The second one is only a use case, if your system shall have functions to drive off rats.

The UML doesn‘t say much about how to describe use cases. I always recommend to describe them from the viewpoint of the stakeholder for whom the result is of value.

Answer 2

In short

Yes, every actor is always stakeholder. But not every stakeholder is an actor.

Some more thoughts:

First definition

In the UML specifications, there is no definition of stakeholders. But it is said that:

[A use case] specifies a set of behaviors performed by that subject [i.e. the system], which yields an observable result that is of value for Actors or other stakeholders of the subject.

This wording also suggests that actors are stakeholders: if they weren't, the word "other" wouldn't be needed.

By the way, this clearly eliminates the rat from the suspected actors, since the cabling system is not supposed to produce results of value for rats. And the result that could be observed on the rats is not of value for the other stakeholders.

How are stakeholders related to use cases?

Many systems produce an observable result that is of value for the actor interacting with the system: the actor benefits of cash after a withdrawal, the actor could achieve a task with the system, etc...

But the value is not always for the actor. If you walk through a body scanner at the airport, as a user you might not fully value the results of being scanned yourself. But the airport, the airline, homeland and security, and the other passengers may very well value the result of the use case. This shows that not all stakeholders who have interest in a system, are necessarily users.

Second definition

As strange as it may sound, the SWEBOK does not define the stakeholder either. They just enumerate some examples, such as users, customers, regulators etc. ISO 21500 does also have a definition by example.

Moreover, we must keep in mind that the interest of a stakeholder is not only the own benefit, but could be the opposite. If your neighbor installs a video surveillance system with a camera that captures the entry of your house, you're neither the customer, nor the user, but you will probably be a stakeholder perceiving a threat for your right to privacy.

A popular definition is therefore the PMI's:

An individual, group or organization that may affect, be affected or perceive itself to be affected by a decision, activity or outcome of a project, programme or portfolio.

We can cross check that according to this definition that all actors are stakeholders, since they will be affected by the future system.

And the rats?

Rats are in principle not actors of an underground cabling system, as the system is not build for providing them value nor to involve them to provide value to other stakeholders. Rats could be considered as stakeholders if we'd extend the concept to animals: they may be affected or think to be affected by all this cables. Bust most probably, they are simply a source of malfunctions in the system's environment.

This reminds me a story that an old system engineer told me 30 years ago, and that happened to him at the begin of his career, probably another 30 years before. It was on his first bigger computing project, a large electromechanical computer designed to compute the payroll of a large organisation. For some reasons, there were some mistakes every month, but never the same. After months of (expensive) debugging, they found out that some rats indeed have eaten the hull of some cables in the floor space under the very large computer, and if a rat by chance walked on the wires at the wrong moment, it closed random circuits that were supposed to stay open. A more modern version of the first bug?