BMIS 580
DISCUSSION ASSIGNMENT INSTRUCTIONS
The student will complete 3 Discussions in this course. The purpose of Discussions is to generate
interaction among classmates in regard to relevant current course topics. The student will post
one thread of at least 500 words by 11:59 p.m. (ET) on Thursday of the assigned Module: Week.
The student must then post 2 replies of at least 150 words by 11:59 p.m. (ET) on Sunday of the
assigned Module: Week. For each thread, students must support their assertions with at least 2
scholarly citations in APA format. Each reply must be different and incorporate at least 2
scholarly citations in APA format. Any sources cited must have been published within the last
five years. Acceptable references or sources include the textbooks, the Bible, and peer-reviewed
journal articles.
A Taxonomy of Stakeholders
25
Chapter II
Copyright 2007. IGI Global.
All rights reserved. May not be reproduced in any form without permission from the publisher, except fair uses permitted under U.S. or applicable copyright law.
A Taxonomy of
Stakeholders:
Human Roles in
System Development
Ian F. Alexander
Scenario Plus Ltd. & City University, UK
Abstract
Systems engineers have often paid too little attention to the nature of the so-called
“users” of products under development. These are better called stakeholders, as
many roles are involved, and few of those are in direct contact with the developed
products. A simple and robust conceptual framework for classifying development
stakeholders—a taxonomy—is proposed. The taxonomy is product-centric, with
concentric “circles” denoting broad categories of the stakeholder. Within these,
generic “slots” describe typical classes of the stakeholder; these are subdivided into
“roles,” which are expected to vary at least in name with the domain. Examples are
given, and a popular template is re-analysed using the framework. The taxonomy
has immediate value in identifying and validating stakeholder roles in requirements’
elicitation. This helps to ensure that key viewpoints on requirements are not missed.
That, in turn, reduces the risk of instability and failure during development.
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission
of Idea Group Inc. is prohibited.
EBSCO Publishing : eBook Collection (EBSCOhost) - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY
AN: 173380 ; Stahl, Bernd Carsten.; Issues and Trends in Technology and Human Interaction
Account: liberty.main.ehost
26 Alexander
Introduction
Motivation
The structure of stakeholder roles and their relationships, such as surrogacy, have
only slightly been investigated in the requirements’ world (although much more
extensively in the political, ethical, and information systems’ worlds: one reason
for believing that an attempt at an interdisciplinary look at stakeholders may be
worthwhile). Requirements’ work almost inevitably involves dealing with stakeholders of widely-varying kinds and hence demands a commensurately wide range
of elicitation techniques. The first step in identifying which techniques should be
applied is, therefore, to identify the stakeholder composition for a new project; and
this, in turn, demands a suitable taxonomy of stakeholders.
Too many projects focus their attention too closely on the product—perhaps especially when that is software—to the exclusion of non-operational roles and often
even of secondary operational roles such as maintenance. I suspect this is due to
“inside-out thinking,” where the “system” is seen as important and the “user” as
secondary. Such thinking is a hangover from the past. When I was at the university,
an IBM 360 mainframe occupied the only air-conditioned tower on the campus.
Students were permitted to approach the card-reader with a deck of punched cards;
only trained operators were allowed upstairs to see the computer itself. This was
truly a priestly hierarchy (Greek hieros = holy, arches = ruler) of operator roles. As
Christopher Locke writes, “Even the word ‘users’ is an artefact of the [commandand-control] mentality” (Levine, Locke, Searls, & Weinberger, 2000). It is time to
move on from treating “the user as a computer peripheral” (in Julian Hilton’s words).
The system is made for man, not man for the system.
Many industrial development problems seem in practice to be caused not so much by
a failure to write requirements as by a failure to perceive that specific stakeholders’
viewpoints were relevant. That failure causes whole groups of requirements, typically
those related to scenarios involving the missing stakeholders, to be missed.
A similarly unhappy result is obtained when one stakeholder, for example, a software developer, assumes one scope for a product, while another stakeholder, for
example, a purchaser, assumes another. For instance, when a developer assumes that
it will be sufficient to design, code, and test a piece of software, but the purchaser
hopes to have everything set up and the operators trained, then the points of view
of the installer, the trainer, and to some extent that of the operators have not been
adequately considered and made explicit. Legal disputes and financial losses are
then likely.
It seems likely that stakeholder composition is a good predictor of project risk; hence,
it should be cost-effective to characterise projects at their initiation according to
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
A Taxonomy of Stakeholders
27
their likely stakeholder impact (and to other variables, such as safety-relatedness,
technological innovation, similarity to previous projects, and so on).
In addition, maintaining a model of stakeholders throughout a development allows
changes in stakeholder composition to be modelled explicitly, leading to appropriate changes in requirements.
Stakeholder surrogacy has powerful and paradoxical connotations in requirements’
engineering. It is almost a dogma that projects should seek out ever-closer dialogue
with stakeholders—consider the current fashion for integrated project teams, facilitated workshops, rapid prototyping, agile development with user stories, and so
forth. Yet, all of the time the obvious truth is glossed over: that it is remarkably rare
to be able to talk to many stakeholders in the flesh. Every requirements’ engineer
knows that the basic answer to the client organisation’s boss who says, “I know
everything that happens in my department, ask me,” is “well, sir, that’s fine but can
I see if the people on the shop floor know of any small issues?” To put it more formally, standardised procedures, no matter how critical1 and how carefully defined in
writing, are always modified when operationalised “on the shop floor.” Therefore,
it is essential to talk to stakeholders directly—without intermediaries—to find out
what actually happens. Yet, requirements’ engineers are themselves intermediaries!
Stakeholder surrogacy is accordingly discussed at some length in the sub-section,
Surrogacy.
Worse, many kinds of stakeholder are inaccessible: they may be distant geographically; separated by contractual and procedural barriers; hidden within organisations
(with cultural barriers); simply unaffordably expensive to contact given scarce project
time and resources; or not yet in existence (for future products).
The naïve “go and talk to the users”—whoever may be meant by that phrase—is therefore far from helpful as advice. This chapter considers what we mean by stakeholder
roles on development projects and offers both a theoretical framework for classifying
them and some practical suggestions for making use of that knowledge.
It may be that the approach can be applied outside system development, for example, to model political and business stakeholder structures, but that is beyond
our scope.
Structure
This chapter is structured as follows:
•
The Proposed Taxonomy
•
Applying the Taxonomy in Practice
•
Research Review
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission
of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
28 Alexander
•
Discussion: Features & Limitations of the Taxonomy
•
Conclusion
The Proposed Taxonomy
A project’s stakeholder sociology can be modelled graphically on an onion diagram
(Figure 1). This deceptively simple-looking model documents a wealth of information about a project. It presents a view of the project that is centred on its product
and serves as an overview of our stakeholder taxonomy.
Figure 1. Onion diagram of product stakeholders
The Wider Environment
(mainly social)
Financial
Beneficiary
The Containing System
Negative
Stakeholders
(also sociotechnical)
Our System
Interfacing
Systems
(sociotechnical)
Sponsor or
champion
The Kit
or Product
(technical)
Political
Beneficiary
Functional
Beneficiary
Normal
Operator
Regulator
Operational
Support
Maintenance
Operator
Consultant
Purchaser
Developer
The onion diagram displays a customisable set of named “slots” (silhouette icons), containing stakeholder roles, in three or more “circles” centred on the “kit” or product. For example, “pilot” is a role
(not shown) in the “normal Operator” slot in the “our system” circle, where product is an aircraft.
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
A Taxonomy of Stakeholders
29
Structure of the Onion Model
This section introduces and defines the terms used in the onion model and the associated taxonomy of stakeholders. Terms are highlighted in boldface when they
are introduced and defined.
The onion model consists by default of a set of three concentric circles. Each circle
logically contains the circles drawn inside it. (The term “Annulus” may be used where
it is desired to refer to the contents of a circle without those of the circles it contains.)
Other circles may be added, most likely by subdividing the default circles.
Hence, a circle denotes a subset of entities in the world relevant to a development
project. Those entities are slots and circles.
The innermost ring (not strictly a circle) denotes the kit, a conveniently short term
for the equipment or product under development, whatever its nature, for instance,
software or electronics hardware. This could be a one-off piece of custom financial
software or a mass-market product, such as a handheld information device. It could
equally well be the tangible equipment for a large system, such as a railway line:
the system with its many human operators would, of course, be more than just
that equipment. The innermost ring thus differs from true circles in not containing
stakeholders.
A slot is a class of roles that is drawn by default (empty if necessary) in an onion
diagram. In effect, it is a prediction or suggestion that roles of a certain kind may
be important in a project. For example, “normal operator” is a default slot in the
“our system” circle. The existence of the slot is a prediction that, in any system,
there will probably be one or more “normal operator” roles. The slot might remain
empty in a supposedly “wholly automatic” system, though such a system might
still have other human roles such as installer, configurer, and maintainer within the
“our system” circle.
A slot is said to be empty in an onion model when it contains no roles. For example,
take a product like a distress signal flare. This product is fired by a sailor to attract
rescuers; whether it succeeds or fails, it is then disposed of. No maintenance work
of any kind is carried out on it, so it has no maintenance operator and that slot is
empty.
A role is a class of stakeholder with a distinct relationship to the product under development. For example, in a passenger aircraft, both the pilot and flight engineer
are roles within the “normal operator” slot.
A role is said to be a surrogate if it is conducted on behalf of another role, which
cannot speak directly for itself. For example, a product manager acts as the purchaser
of a new type of product until such time as the product can be sold on the mass
market; then the consumers buy instances of the product (or not) for themselves.
As another example, the regulator acts as a government-sponsored voice on behalf
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission
of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
30 Alexander
of the public to ensure safety, and so forth. Surrogacy is discussed in more detail
in following sections.
A role is said to be negative if it is associated with viewpoints opposed to the successful completion of the product’s development, its coming into service, or its
successful operation. Viewpoints do not appear in the onion model as such, but can
be documented briefly as text attributes of role objects in an associated database
(Figure 2), or in full as sets of requirements (not shown) linked to role objects. It
may be useful to document generalized viewpoints as attributes of slot objects,
summarizing a group of more specific role viewpoints. Tool support is discussed
in the sub-section, Tool & Template Support.
A stakeholder is an individual person or other legal entity able to act like a person
(e.g., a limited company, an industry regulator, a registered charity) playing one
or more roles. Note however that in accordance with common usage, we loosely
describe both slots and roles as “stakeholders” when the class/instance distinction
is not of immediate concern.
It would also be possible to limit the definition to “individual person;” this would
have the advantage of avoiding possible confusion between “Company XYZ” as
a stakeholder and “The Company XYZ Containing System” as a circle. Further,
while a suitably-placed individual (e.g., the chairman, the press relations officer)
can legitimately represent the voice of a company as a corporate legal entity, that
individual cannot legitimately claim to speak for each of the many roles within
the company as far as their viewpoints and requirements are concerned. There are
thus some dangers associated with treating legal entities as stakeholders; but, there
are obvious advantages. For instance, if a conservation body chooses to oppose a
development, its negative stakeholding can reasonably be treated as a single voice
in accordance with its legal status.
Figure 2. Viewpoints as attributes of traceable slot and role objects
In this example, “consultant” is a slot in the “wider environment” circle, containing two currentlydefined roles. Other attributes include “viewpoint” text (here with very brief examples); “Polar Angle”
(proposed by the tool) specifies where icons should appear on the diagram, and so on. Traceability
links (indicated by triangles) can be inserted between stakeholder roles and detailed viewpoint requirements, and so forth.
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
A Taxonomy of Stakeholders
31
Circles
The four default circles used in the onion model are:
1.
The Product or The Kit: The item under development (e.g., a software program,
a consumer electronics device, an aircraft, a communications network).
2.
Our System: “The Product” plus its human operators and the standard operating procedures or rules governing its operation (e.g., an aircraft with its crew,
operating manuals and aviation rules, etc.).
3.
The Containing System: “Our System” plus any human beneficiaries of our
system (whether they are involved in operations or not).
4.
The Wider Environment: “The Containing System” plus any other stakeholders.
Other circles may be introduced as necessary. For example, an additional circle
might be created outside “the containing system” to divide stakeholders relatively
closely involved with the project from those more distantly involved in the “wider
environment.” That might be helpful when a product forms a component of a
subsystem within a larger system. That is, when our product is a control box for a
train (the containing system), we might wish to consider a “wider system” circle,
namely a railway line with stakeholder roles such as line controller, and a “system
environment” circle, namely a complete railway network with roles such as network
timetable scheduler—as distinct from the “wider environment,” which might include
stakeholder roles such as the general public and the government.
The kit or product circle is considered to be the part of our system that can be sold,
so it does not contain humans. All of the other circles contain stakeholders. This
raises an apparent problem of consistency: since it is a purely relative matter which
system in the real world we consider to be “our system,” it is perfectly possible for
somebody else to treat our system as a component part of their product. What is
happening here, however, is that they are focussing attention only on the machine
(non-human) aspects of our system for the purposes of product development. The
stakeholders do not disappear, but they will either be treated as insignificant from
the (larger) viewpoint, or they will be promoted to the rank of stakeholder in the
larger product.
For example, if the larger product is a train, its normal operator is a driver. Our
component product, the train’s control box, is also operated by the driver, who only
appears once in the model—outside the product, the train, as one would expect.
The fact that the driver also operates a sub-product of the train (the control box)
does not make the driver a part of the product. Thus, at the level of detail of the
larger viewpoint, there is no need to consider separate sub-product stakeholders. In
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission
of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
32 Alexander
general, therefore, as long as one considers just one “our system” at a time, there
is no problem of consistency. A shift of viewpoint—to consider a larger or smaller
product—rightly causes a change in the perspective of the onion model.
One might ask whether distance from “the product” means less influence on the
requirements for it: this would be a simple application of the spatial metaphor of
the onion diagram. (See the sub-section, Visual Metaphors, for a more in-depth
discussion of a visual metaphor.) However, there seems no reason to believe this.
On the contrary, the approach here emphasises that stakeholders who never see the
product may be crucially important to a development project. As Coakes and Elliman (1999) say of their stakeholder Web diagrams:
The diagram is not intended to depict stakeholders from some judgmental
position such as degrees of power, influence, or interest. In particular, care
must be taken not to interpret distance from the central [Product] as an
indication of importance. Some of the most influential stakeholders may be
remote from the organisation. (p. 11)
A well-known example is the occasion where English Heritage stopped a rail resignalling project the day before it was to launch as an attractive red-brick Victorian
railway viaduct would have been demolished. No knowledge of signalling or interest
in it was necessary. It may be that different stakeholder “slots” come with presumptions about their likely (default) importance, but that is a weaker claim.
The Slots of the Onion Model
The onion diagram by default displays the following “slot” icons in the named
circles. Other slots may be added as necessary. In each case, they are defined, based
broadly on the framework of Sharp, Finkelstein, and Galal (1999):
•
the nature of the roles in the slot with respect to the kit;
•
the most likely interactions with stakeholders in other slots;
•
the stage(s) in development that the slot is most likely to be relevant; and
•
the likely priority (relative importance) of stakeholders in the slot.
Note that the following are what are considered to be the bare minimum of slots,
not an exhaustive taxonomy.
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
A Taxonomy of Stakeholders
33
Our System
•
Normal operator: Roles that involve giving routine commands and monitoring
outputs from the product, whether these are via a human-computer interface
or not.
Normal operators interact directly with the product, with other operators (e.g.,
maintenance, operational support) and with functional beneficiaries (e.g., providing
them with processed information and receiving instructions from them).
Operator requirements are relevant throughout development, but especially during
user interface design.
Operability requirements are always important, perhaps especially so for mass-market products (where operability is a selling-point) and for control systems (where
safety is involved).
•
Maintenance operator: Roles that involve maintaining the product, such as
servicing hardware and diagnosing and fixing faults. (So-called maintenance of
software involves changing the design of the product, and is the responsibility
of our developer slot; it is not maintenance in our sense.)
Maintenance operators interact with the product and with normal operators.
It is worth noting that now that outsourcing is in fashion, maintenance people may
be contractors. If so, there is a contractual boundary that crosses the “our system”
circle (and others outside it). This can easily act as a “geological fault-line,” impeding
communications and possibly rupturing if anything goes wrong. For example, some
organisations outsource their computer and network administration (maintenance
operations), while retaining normal operation of the equipment in-house. This typically creates bureaucratic delay and difficulty, which in turn creates tension between
the two roles. It may be helpful to draw contractual or other boundaries on the onion
diagram and to annotate these with their significance for the project.
Maintenance is often not considered until late in projects; however, maintainability
needs to be designed-in, whether as built-in test and diagnostics, internationalised
error messages, accessibility of equipment, or spares holdings. Requirements for
these need to be in place early in a development.
Maintenance requirements are often more important than they seem. The wholelife cost of many products—from cars to jet engines—depends much more on the
cost of maintenance than may be realised. Similarly, maintainability requirements
such as the time to repair or replace components can significantly affect quality of
service.
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission
of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
34 Alexander
•
Operational support: Roles that involve advising normal operators of a product
about how to operate it. These roles are very close to operations but support
rather than conduct productive use of the product itself. We have chosen to
include them in “our system” for two reasons:
1.
they behave as operational staff in their daily work; and
2.
like maintenance operators, they help to keep the system fully operational
(enabling the normal operators to continue working effectively).
Operational support people such as “help desk” staff and trainers interact mainly
with normal operators. They are “maintenance” for the humans involved, rather than
just for the product. The comments on outsourcing under “maintenance operator”
can also apply here.
The priority of support probably deserves to be higher than it is on many projects.
As with maintenance, good support raises operational effectiveness and availability. Clearly, it is secondary to other slots such as normal operator and functional
beneficiary.
Support needs to be considered when preparing manuals and training materials,
that is, relatively late in the project; however, supportability may also need to be
evaluated earlier, for example, when designing software to yield intelligible error
messages, and so forth.
Containing System
•
Functional beneficiary: Roles that benefit from the results or outputs created
by the product. For example, an astronomer benefits from the astronomic data
captured by a space telescope though he or she cannot operate the instrument
directly. Since products are or should be designed to produce results, this is
an important slot.
They interact with operators, giving them instructions and receiving information
and any other benefits that “our system” is designed to provide.
Functional requirements form the centrepiece of most specifications. They need to
be available early and are used throughout development, for example, in design and
for specifying functional tests. They are of the highest importance.
•
(Responsible for) interfacing system: Roles responsible for neighbouring
systems that have electronic or other interfaces to and from the product. Such
systems behave much like human operators in terms of demanding specific
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
A Taxonomy of Stakeholders
35
capabilities from the product, but, naturally, the interfaces are precisely defined
as protocols, and so forth.
They interact with operators and/or the product; any other interactions they may
have are most likely but not necessarily outside our scope.
Interface requirements form a crucial part of the definition of many developments.
They are required from the start. Shifting interfaces and scope are serious risks to
projects.
•
Purchaser: Roles responsible for having the product developed. There are
certainly several of these, ranging from product manager (with knowledge of
what can be sold) to procurement (responsible for obtaining a contract with
a supplier). In the case of a mass-market product, the purchaser is a product
manager—a surrogate role, acting on behalf of millions of consumers who will
if all goes well ultimately buy the product. Purchasers interact with developers
and consultants, and (to obtain requirements) with beneficiaries and marketing
also.
The purchaser’s input is required from the start, is critical in getting development
started and in ensuring that funding for it is not withdrawn. It always has high priority (possibly more than it deserves, but that is out of the control of those working
on a project).
•
Product champion (a.k.a., sponsor): Role responsible for initiating development of the product, for obtaining funding for it, and for protecting the
development from “political” pressures and funding cuts. The role requires
positional power within the purchasing organisation (e.g., the company creating a mass-market product). The product champion is perhaps the best person
for the requirements’ engineer to meet with first; an effective champion can
indicate the scope and purpose of the development, the opportunities and
threats, and can suggest who the key stakeholders are. All of this helps to cut
the risk to the project.
A product champion’s effectiveness is clearly related to the ability to interact with
other stakeholders, especially beneficiaries and negative stakeholders (including
those within the organisation).
The product champion is critical from before the start of a development and remains
important throughout. The role does not necessarily or even desirably contribute
to product requirements: it functions mainly at a political rather than a technical
level.
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission
of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
36 Alexander
Wider Environment
•
Negative stakeholder: Any role that could be harmed by the product physically, financially or in any other way that might be found justifiable by the
authorities (e.g., a court of law, a regulator), or conversely that could attempt
to harm the product (for example, householders living close to the route of a
planned railway; a nature conservation body with interest in land threatened by
such a route; activists opposed to pollution that might be caused by a product
under development; employees finding their decision-making abilities reduced
by ‘intelligent’ software; employees that perceive their tasks being oversimplified or made too complex; groups feeling that collaboration or communication
were made more difficult).
•
A special kind of negative stakeholder (and possibly a distinct slot) is the
hostile agent: Any role that actively seeks to hinder or harm the development and operation of the system. “Actively” means using some degree of
intelligence and creativity to oppose the system. Examples include military
enemies, political and commercial spies, hackers, spammers, virus writers,
thieves, and fraudsters. Clearly, the degree of harm intended by such agents
varies widely, and new subtypes of the hostile agent are constantly emerging.
We may distinguish a few subtypes as examples:
1.
Military enemy: Intends complete destruction of the product.
2.
Amateur hacker: Intends to gain malicious pleasure from unauthorised
access.
3.
Thief: Intends to steal assets (with essentially unintended harm to those
deprived of the assets as a side-effect).
Negative stakeholders may interact with regulators, with beneficiaries, and with
any roles in the wider environment able to wield influence, for example, the press,
politicians, and other pressure groups.
Hostile roles can be treated as a kind of negative stakeholder or may perhaps be
promoted to a slot in their own right. Hackers and virus writers are obvious hostile
roles. Competitors, too, could be considered: their relationship could be anything
from passive victim to active threat. In the case of military systems, the enemy’s
expected behaviour and capabilities are naturally a primary consideration.
Negative roles are important from before the start of a development, and then
whenever issues like security, marketability, and environmental impact are considered. These affect requirements and design. Security may demand special effort in
system testing.
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
A Taxonomy of Stakeholders
•
37
Political beneficiary: Any role in public office or private business that can
benefit in terms of power, influence, and prestige through the success of the
product. For example, a space agency’s management could benefit “politically”
from a successful space mission.
Interaction with other roles is usually infrequent and is typically indirect, for example
via senior management (purchaser, functional beneficiary, etc.).
Political forces within an organisation can also be negative (see the discussion of
product champion in the previous sub-section, Containing System). It might be worth
representing a “political opponent” although such explicitness can be dangerous,
as Checkland mentions (Checkland & Scholes, 1990): “There is an unavoidable
political dimension .. to any human affairs which entail taking deliberate action”
(p. 50); “delicate judgements are usually required” (p. 51); “if the results (of political analysis) are all bluntly made public, then those results can themselves easily
become a potent commodity of power in the ‘real’ politics of the situation. There
is potentially an infinite regress here in which the politics of the situation forever
escapes open analysis” (p. 51).
Political roles are important (see “sponsor” in the previous sub-section, Containing
System) throughout a development and indeed from before it begins.
•
Financial beneficiary: Any role that can benefit financially from the success
of a product (for example, shareholders and directors in a company making a
mass-market product).
They often interact weakly with other roles, except perhaps with the product champion and other senior beneficiaries.
Development staff perhaps needs to consider financial beneficiaries directly only
rarely; project and programme management may be more concerned. Perhaps the
most usual situation is that financial beneficiaries are represented by surrogate roles
such as line management. Conversely, financial beneficiaries are likely to take a
direct interest only in the largest of developments. They are important at the main
“gates” in a development.
•
Regulator: Any role responsible for regulating the quality, safety, cost, or other
aspects of the product (for example, aviation authorities, health and safety
executives, rail regulators, radio regulators, financial service authorities).
The regulator is most likely to interact with senior developers. Regulators act as
surrogates for the public, interacting with the developer and beneficiary roles as
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission
of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
38 Alexander
necessary; for example, the aviation authorities certify components on receipt of a
satisfactory safety case supported by evidence from the development organisation’s
safety officer.
In the case of a software product, we could view standards organisations like ISO
as non-statutory (voluntary, not enforcing) regulators.
Regulators impose requirements which act as qualities and constraints (rarely as
functions). These are important in defining the requirements for a product and again
for acceptance and certification. In the case of safety-related products, they are of
crucial importance.
•
Developer: Any of the many roles (requirements engineer, analyst, designer,
programmer, tester, safety engineer, security engineer, electronics engineer,
metallurgist, human factors engineer, project manager, etc.) involved directly
in product development. Note that none of these roles are operational unless
tied into operations via a maintenance contract—in which case the affected
people have hybrid developer/maintenance roles.
Developers interact mainly with each other (often adopting surrogate “customer”
roles in the process—see the following discussion), but also contractually with
purchasers. Ideally, developers in the form of requirements’ engineers and analysts
would interact with all other roles, but this is rare and often impossible for reasons
of, for example, time and restrictions on access.
Developer roles are mainly involved once development has started; it may be helpful to involve a development opinion (a consultancy role) before that and to keep
developers involved (via maintenance) during operations. Clearly, the priority of
a developer’s requirements is secondary to those of the beneficiaries, although
manufacturability is an important consideration for mechanical products such as
jet engines.
Suzanne Robertson (2004) suggests that it may be helpful to create an extra circle for
“development project responsibility.” It may be best for this not to be a concentric
circle—in a way, development is another world from operational usage. Developers are in the outermost circle from the point of view of the product but intimately
involved from the point of view of development. Hence, it may be an over-simplification to try to force the two taxonomies into one. However, as she says, drawing
a development circle “highlights the necessity to have adequate representation of
the ongoing maintenance operator and operational support roles and [to] separates
real maintenance from new development.”
•
Consultant: Any of the many roles (marketing expert, software expert, business
analyst, management specialist, etc.) involved in supporting some aspect of
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
A Taxonomy of Stakeholders
39
product development, characteristically from outside the development organisation. Internal consultancy is possible but problematic, as it is hard to speak
out in the face of “political” pressure within the organisation (except with the
help of a “sponsor” [see the previous sub-section, Containing System]).
Consultants may interact mainly with the product champion, with purchasers, or with
developers, depending on when they were hired, by whom, and for what purpose.
For priority and timing, see the comments on developer.
•
Another possible slot is supplier: A role involved in the manufacture and
provision of components, whether custom or commoditized, for the product.
In the case of custom components, this is close to a developer role initially.
During system operations, both custom and commodity component suppliers
have a role closer to maintenance, supplying whatever is needed to keep the
system operational.
Suppliers are important in product manufacture, in maintenance, and sometimes in
development. In extreme examples, such as the manufacture of a jet engine’s intercasing (a complex 3-dimensional casting), the supplier is critical to development as
the lead time for the manufacture of the component is comparable to the lead time
for the entire engine development. Hence, suppliers may need to be involved very
early in a project, possibly even before it begins.
Applying the Taxonomy in Practice
Requirements Elicitation
The simplest and most essential use of a taxonomy of stakeholders is as a guide to
the likely kinds of people to interview, observe, and invite to workshops to help
gather the requirements for a project. As stakeholders are successively identified
and brought into the project, an onion model and associated database can be used
to document their roles, contact details, viewpoints, and ultimately requirements.
The onion model then gives a direct visual report on the progress of stakeholder
discovery and provides pointers to slots that require further investigation.
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission
of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
40 Alexander
Characterising the Project
The nature of the stakeholder taxonomy for an individual project determines the kind
of stakeholder involvement that will be necessary during the life of the project. One
application of the taxonomy is, therefore, to characterise the project in terms of the
requirements’ elicitation approach and the degree of stakeholder participation that
should be selected. This is one of several characterisation dimensions, each of which
can help to reduce risk. Other dimensions include whether and how far safety is
involved, how complex the interfaces are, and how new the needed technology is.
Elicitation techniques vary widely, from interviewing and workshops through
ethnographic fieldwork to market surveys, prototyping, and product trials. Most
requirements’ textbooks describe a range of such techniques (e.g., Alexander &
Stevens, 2002; Kotonya & Sommerville, 1998; Robertson & Robertson, 2006).
Textbooks with a user-centred orientation offer a still wider range (e.g., McGraw &
Harbison, 1997; Sutcliffe, 2002). The choice of techniques is in practice, however,
strongly driven by the stakeholder roles involved. Figure 3 illustrates some common
elicitation approaches for operational stakeholders.
Figure 4 similarly illustrates some common elicitation approaches for non-operational stakeholders.
Characterisation can be carried out by assessing which kinds of stakeholders are
likely to be most significant in a project and then assigning the most appropriate
development life cycle to respond adequately to those stakeholders. For example, if
the operational needs are simple but meeting regulatory demands is long and complex
Figure 3. Eliciting from operational roles (outer circles suppressed)
(Interfaces)
(Benefits)
Neighbouring
Systems
(Operations)
Product
• Interviews
• Scenario Workshops
• Working as an Operator
• Observation & Fieldwork
(Maintenance)
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
A Taxonomy of Stakeholders
41
Figure 4. Eliciting from non-operational roles
(Political Impact)
• Lobbying
• Legislation Government
(Effectiveness
Ease of Use,
Cost)
Neighbouring
System
Mass Market
Operator
• Market Surveys
• Prototypes
• Trials
• Analogous Products
• Competitors
• Observation & Fieldwork
Product
Maintenance
• Safety Cases
• Standards
• Negotiations
(Safety, Quality)
Regulator
(Negative Impact)
The Public
• Public Meetings
• Focus Workshops
• Questionnaires
(e.g., for a jet engine) then the life cycle must focus on achieving certification with
careful attention to verification and the gathering of evidence for the regulator.
Conversely, if regulation is minimal but operational needs are rigorous (e.g., for a
portable consumer product), the life cycle must focus on satisfying users (i.e., hybrid
normal operators/functional beneficiaries) so that the product is suitable, through
involvement with the development—which will presumably be iterative to permit
it to respond to user reactions.
Checking for Stakeholder Problems
Checking for Empty Slots
A tool that records details of slots, roles, and stakeholders can readily detect empty
slots. These might indicate forgotten stakeholders or, for example, a missing sponsor, threatening project success.
Checking for Multiple-Filled Slots
Similarly, a tool could readily detect slots populated by more than one role. This is
sometimes acceptable, but could indicate sources of conflict. For example, conflict
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission
of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
42 Alexander
is likely if two departments (e.g., international marketing, product development
within a multinational carmaker) both believe they are funding and therefore have
control of a development project.
Checking Traces to Use Case Actors
A tool that in addition records traces between items such as requirements could
detect any “our system” roles not traced to use case actors and thus documented in
operational scenarios, and vice versa. Lack of traceability could indicate a disconnect between stakeholder analysis and implementation work.
Analysing and Visualising Contractual Fault-Lines
An onion diagram shows a product and layers of its environment as concentric
circles. Contractual boundaries (see the discussion of Maintenance in the previous
sub-section, Our System) may not coincide with these circles. A diagram with overlaid boundaries may help stakeholders to visualise the risks inherent in outsourcing
or otherwise sharing responsibilities.
For example, Railtrack was the company formed to operate Britain’s railway infrastructure of tracks and signalling, while independent franchises operated the trains
themselves (along with ticket booking and inquiries). For the system of the railways
as a whole, operations were split between Railtrack (the track) and the franchisee
(the train). This gave rise to the ironic term “wheel-rail interface,” referring not to the
problems of friction and wear between iron wheel and iron rail but commercial friction between the occupants of the uncomfortably-split stakeholder slots. The pressure
on Railtrack was immense: from shareholders to make money; from the regulator
for safety; from franchisees for reliable, low-cost service. Railtrack management
responded by letting out contracts for the actual work of maintenance, for example,
of keeping the railway in a safe condition. Some notorious accidents followed after
a few years. These caused large parts of the rail network to be inspected for cracked
rails and then restricted to carrying trains at low speed. These restrictions, in turn,
caused severe delays to passengers and large cost penalties to the company. Railtrack
folded in a welter of government intervention, blame, and acrimony.
Tool & Template Support
The taxonomy presented here has several practical applications. These do not
necessarily require tool support: onion diagrams and hierarchies can be created
quite easily in ordinary office software, on paper, or on flipcharts—provided that
traceability is not required.
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
A Taxonomy of Stakeholders
43
When models must be maintained for extended periods during which a steady
trickle of change must be accommodated, tool support with configuration control,
and traceability to requirements becomes helpful.
Requirements Database Tool
A tool (Figure 5) supporting some of the earlier-mentioned applications has been
implemented in a requirements’ traceability tool environment (Telelogic® DOORS)
and is available for free download (Scenario Plus!, 2004). This both demonstrates
the feasibility of building such a tool, and allows workers to experiment with uses of
the approach in a controlled environment (e.g., with a complete audit trail). Figure
2 incidentally illustrates part of the tool’s (very straightforward) data model.
The tool permits the creation and editing of an onion model diagram. As illustrated,
the tool also acts as a display of the status of the model, making it apparent which
slots are filled and which are empty. The tool manages a conventional documentlike data structure (a formal module; see Figure 2) in which each slot, role, and
stakeholder is represented as a separate object within a hierarchy. Details of each
Figure 5. “Onion model” tool displaying current status of stakeholder slots
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission
of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
44 Alexander
stakeholder are held as a database record within the object; these include name and
contact details as well as a text summarizing the stakeholder’s viewpoint. Objects
can be given (bidirectionally navigable) traceability links to any other objects (e.g.,
requirements) in the database. Hence, the tool enables the requirements’ engineer
to provide traces from any number of requirements, use cases, actors, and so forth,
directly to stakeholders.
Tools can readily calculate metrics on the status of the onion model. For example, the
number of our system slots that are not linked to use case actors gives a measure of
the completeness of coverage of known human operators in the use case model.
Clearly, the same information architecture could also serve as the basis for other
forms of stakeholder analysis including conflict detection and resolution. These do
not necessarily demand tool support, but they do require systematic handling for
which a tool can be beneficial. Small projects may instead choose to apply a simple
template of likely stakeholder roles, discussed in the next section.
The Scenario Plus! tools could in principle be implemented in any automated
software/system development environment that supports traceability between items
and provides a suitable application programming interface. The hybrid hierarchical/
tabular data structure of DOORS’ formal modules was very convenient for implementation, but stakeholder information could certainly be represented without it.
Stakeholder Template
A document template (Figure 6), based on the onion model and in a choice of formats suitable for popular word-processing and spreadsheet tools, is available for
free download (Scenario Plus!, 2006). While there are clear advantages for large
projects to work within a traceability tool environment, smaller projects can benefit
from stakeholder analysis and other forms of modelling using simpler tools.
Customisable templates such as Scenario Plus! and Volere (2004) allow stakeholder
analysis to take place in essentially any development environment including indeed
those without any specialist modelling tools whatsoever. The analysis could take
place in Word or Excel with an onion diagram in PowerPoint or CorelDraw. Clearly,
there are advantages for larger projects to work with traceability and configuration
management tools so as to keep track of changes more reliably.
Research Review
The focus of this chapter is on the place of stakeholder analysis in system development and perhaps especially in requirements’ elicitation. However, the subject of
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
A Taxonomy of Stakeholders
45
Figure 6. Fragment of the stakeholder template
stakeholders is far wider than that. This section, therefore, attempts to set the current
work in its system engineering context and also briefly in the wider onion-circles of
information systems research and business studies. These literatures are voluminous,
so references are confined to key papers on each topic.
This research review section is organised by topic as follows:
•
Stakeholder Analysis
•
Onion Models
•
Taxonomies and Hierarchies
•
Goals and Viewpoints
•
Human Aspects of System Development
•
Surrogacy
The logic of this should become apparent, but in essence the information systems
and other literatures on stakeholders are briefly introduced; the background to the
paper’s use of onion models and a taxonomy of stakeholders is sketched; existing
work related to stakeholder classification in the requirements’ engineering and
usability fields is examined; and finally, since stakeholder surrogacy seems to be
significant in system development, research on surrogacy is explored.
Stakeholder Analysis
Mason and Mitroff (1981) helped to introduce stakeholder analysis to business practice. Their definition is: “Stakeholders are all those claimants inside and outside the
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission
of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
46 Alexander
firm who have a vested interest in the problem and its solution” (p. 43) and “[they]
are the concrete entities that affect and in turn are affected by a policy” (p. 95).
They suggested ways of identifying stakeholders including: considering standard
demographic groups (age, sex, etc.) for relevance; asking people who they consider
to be the key stakeholders; and studying accounts of ethnographic fieldwork to
discover who seems to have a valid interest.
An authoritative account of business stakeholders can be found in Donaldson and
Preston (1995). The paper describes a corporation “as a constellation of co-operative and competitive interests possessing intrinsic value” (p. 66). It states that the
stakeholder theory is descriptive of the corporation, instrumental in helping people
to examine stakeholder management practices, normative in establishing that stakeholders deserve attention, and managerial in recommending attitudes, structures,
and practices. However, it considers the corporation as the system of interest and
does not look at software or product development.
Pouloudi (1999) examines the concept of stakeholder and its use in information
systems development. The paper is an excellent introduction to the extensive information systems literature on stakeholders, and it analyses some of the weaknesses
of the concept (including being “almost a cliché,” quoting from D. Willets). For
our purposes here, one key point is that it does not make sense to treat human and
non-human actors symmetrically: they are simply different. Pouloudi notes the
discomfort of Vidgen and McMaster “about assigning anthropomorphic properties
to non-human resources” and states that
I do not subscribe to the symmetrical treatment of humans and non-humans
or the treatment of non-humans as stakeholders, although it is interesting
and indeed necessary to consider the way in which non-humans—including
.. information systems—“inscribe, represent, and speak for” the interests
of stakeholders. (p. 13)
In the taxonomy presented here, all stakeholders are human; interfacing systems are
represented by humans responsible for them, that is, in accordance with Pouloudi’s
approach. Pouloudi has studied stakeholder identification but in a medical context
(Pouloudi & Whitley, 1997). This is very different from system development, but
the paper is of interest for its clear thinking and practical approach.
Sharp et al. (1999) suggests a simple recursive procedure, starting from an initial
contact person and asking each interviewed person who might be worth speaking
to. The procedure terminates when no new names arise or when the new names
are found not to be relevant. The paper describes a simple method for identifying
stakeholders starting from the initial point of contact (which might typically be the
project sponsor). This is one of the few papers to address the issue directly, and
its suggestion is sensible. However, it is not a substitute for a template (based on a
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
A Taxonomy of Stakeholders
47
taxonomy); the method could be time-consuming, and it is likely to reveal only the
stakeholders that everybody knows already. To be fair, the method of asking each
interviewee who else might be relevant is almost an obvious good practice during
requirements’ elicitation. The paper also points out that stakeholder classes (slots)
should be characterised by their relationships to the system, to other stakeholders,
and by the priority to be given to each stakeholder’s view. These dimensions are
used here (along with the stages where each slot might be relevant), although they
are rough guides at best.
Robertson and Robertson (2006, pp. 356-358) distinguish clients, customer, and
other stakeholders, including subject matter experts, marketing people, product
managers, and so on, and attempts to prioritise them:
the principal stakeholders are the users, clients, and customers (p. 35).
However, the general effect is of a flat unstructured list of many interested parties.
The Volere template (by the same authors) similarly proposes a flat list of roles,
as one axis of a matrix to organise which kind of stakeholder to consult for which
“class of knowledge” (Volere, 2004). The taxonomy proposed in this chapter offers a richer and more explanatory structure and suggests the significance of key
roles and their interactions. The Volere template has been updated in the light of
the criticism presented here (Alexander, 2005), but its 2004 version remains of
interest in showing the difficulties even experienced consultants face in identifying stakeholders. That version is analysed next in the sub-section, Developer- or
Requirement-Centric Taxonomy.
Alexander and Stevens (2002) includes a chapter on identifying stakeholders (pp.
19-26). It also distinguishes “users” from clients, suppliers, managers “who are
concerned for the system to succeed” (and by implication other people with that
concern), and regulators, and it briefly discusses the role of people in the development organization (p. 7). The variety of roles is illustrated with a cartoon of stakeholders in a space telescope project (p. 20), which shows an astronaut carrying out
maintenance, a ground station engineer operating the spacecraft, an astronomer
discussing the data produced by the telescope, and a politician gaining political
benefit from the system (Figure 7). The discussion of these roles makes clear that
these represent different viewpoints not necessarily conflicting. This was a sensible
and pragmatic position, but the proposed taxonomy looks far more deeply at the
structure and possible conflicts between stakeholders.
There is much pragmatic wisdom on dealing with stakeholders in Peter Checkland’s
many writings (for example, Checkland & Scholes, 1990). He does not on the whole
focus on the development of products or services, and indeed he seems to believe
that that is the easy part of the problem! For example:
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission
of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
48 Alexander
Figure 7. Space telescope stakeholders (from Alexander & Stevens, 2002)
It now seems that, in the future, the computer project managed through a
‘project life cycle’ will increasingly become the occasional special case
in which some uncontentious and relatively mechanical administrative
procedures are computerized. Where perceptions and meanings, and hence
tasks, are more problematical, the ‘project’ approach needs to be complemented by a process for the continuous rethinking of organizational tasks
and processes… . (Checkland & Scholes, 1990, p. 312)
While we may readily agree with Checkland’s emphasis on process rather than project,
and take his advice on (human) “perceptions and meanings” and “rethinking” as a
hint to keep up to date with our stakeholder analysis, we do not think that software
only implements uncontentious mechanical procedures. Indeed, major products such
as enterprise resource planning tools can have a powerful and sometimes deleterious
impact on organisations (note that we consider the customisation of such COTS
tools for an organisation to be a kind of development project).
Another worker—both researcher and practitioner—who helped to pioneer sociotechnical design is Enid Mumford. In her long career and her many writings (e.g.,
Mumford, 1996), she emphasised a humanistic and ethical approach to the people
whose work was affected by process redesign and automation. She talks more often
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
A Taxonomy of Stakeholders
49
about specific people, individuals, clerks, groups, staff, and so on, rather than using
generalities like “stakeholders.” However, much of her work was precisely about
paying more attention to the different groups of people involved in or affected by
a project. For example:
At these meetings a large number of organizational problems emerged and
she [Mumford] suggested to the clerks that they should think about how
these might be solved.
She then forgot about this request and fed-back the results of the survey
to the members of the technical design group. They subsequently designed
what they thought was an excellent socio-technical system, called a meeting
of all the clerks, described their proposed system and sat back and waited
for the applause. To their astonishment there was silence. Then one of the
senior clerks stood up… He then produced an excellent blue-print for a
work structure that solved most of the office’s efficiency and job satisfaction problems.
… The author learnt a very important lesson from this experience… This is
never to underestimate a group’s abilities. (Mumford, 1996, p. 87)
Onion Models
Peer: (Pulls off several layers at once.)
What an enormous number of swathings!
Isn’t the kernel soon coming to light?
(Pulls the whole onion to pieces.)
I’m blest if it is! To the innermost centre,
it’s nothing but swathings-each smaller and smaller.
- Nature is witty!
(Throws the fragments away.)
Peer Gynt, Act 5, Scene 5, by Henrik Ibsen (1867)
Onion models have been used for centuries to indicate hierarchical spheres of influence. Alexandre Koyré’s wonderful From the Closed World to the Infinite Universe
(Koyré, 1957) uses the beautiful 11-layered onion diagram of Peter Apian’s 1539
Cosmographia, a pre-Copernican model of the universe, on its cover (Figure 8).
Apian has the imperfect and changeable Earth at the centre, and Coelum Empireum
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission
of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
50 Alexander
Figure 8. Apian’s onion diagram of the universe (from Koyré, 1957)
Habitaculum Dei et Omnium Electorum (i.e., The Empyrean heavens, the dwelling
place of God and all the Elect) as the outermost, perfectly unchangeable layer.
This implied a fixed frame of reference for each class of beings in the Great Chain
(Lovejoy, 1936), very far from the dynamic situation-dependent stakeholder Webs
of Coakes and Elliman (1999), who describe the role of stakeholders in managing
change. Their term “stakeholder Webs” has entered popular currency, perhaps by
association with fashionable terms like World Wide Web and semantic Web, and
may have done much to get people thinking about stakeholders in software development.
Their Webs are drawn as cobwebs with radial lines and concentric ellipses. This
makes them look something like onion models, but:
The importance of the Web is not in the exact labelling of sectors and
boundaries but in seeing the web as a continuum. The sectors and labels
shown in [a Figure] are not a prescriptive or a priori model for all webs
but … the groupings that emerged from the case study. (p. 9)
Thus, the Coakes and Elliman stakeholder Web is expected to be different for each
examined system: there is no recognisable taxonomic pattern common to different
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
A Taxonomy of Stakeholders
51
Figure 9. A stakeholder Web (from Coakes & Elliman, 1999)
developments. Somewhat in contradiction to this, Figure 1 of their paper illustrates
the choice of the system boundary based on Midgley (1992), which shows concentric
circles labelled the technical system boundary, the organisational boundary outside
that, and finally the human or total system boundary on the outside (Figure 10).
Within the technical system boundary are three items linked by bidirectional arrows:
computer information system, whose boundary is labelled automation boundary;
direct system users; and system designers. Within the organisational boundary is a
text label “executive and wider management, other divisions and business activities.”
Within the human or total system boundary is a text label “shareholders, clients,
government, and other stakeholders, beyond the organisational boundary” (p. 6).
This is clearly a rudimentary onion model. We can make the following assignments:
•
Computer Information System = (an example of) our “the kit” or product;
•
Direct System Users = our normal operators (but see criticism of the term
“users” later in this chapter);
•
System Designers = our developers, who seem oddly placed within the
technical system, given that they may have no part in the system’s daily operations. It looks as if the operational boundary is here confounded with the
boundary of all matters engineering and technical. The figure is criticised by
both Midgley and Coakes and Elliman, who argue that the “critical setting of
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission
of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
52 Alexander
Figure 10. Midgley’s onion (from Coakes & Elliman, 1999)
the system boundary” needs to be “determined by examining the viewpoints
of stakeholder groups … rather than technical issues” (p. 6). However, the
automation boundary remains important as a contractual and developmental
reality; while the figure is clearly defective as regards the technical system
boundary, it can be corrected by removing the system designers from it, and
inserting any other types of operator that may be needed, as is argued later in
this chapter.
•
Similarly, executives and management may loosely correspond to our functional,
financial, or political beneficiaries, but there is no reason why the organisational
boundary should fit neatly within the total system boundary if this is taken to
mean our wider environment with respect to a specific kit or product: some
parts of the organisation’s management may be involved, others not. Simply
because some dead-wood paper-pushers are within the organisation does not
make them valid stakeholders: that way madness lies.
•
Again, Midgley’s shareholders, clients, government can reasonably be equated
with our financial beneficiaries, purchaser (perhaps—client is a slippery term),
and political beneficiary (or perhaps regulator, depending on the situation).
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
A Taxonomy of Stakeholders
53
Coakes and Elliman (1999) are probably right, therefore, to reject the Midgley
(1992) onion model, but a more carefully-considered model may overcome their
objections. Designers and developers do not belong inside the “technical system”
boundary—in any case, since it contains people, it must be sociotechnical. The
organisational boundary is the wrong one to choose (unless, of course, it is the
organisation rather than a product or development which is your focus); and the
“human or total system” boundary does seem rather vague. On the other hand, there
is usually a containing system (in our terms, see sub-section, Structure of the Onion
Model) that makes use of the results or outputs of the (sociotechnical) system that
we are developing—otherwise, why would anyone pay to develop it—and there
are indeed stakeholders such as shareholders and government who may have an
interest in aspects of the system, while not themselves playing any part in its development or operation. The problem with a stakeholder Web formed afresh for each
new system is that it offers little guidance, whereas the engineers working on yet
another telemetry system (say) are immediately aware that what they are doing is
very similar to what they did on previous projects. Coakes and Elliman throw out
the baby with the bathwater.
A modern onion model related to stakeholders can be found in Donaldson and
Preston (1995, p. 74).
However their model’s circles, starting from the centre, are the normative, instrumental, and descriptive aspects of stakeholder theory (Figure 11). These:
are nested within each other … The external shell of the theory is its descriptive aspect; the theory presents and explains relationships that are observed
in the external world. The theory’s descriptive accuracy is supported, at the
second level, by its instrumental and predictive value; if certain practices
are carried out, then certain results will be obtained. The central core of
the theory is, however, normative. (p. 74)
The Donaldson and Preston onion model is thus used to help visualise the structure
of the theory, not the relationships of the stakeholders and a product under development.
Hirschheim and Klein (2003) reflect on the state of information systems research
in a long and discursive paper. In a nutshell, they wonder whether information systems can effectively mediate social dialogue, and if so how the field would have
to be structured. Understanding organisational stakeholders better would form an
important part of that programme. The authors refer to “immediate,” “external,”
and “societal” stakeholders, implying something like an onion structure, although
not exactly the one described here. “Immediate” roles, for instance, include “a
managerial elite and their masters, the shareholders” (p. 271)—although it is not
clear if in fact the shareholders are immediate or one jump removed by being the
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission
of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
54 Alexander
Figure 11. A wholly different onion model (from Donaldson & Preston, 1995)
masters of the managerial elite. If the latter, then there might be a reasonable match
with the onion model given here: managers = functional beneficiaries, shareholders
= financial beneficiaries. However, the focus of the paper is not on products but on
information systems professionals themselves.
Taxonomies and Hierarchies
The general subjects of taxonomy and hierarchy are far too broad to be addressed
here in any detail. Susan Leigh Star has written engagingly about classification (e.g.,
Bowker & Leigh Star, 1999). She states that classification systems should exhibit
consistent principles, mutually-exclusive categories, and completeness. It is hard
to make any such classification of stakeholders; while the roles listed here seem
to be usable consistently and are mutually-exclusive, one person can play several
roles, and it is impossible to be sure that new roles will not arise, so completeness
is unattainable. Any “taxonomy of stakeholders” must be tentative at best.
Under the heading of “hierarchical structure,” Jackson (1995, pp. 92-95) wittily
makes the point that one taxonomy can only do one job; very often several different hierarchies are needed. Indeed, one of the key principles of Jackson’s JSD/JSP
methods is to make sure that your representations adequately span the problem. You
may need one data structure that understands files: file start—data—file end; and
another that understands transactions recorded within those files: start event—more
events—end event. Either on its own is insufficient: a transaction might, for instance,
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
A Taxonomy of Stakeholders
55
span two files. Analysing stakeholders by their relatedness to a product is only part
of the story.
Goals and Viewpoints
Two areas of requirements’ engineering related to stakeholder analysis are goal
modelling and viewpoint analysis.
A goal is an intention that a stakeholder has for a development project (or more
widely for a business or indeed for a lifetime), for example, that it will make preparing accounts easier. Goals may interact positively or negatively—achieving one
goal may make it easier or harder to achieve another. Such interactions can easily
be modelled graphically, making conflicts easy to visualise. Hence, modelling goals
and their interactions is one way to explore the relationships between stakeholders
with different needs. What goal modelling is not designed to do is to identify or classify the stakeholders themselves, though it can explore their social and operational
interactions (and even their beliefs). Goal modelling is, therefore, like most other
approaches, likely to discover operational (“our system”) roles rather than those
in the wider circles of the onion model. There is an extensive literature on goals; a
good starting point is Yu and Mylopoulos (1998).
Negative interactions can also be intentional and dynamic, in which case they may
more directly be modelled as negative scenarios or misuse cases (Alexander, 2002).
This approach has the merit of considering threats, risks, and hazards, whether caused
intentionally or not, and how to mitigate them. It will, therefore, put the spotlight
on negative stakeholders as well as normal operators. However, this approach too
tends to direct attention mainly to operational issues.
A viewpoint is either the perspective that a given stakeholder has on a development
project or its product, for example, that they will continue to have an interesting job
and a decent salary, or the projection (for example, of requirements) on to the system
from the position of a given stakeholder role, for example, an employee’s. Analysing
viewpoints helps to discover whole groups of requirements, can indicate possible
conflicts, and hence can help to create better and more stable specifications.
A readable introduction to viewpoints is Kotonya and Sommerville (1998). It describes
a method of “viewpoint-oriented requirements’ development” (VORD), explicitly
a stakeholder-centred approach. As well as describing a method for discovering
viewpoints and resolving stakeholder conflicts, it presents a simple taxonomy of
“abstract viewpoint classes” (p. 219), classifying viewpoints into direct and indirect.
These do not correspond exactly to our operational and non-operational. Instead,
direct includes “system” (our “interfacing systems”—see sub-section, Structure of
the Onion Model) and “operator” (our “normal operator”). Indirect is divided into
engineering (maintenance and standards: we consider maintenance to be operational,
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission
of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
56 Alexander
while standards means the regulator), regulatory, organisation (procurer, policy, and
training), and environment. A further paper by the same team (Sommerville, Sawyer,
& Viller, 1998) describes the PreView approach in which viewpoints are treated as
projections on to a system. One stakeholder viewpoint then naturally corresponds
to a substantial set of requirements.
Multiview (Avison & Wood-Harper, 1990) is a well-respected approach to system
design based on the idea of multiple stakeholders’ views on the system and on
choosing appropriate tools and techniques according to the problem situation thus
defined—as such it owes something to soft systems methodology (Checkland &
Scholes, 1990). Both “soft” and “hard” aspects are considered: human exploration
and sociotechnical analysis on the soft side; information analysis and specification
on the hard side. This is obviously sensible and practical. However, it does not
attempt to classify stakeholder roles. Multiview 2 went further in several ways,
including a “systemic stakeholder analysis” within its organisational analysis and
using ethnography in the sociotechnical analysis (Bennetts & Wood-Harper, 2000).
However, it did not attempt a taxonomy of stakeholders.
Human Aspects of System Development
There is an extensive literature on human aspects of system development. It seems,
however, to focus quite naturally on the “user” (by which is generally meant our
“normal operator”) at the expense of all other roles. This is no place for a full
literature survey but a good starting point is Sutcliffe (2002), which approaches
requirements’ engineering from a background in human-computer interaction and
has an extensive bibliography.
Sutcliffe distinguishes customers, users, managers, software engineers, system
testers, and system maintainers—“Maintenance personnel are rarely consulted in
requirements analysis yet they depend on accurate requirements documentation
more than most” (p. 17)—and it could be added that they have more to contribute
than most, too. These roles are notably concentrated around “our system,” but to be
fair, they are said to be those that can write requirements. Stakeholders are further
classified (p. 56-7) as:
•
Primary: “Who will actually operate the system” (our “normal operators” [and
possibly also our “maintenance operators”]: equivalent to UML “actors”).
•
Secondary: “Users who will not actually operate the system but will consume
its output and depend on its operation for successful completion of their work.”
The astronomer of Alexander and Stevens (2002; see Figure 7) would be an
example (our “functional beneficiary”). Note the typical awkwardness and
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
A Taxonomy of Stakeholders
57
circumlocution necessitated by overloading the term “users” to mean both
operator and beneficiary.
•
Tertiary: “Senior managers who rarely consume the system output directly
but make use of information for planning and strategic control of the business.” This seems to denote either our “functional beneficiary” or our “political
beneficiary.”
Sutcliffe’s classification is interesting but limited to thinking about people who
receive information outputs. However, the book also describes more general stakeholder analysis methods somewhat surprisingly quoting the ruggedly practical and
pioneering (Gause & Weinberg, 1989) rather than the more academic (Kotonya &
Sommerville, 1998), which one might have expected.
Surrogacy
Surrogacy has apparently scarcely been researched as a requirements’ engineering
issue. It is mentioned briefly in some of our own earlier work on stakeholders (Alexander, 2003) and in a practical way on the Scenario Plus! stakeholders template
(Scenario Plus!, 2006).
Damian and Zowghi (2002) state that a business management department acted as
a surrogate stakeholder:
Hence BM became a surrogate customer for the developers in Australia
and the need for effective collaboration with DM group emerged as critical
in order to meet commitments made to the customers.
The point is not developed further, but it is clear that in the context of using technology to support RE across sites on different continents (America, Australia, Europe),
the issue of who you can actually speak to, and whether they fairly represent who
they claim to, is highly significant.
A set of guidelines (Kitapci & Bhuta, 2004) for using the EasyWinWin (requirements’ negotiation) tool and approach (Boehm, Grünbacher, & Briggs, 2001) tantalisingly mentions appointing “one of the team members as a surrogate customer if
the customer would not be using the EasyWinWin tool.” However, the significance
of surrogacy is not considered.
Surrogacy is also occasionally mentioned in non-requirements’ work on stakeholders
(i.e., to do with steady-state business, not with system development). For instance,
Wood (1999) writes:
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission
of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
58 Alexander
The Chief Executive Officer acts as the surrogate employer of teachers, but
it is unclear who is responsible for the teacher relationship.
Similarly, Younkins (2001) expresses the sentiment:
The corporation should be managed for the benefit of its stakeholders and
the groups must participate in decisions that affect their welfare. Such
participation is indirect with managers having surrogate duty to represent
the stakeholders’ interests. Managers are said to have a fiduciary relationship to stakeholders and must act in the interests of the stakeholders as
their agents.
The focus of such work is however (in both these examples) on the political and
social significance of stakeholder responsibilities not on surrogacy as such.
Donaldson and Preston (1995) begin, interestingly, with a quotation from E. Merrick Dodd, Jr., writing in the Harvard Law Review of 1932. Dodd does not use the
term “stakeholder,” but he is plainly thinking of the same concept: “If the unity of
the corporate body is real, then there is reality and not simply legal fiction in the
proposition that the managers of the unit are fiduciaries for it and not merely for its
individual members, that they are … trustees for an institution [with multiple constituents] rather than attorneys for the stockholders.” Both the concept of stakeholder
and the importance of surrogacy are evident from this early discussion.
Potts (1995) does not explicitly mention surrogacy but does consider the relationship of “customer” and “developer” and some of the misunderstandings that can
arise across the gap between them, for example, the contractual interface and hence
the supplier/purchaser roles that are created (with inevitable surrogacy). His talk’s
provocative title also led requirements people to reflect on the nature of the stakeholder/developer “interface.”
Discussion:
Features and Limitations of the Taxonomy
“User”: A Hybrid Role
One slot that is not provided is “user.” We consider this term to be both dangerously
overloaded and confusing. It has many loose meanings in colloquial engineering
parlance, including:
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
A Taxonomy of Stakeholders
59
1.
“all stakeholders;”
2.
“all stakeholders other than us, the developers” (this meaning verges on the
derogatory, and should be avoided);
3.
“any stakeholder who gets any benefit from the product;”
4.
“any stakeholder who operates the product.”
However, perhaps the most widespread meaning is an interesting hybrid of two
of our slots: normal operator and functional beneficiary (Figure 12). For example,
consumer electronics companies speak of “users.” They seem to mean the people
who both push the buttons on their products and who enjoy the resulting entertainment (music, video, games, etc.). This user/consumer role seems necessary to
combine the roles of operator and functional beneficiary, and, of course, the role of
consumer/mass-market product purchaser—not to be confused with the important
surrogate role of purchaser adopted by product managers and procurement departments—is not far away either. Indeed, if changing the batteries is considered to be
a maintenance operation, then the role is multiple-hybrid.
Popular variant terms such as “end-user” do not clarify the situation. “End-User”
seems sometimes to mean “the actual operator of the product, as opposed to the
purchasing organisation that is paying for its development,” in which case its slot is
normal operator. At other times, the implied slot is functional beneficiary, as when
Figure 12. “User” as a hybrid role across 2 or more slots
The Containing System
Our System
The Kit
or Product
Functional
Beneficiary
Normal
Operator
‘User’ / ‘End-User’ Role
is a hybrid (possibly including a
little first-line maintenance also)
?
Maintenance
Operator
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission
of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
60 Alexander
astronomers are called the end-users of a scientific satellite because they make use
of the data it collects. In any case, we may ask “the end of what?” with respect to
the chain of beneficiaries on the left of the onion model and indeed to the shifting
perspectives of the onion models drawn with respect to different products within a
system/subsystem hierarchy.
Therefore, the terms “user” and “end-user” have little value, may be harmful in
diverting attention away from non-operational stakeholders, and should not be
chosen as fundamental taxonomic units.
Overlapping Taxonomies
Clearly, this model is product-centric, although by intention people-focused. It is
possible to create process-centric models (around the developer and development
activities, the business processes, and system usage), and as argued in the section,
Research Review, most of the requirements’ literature seems to be tightly productcentric to the exclusion of most kinds of stakeholder.
It is unwise to try to make a single taxonomy or hierarchy do too much (Jackson,
1995, pp. 92-95); the aim here is to provide a practical way of discovering and
remembering the viewpoints necessary to a development’s success. Other models may be needed to cover business processes that stakeholders are involved in.
Other hierarchies may be needed to suit other purposes such as defining company
responsibilities. More is said on the dangers of reading too much into the model in
a following sub-section, Visual Metaphors.
Usage-Centric Taxonomy
We have chosen to emphasize the range of roles across onion model circles, as a
counterbalance to the prevailing emphasis on (software) product usage to the exclusion
of almost all other roles. For example, the Unified Modeling Language’s “actors”
are chiefly normal operators; the narrowness of the UML framework (Fowler, 2004)
often causes even maintenance operators to be forgotten, while the surrounding context of other stakeholders able to contribute requirements is essentially undescribed
(Figure 13). On the other hand, starting from an onion model, any operational role
(in the “our system” circle) is a candidate UML actor.
Readers from other backgrounds accustomed to paying attention to a myriad of
stakeholder groups may find the need to counteract excessive actor-fixation parochial;
perhaps, the most that can be done here is to assure them that it does seem to be a
problem. The current unhappy emphasis on security requirements, in response to
threats as diverse as hacking and terrorism, may however be helpful to make even
the most software-fixated developers aware that stakeholders do matter.
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
A Taxonomy of Stakeholders
61
Figure 13. UML only explicitly addresses stakeholders inside “our system”
with its use case “actors”
Withdraw Cash
Bank Customer
Developer- or Requirement-Centric Taxonomy
The Volere template (Volere, 2004) contains an interesting and useful list of stakeholders—certainly far more comprehensive than most others in the literature. These
are not easy to map into our taxonomy from the stakeholder role names alone: for
instance, should “maintenance specialist” be treated as a maintenance operator role
or as a consultant role? It could clearly be either. However, the list seems rather
developer-oriented: most of the roles appear to fall into the developer and consultant
slots (see Table 1).
The numerous “consultant” roles in the Volere list—their names ending in “specialist” or “expert”—make sense if seen from the point of view of a classification
of non-functional requirements: perhaps, the thinking ran “here are some usability
and some security requirements, we better consult some appropriate specialists
about these” (i.e., the knowledge-role-person triangle was the driver for discovering requirement-related knowledge [Robertson, 2004]). Thus, it appears that the
Table 1. Classification of Volere stakeholder roles into the onion model
Onion Model .
tailored for Volere
The Wider Environment
Financial Beneficiary
Negative Stakeholder
All 37 Stakeholder roles .
defined in Volere.co.uk template
Volere
Row No.
––– none –––
Opponents of project/product
Public Opinion
38
41
Packaging Designer
Manufacturer
Project Management
Business Analysts
Requirements Engineers
Technical Designers
Technical Systems Architect
Organisational Architect
Testing Specialists
28
29
32
33
34
35
36
37
42
Business/Subject Experts
Future Ideas Specialists
Current System Specialists
Sales Specialist
11
12
13
17
Developer
Consultant
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission
of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
62 Alexander
Table 1. (continued)
Onion Model .
tailored for Volere
All 37 Stakeholder roles .
defined in Volere.co.uk template
Marketing Specialist
Aesthetics Specialist
Graphics Specialist
Usability Specialist
Safety Specialist
Security Specialist
Cultural Specialist
Legal Specialist
Environmental Specialist
Standards Specialist
Financial Specialists
Negotiation Specialists
Volere
Row No.
18
19
20
21
22
23
24
25
26
40
44
45
Regulator
Political Beneficiary
The Containing System
Interfacing System
Purchaser
Functional Beneficiary
Auditors
43
––– none –––
––– none –––
Customer
10
Client
9
Protectors of Project/Product
39
Product Installer
Maintenance Specialist
30
27
Clerical User
Technical User
Potential User
14
15
16
Training Staff
31
Champion / Sponsor
Our System
Maintenance Operator
Normal Operator
Operational Support
Volere template is perhaps more specifically requirement-centric than developercentric. On the other hand, the negative and champion slots are rightly stated to be
“project/product”-centric.
The resulting onion diagram (Figure 14) shows that (for all the length of the Volere
stakeholders’ list) several slots remain unfilled, perhaps surprisingly including the
one for stakeholders responsible for interfacing systems.
Several other slots are only weakly represented, for example, “auditors” is the sole
(and rather doubtful) role in “regulator.”
Volere’s “customer” and “client” are slippery terms; in this analysis, they are assumed
to correspond roughly to our “purchaser” and “functional beneficiary,” respectively;
client can, however, also include financial beneficiary.
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
A Taxonomy of Stakeholders
63
Figure 14. Onion model of Volere stakeholder roles
The Wider Environment
Financial
Beneficiary
The Containing System
Our System
Sponsor or
Champion
Political
Beneficiary
Functional
Beneficiary
Interfacing
System
Negative
Stakeholder
The Kit
Normal
Operator
Regulator
Operational
Support
Maintenance
Operator
Consultant
Purchaser
Developer
Several slots (greyed-out) remain unfilled. Several other slots (especially consultant, developer) are
heavily populated (see Table 1).
Surrogacy
One aspect of stakeholder sociology that is brought out clearly on an onion diagram
is surrogacy—the representation of one stakeholder’s viewpoint by some other
person. Surrogacy has (when it has been considered at all) always been seen as a
dangerous obstacle to successful requirements work. It is, therefore, remarkable that
stakeholder surrogacy (Figure 15) is both central to requirements’ engineering (RE)
and scarcely discussed in the RE literature (see the section, Research Review).
Figure 15 describes some of the surrogacy issues around requirements’ engineering
as a whole and stakeholder sociology in particular. It is immediately apparent that
the different stakeholder-surrogate relationships each have their own advantages
and risks. These are briefly analysed in Table 2.
Other forms of surrogacy are also involved, given that both in development projects
and in ordinary work (using the developed products) people are usually working
on behalf of other people.
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission
of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
64 Alexander
Figure 15. Four kinds of stakeholder surrogacy
“Typical
Consumer”
(small)
sample
official
voice
(e.g., PDA user,
car driver)
“Salaried
Authority”
(e.g., Safety
Regulator)
The large
(unreachable)
Population
present-for-future
analogue
professional
interpretation
“Operator of
Current Product”
“Project
Intermediary”
(e.g., soldier, pilot,
railway signaller)
(e.g., Requirements Engineer,
Product/Marketing Manager,
User Interface Designer)
Table 2. Stakeholder-surrogacy relationships
Type of
Relationship
Surrogate
Example
with Stakeholder
Advantages
Stakeholder
Population
‘Typical
Car drivers paid to give
statistical sample is a real operator/
Consumer’
opinion of new models of
beneficiary of the
car
product
‘Operator
Soldier helping to define
present-for-future is a real operator of
of Current
military equipment needs 25 analogue in the
analogous products
Product’
years into the future
domain
‘Project
Requirements Engineer
professional
familiar with
Intermediary’ writing other people’s
interpretation
engineering
requirements; Product
development
Manager purchasing
development of product on
behalf of both consumers
and financial beneficiaries
(e.g. shareholders)
‘Salaried
Aviation Authority (Safety official voice
statutory position;
Authority’
Regulator) checking safety
enforcement of
on behalf of public
requirements
enshrined in law
Risks
may not be typical;
danger of missampling
analogy may not hold
in future environment;
obsolescence
misinterpretation
through lack of
domain knowledge;
over-technical
focus (bias towards
technology); invented
requirements (Potts
1995)
remote from
population and
product operations;
bureaucracy
Combinations and intermediate types can also be identified. For example, environmental pressure groups and “not in my back yard” campaigners may create leaders
who, although unofficial and unpaid, may act almost as regulators being invited to
meetings and having their (negative) opinion sought.
Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
EBSCOhost - printed on 8/29/2022 9:55 PM via LIBERTY UNIVERSITY. All use subject to https://www.ebsco.com/terms-of-use
A Taxonomy of Stakeholders
65
The history of computing can be seen as a steady retreat from the assumption that
we know how to program what we want done in machine language. Languages
and tools that are successively more human-oriented (such as assembly language,
Fortran, visual programming, databases) have been invented to fill the gap.
The history of requirements can be seen as a steady retreat from the assumption
that we know how to say what we want done in atomic “shall” requirements. Documents and diagrams that are successively more stakeholder-oriented (such as user
requirements, concepts of operations, use cases, goal models) have been invented
to fill the gap.
The roles people play—what they do, and what they want to do—thus seem to be
becoming increasingly important to our discipline of RE. Our “machine codes”—
individually prioritised and traceable requirements—will not simply disappear.
But like hexadecimal, the writing of requirement text is moving steadily into the
background as more abstract representations of what people want are invented and
adopted in practice.
A “user requirement” has the general form
wants .
If the gold standard for RE is to create requirements like this—claiming that specific
stakeholders (we’ll pass over the class/instance issue for a moment) want that result,
more or less personally for their own work (by which we include leisure uses of
consumer products, etc.), then surrogacy is a rampant anomaly. All that surrogate
stakeholders can give us are statements of the general form
believes that wants .
In law, st...
Purchase answer to see full
attachment