RULE 2: Understand your stakeholders
A Stakeholder is a person, or group of people, with a vested interest in your system. Vested means they want something out of it – a return on their investment. That may be money; it may be an easier life.
One of the keys to requirements analysis is understanding your stakeholders – who they are, what they are responsible for, why they want to use your system and how it will benefit them.
It’s important to understand (and difficult for many software engineers to accept!) your stakeholders have responsibilities above and beyond just using your product. In fact, the only reason they are using your product is because it (should!) help them fulfil their larger responsibilities. If your product doesn’t help your stakeholder then why should they use it?
The first step in requirements analysis is to define your stakeholders. That definition must include:
- A named individual responsible for the stakeholder group
- The stakeholder’s responsibilities. That is, a description of the roles, jobs, and tasks the stakeholders have to perform everyday. If you understand a stakeholder’s problems and needs you can define solutions that help them
- Success criteria. That is: what is a good result for this stakeholder? The success criteria are a list of features and qualities that, if implemented, would bring maximum benefit to the stakeholder group.
Not all stakeholders are the same. For analysis, I divide stakeholders into three groups using my ‘stakeholder onion’ model:
Users are the most obvious group of stakeholders. Users directly interact with the system under development (sometimes I call them ‘Direct Interactors’). A system’s users are concerned with how things work – what buttons to press, what order events happen, etc. Their focus is therefore primarily functional behaviour and human-centred system qualities-of-service such as usability.
The beneficiaries have some need that the system fulfils (or some pain that needs to be taken away!). The beneficiaries therefore benefit (often financially) by having the system in place. Typically, these stakeholders will be paying for the system. Beneficiaries are less interested in function and more interested in quality-of-service – reliability, maintainability, etc. since if these requirements are not fulfilled it will cost them money!
The Users and Beneficiaries of a system are concerned with the problem they need to solve. The Constrainers are focused not on the problem domain but on the solution domain. The constrainers place negative requirements – or design constraints – on the system. They place limits on how the system can work, how it will be developed, or what technologies or methodologies may be used. Constrainers come in many forms – Legislation, Standards, The Laws of physics, to name a few.
Most engineers intuitively understand they are, in some way, a stakeholder in the system they are designing, but they often do not know how to express this. The development team itself is a Constrainer stakeholder, since it places limits on the technologies that can be implemented (lack of skills) or timescales (lack of resource).
Not only do the different stakeholders have different viewpoints, they also have different priorities on your project:
Beneficiaries’ concerns typically (but not always) outweigh user concerns. For example, in the conflict between usability (a user concern) and low cost (a beneficiary concern) who will win? Remember: He who pays the piper calls the tune…
Constrainers should over-ride beneficiaries. Legal requirements, standards requirements, skills shortages, etc. will always supersede the desires of the other stakeholders.
The core difference between Beneficiaries and Constrainers is that Constrainers CANNOT be influenced – that is, you can negotiate on functional behaviours or qualities of service, but you cannot negotiate away legal requirements or the laws of physics! A Constrainer either exists, in which case their criteria must be met; or they are not a Constrainer. The skill, therefore, is to reduce the number of Constrainers on a project to open up as many different design options as possible.
Where does all this fit into Use Case analysis? The answer is two-fold:
- Actors on a use case diagram are all stakeholders
- Stakeholder analysis gives context to the Use Case.
An Actor is an “external entity that interacts with the system under development”. In the simplest case, that means they’re a User stakeholder. The Beneficiaries and Constrainers also influence and affect the system behaviour, albeit in a very different way to the Users.
Actors, Stakeholder types and Use Cases is a potential source of problems; and we’ll discuss this in a later article.
The most important reason for performing stakeholder analysis is it gives context to the Use Case model. The Use Case System Boundary element defines the functional scope of the system – that is, what behaviours the system is required to provide – but it doesn’t give any reasons why the system has to provides those features. There is nothing on the Use Case diagram that gives any help in validating the Use Case model. We can add any behaviour we like to the Use Case diagram, provided we can link it to an actor.
By providing a stakeholder analysis we can validate the Use Cases by asking questions such as: Does the Use Case behaviour help the stakeholder (actor) fulfil their responsibilities? If the behaviour does not help any stakeholder fulfil their responsibilities, should we be implementing it, or have we missed a stakeholder? Are there other (additional) behaviours the stakeholder may need in order to fulfil their responsibilities?
- Practice makes perfect, part 3 – Idiomatic kata - February 27, 2020
- Practice makes perfect, part 2– foundation kata - February 13, 2020
- Practice makes perfect, part 1 – Code kata - January 30, 2020
Glennan is an embedded systems and software engineer with over 20 years experience, mostly in high-integrity systems for the defence and aerospace industry.
He specialises in C++, UML, software modelling, Systems Engineering and process development.
Pingback: Sticky Bits » Blog Archive » The Baker’s Dozen of Use Cases – Part 4