Discussion Thread: Stakeholders Taxonomy: Human Roles in System Development
JayLQue
ATaxonomyofStakeholders.pdf
See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/269561482
A Taxonomy of Stakeholders
Article in International Journal of Technology and Human Interaction · July 2007
DOI: 10.4018/jthi.2005010102
CITATIONS
38 READS
2,200
1 author:
Ian Alexander
Independent; visiting research fellow at City University
60 PUBLICATIONS 1,243 CITATIONS
SEE PROFILE
All content following this page was uploaded by Ian Alexander on 24 April 2016.
The user has requested enhancement of the downloaded file.
A Taxonomy of Stakeholders
Ian F. Alexander
Scenario Plus
2
A Taxonomy of Stakeholders
Human Roles in System Development
Keywords Stakeholder, taxonomy, onion model, role, actor, user, surrogate, surrogacy,
metaphor, stakeholder identification, viewpoint, requirements elicitation, template
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 stakeholder. Within these, generic ‘Slots’
describe typical classes of 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 reanalysed using the framework.
The taxonomy has immediate value in identifying and validating stakeholder roles in
requirements elicitation, helping to ensure that key viewpoints are not missed, and
hence reducing the risk of instability and failure during development.
1. Introduction 1.1 Motivation
The structure of stakeholder roles and their relationships such as surrogacy have been
very little investigated in the requirements world (though 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 university, an
IBM 360 mainframe occupied the only air-conditioned tower on the campus. Students
were permitted to approach only 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 [command-and-
control] mentality.” (Levine et al 2000). It is time to move on from treating “the user
3
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, e.g. a software
developer, assumes one scope for a product, while another stakeholder, e.g. 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 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, etc. Yet
all 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 operationalized ‘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 below (section 2.6).
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 paper 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.
1 For instance, I am assured that this is as true in Air Traffic Control as it is in other domains. David
Bush, personal communication, 2003.
4
It may be that the approach can be applied outside system development, e.g. to model
political and business stakeholder structures, but that is beyond our scope.
1.2 Structure
The remainder of this paper is structured into sections as follows:
2 Research Review
3 The Proposed Taxonomy
4 Applying the Taxonomy in Practice
5 Discussion: Features & Limitations of the Taxonomy
6 Conclusion
2. Research Review The focus of this paper is on the place of stakeholder analysis in system development,
and perhaps especially in requirements elicitation. However, the subject of
stakeholders is far wider than that. This section therefore attempts to set the current
work in its system engineering context, and briefly also 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.
2.1 Stakeholder Analysis
(Mason & Mitroff 1981) helped to introduce stakeholder analysis to business practice.
Their definition is: "Stakeholders are all those claimants inside and outside the firm
who have a vested interest in the problem and its solution" (page 43) and "[they] are
the concrete entities that affect and in turn are affected by a policy" (page 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 &
Preston 1995). The paper describes a corporation ‘as a constellation of co-operative
and competitive interests possessing intrinsic value’ (page 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
5
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. She 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’ (page 13).
In the taxonomy presented here, all stakeholders are human; interfacing systems are
represented by humans responsible for them, i.e. in accordance with Pouloudi’s
approach. Pouloudi has also studied stakeholder identification, e.g. in a medical
context (Pouloudi & Whitley 1997). This is a very different context from that of
system development, but the paper is of interest for its clear thinking and practical
approach.
(Sharp et al 1999) suggested 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 described 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
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 pointed 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, though they are rough guides at best (along with the time that each slot might be
relevant).
(Robertson & Robertson 1999) distinguishes clients, customer, and other stakeholders
including subject matter experts, marketing people, product managers and so on
(pp356-358) and attempts to prioritise them: ‘the principal stakeholders are the users,
clients, and customers’ (p35). 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 paper offers a richer and more explanatory structure, and suggests the
significance of key roles, and their interactions.
(Alexander & Stevens 2002) contains a chapter on identifying stakeholders (pp 19-
26). It also distinguishes ‘users’ from clients, suppliers, managers ‘who are concerned
6
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
(p7). The variety of roles is illustrated with a cartoon of stakeholders in a space
telescope project (p20) 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 1).
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.
Figure 1: Space Telescope Stakeholders (from Alexander & Stevens 2002)
There is much pragmatic wisdom on dealing with stakeholders in Peter Checkland’s
many writings, e.g. (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:
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, p312)
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 don’t 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).
7
Another worker – both researcher and practitioner – who helped to pioneer socio-
technical 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
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, page 87).
2.2 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 2).
Apian has the imperfect and changeable Earth at the centre, and Coelum Empireum
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.
8
Figure 2: Apian's Onion Diagram of the Universe (from Koyré 1957)
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 & 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.
Figure 3: A Stakeholder Web (from Coakes & Elliman 1999)
9
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” (page 9).
Thus the Coakes & Elliman stakeholder web is expected to be different for each
examined system: there is no recognisable taxonomic pattern common to different
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 4).
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”
(page 6).
Figure 4: Midgley's Onion (from Coakes & Elliman 1999)
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’ below);
10
• 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 &
Elliman, who argue that the ‘critical setting of the system boundary’ needs to be
‘determined by examining the viewpoints of stakeholder groups … rather than
technical issues’ (page 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 below.
• 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, 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).
(Coakes & 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 socio-technical. 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 section 3.1) that makes use of the results or outputs of The
(socio-technical) 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 & Elliman
throw out the baby with the bathwater.
A modern onion model related to stakeholders can be found in (Donaldson & Preston
1995, page 74).
However their model’s circles, starting from the centre, are the Normative,
Instrumental, and Descriptive aspects of stakeholder theory (Figure 5). 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’ (page 74).
11
Figure 5: A Wholly Different Onion Model (from Donaldson & Preston 1995)
The Donalson & 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 & 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 organizational 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, though not exactly the one
described here. ‘Immediate’ roles, for instance, include ‘a managerial elite and their
masters, the shareholders’ (page 271) – though it is not clear if in fact the shareholders
are immediate or one jump removed by being the 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.
2.3 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, pages 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
12
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,
span two files. Analysing stakeholders by their relatedness to a product is only part of
the story.
2.4 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), e.g. 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 & 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, e.g. that they will continue to have an interesting job and a
decent salary, or the projection (e.g. of requirements) on to the system from the
position of a given stakeholder role, e.g. 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 & 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’ (p219), 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 section 3.1 ‘Structure of the
Onion Model’ below) and ‘Operator’ (our ‘Normal Operator’). Indirect is divided into
Engineering (Maintenance and Standards: we consider Maintenance to be
Operational, 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 and Wood-Harper, 1990) is a well-respected approach to system
design based on the idea of multiple stakeholders' views on the system, and on
13
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
socio-technical 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 socio-technical analysis (Bennetts & Wood-Harper 2000).
However it did not attempt a taxonomy of stakeholders.
2.5 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’ (p17) – and it could be added, 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 (p56-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 & Stevens 2002) (see above) would be an example (our
‘Functional Beneficiary’). Note the typical awkwardness and 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.
2.6 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 2004).
(Damian & Zowghi 2002) state that a Business Management department acted as a
surrogate stakeholder:
14
‘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 2003) for using the EasyWinWin (requirements
negotiation) tool and approach (Boehm et al 2003) 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
‘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 & 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; e.g. 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’.
3. The Proposed Taxonomy A project’s stakeholder sociology can be modelled graphically on an Onion Diagram
(Figure 6). 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.
15
The Wider Environment
The Containing System
Our System
The Kit
or Product
Consultant
Financial Beneficiary
Negative Stakeholders
Developer
Regulator Political Beneficiary
Interfacing Systems
Purchaser
Functional Beneficiary
Operational Support
Maintenance Operator
Normal Operator
(mainly social)
(also sociotechnical)
(sociotechnical)
(technical)
Sponsor or
champion
Figure 6: Onion Diagram of Product Stakeholders
The Onion Diagram displays a customisable set of named ‘slots’ (silhouette icons), containing stakeholder roles, in 3 or more 'circles' centred on the 'kit' or product. E.g. ‘Pilot’ is a role (not shown) in the ‘Normal Operator’ slot in the 'Our System' circle, where Product is an aircraft.
3.1 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
16
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 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 of the
public to ensure safety, etc. Surrogacy is discussed in more detail below.
A Role is said to be ‘Negative’ if it is associated with Viewpoints opposed to the
successful completion of the Product’s development or its coming into service, or its
successful operation. Viewpoints – statements of the points of view of stakeholders in
a Role with respect to the Product – 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 7), 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
below (section 4.4).
Figure 7: Viewpoints as Attributes of Traceable Slot and Role Objects
In this example, ‘Consultant’ is a Slot in the ‘Wider Environment’ Circle, containing two currently-defined Roles. Other attributes include ‘Viewpoint’ text (here with very brief
examples); ‘Polar Angle’ 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, etc.
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
17
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.
3.1.1 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.
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. E.g. 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 even 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 the other Circles contain Stakeholders. This does
raise an interesting 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. Of
course, 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
18
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 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 Kit’ means less influence on the
requirements for it: this would be a simple application of the spatial metaphor of the
Onion Diagram. (See section 5.4 for a fuller discussion of Visual Metaphor.)
However, there seems no reason to believe this. On the contrary, the approach here
emphasises that stakeholders who never see the kit may be crucially important to a
development project. As (Coakes & Ellison 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.” (page 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.
3.2 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 are defined, based
broadly on the framework of (Sharp et al 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.
3.2.1 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).
19
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 till 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 whole-life
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.
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;
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, i.e.
relatively late in the project; however, supportability may also need to be evaluated
earlier e.g. when designing software to yield intelligible error messages, etc.
3.2.2 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.
20
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, e.g. 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/from the Product. Such systems behave
much like human Operators in terms of demanding specific capabilities from the
Product, but naturally the interfaces are precisely defined as protocols, etc.
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 and 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 (aka ‘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.
3.2.3 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
21
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, fraudsters. Clearly the degree of
harm intended by such agents varies from complete destruction through malicious
pleasure to unauthorised acquisition of assets (with essentially unintended harm as a
side-effect).
Negative stakeholders may interact with Regulators, with Beneficiaries, and with any
roles in the Wider Environment able to wield influence, e.g. the press, politicians,
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.
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. E.g. a
space agency’s management could benefit ‘politically’ from a successful space
mission.
Interaction with other roles is usually infrequent and is typically indirect, e.g. via
senior management (Purchaser, Functional Beneficiary, etc.).
Political forces within an organisation can also be Negative (see the discussion of
Product Champion above). It might be worth representing ‘Political Opponent’
though 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’ (p50); ‘delicate judgements are usually
required’ (p51); ‘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’ (p51).
Political roles are important (see Sponsor, above) 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.
22
Development staff perhaps need 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 Developer and Beneficiary roles as
necessary; e.g. 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 discussion below), 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 e.g. time and
restrictions on access.
Developer roles are mainly involved once development has started; it may be helpful
to involve a developability 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, though
manufacturability is an important consideration for mechanical products such as jet
engines.
Suzanne Robertson suggests (Robertson 2004) 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’.
23
Consultant: any of the many roles (marketing expert, software expert, business
analyst, management specialist, etc) involved in supporting some aspect of 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
above).
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 commoditised, 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.
4. Applying the Taxonomy in Practice 4.1 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.
4.2 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. Kotonya &
Sommerville 1998, Robertson & Robertson 1999, Alexander & Stevens 2002).
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 8 illustrates some common
elicitation approaches for operational stakeholders.
24
Product
(Benefits) (Operations)
(Maintenance)
Neighbouring Systems(Interfaces)
• Interviews
• Scenario Workshops
• Working as an Operator
• Observation & Fieldwork
Figure 8: Eliciting from Operational Roles (outer circles suppressed)
Figure 9 similarly illustrates some common elicitation approaches for non-operational
stakeholders.
Regulator
Mass Market
The Public
Government
Product
Operator
Maintenance
Neighbouring System
• Market Surveys
• Prototypes
• Trials
• Analogous Products
• Competitors
• Observation & Fieldwork • Public Meetings
• Focus Workshops
• Questionnaires
• Safety Cases
• Standards
• Negotiations
• Lobbying
• Legislation
(Political Impact)
(Effectiveness
, Ease of Use, Cost)
(Negative Impact)
(Safety, Quality)
Figure 9: Eliciting from Non-Operational Roles
Characterisation can be carried out by assessing which kinds of stakeholder 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
(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) that the product is suitable, through
involvement with the development – which will presumably be iterative to permit it to
respond to User reactions.
25
4.3 Checking for Stakeholder Problems
4.3.1 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 e.g. a missing Sponsor,
threatening project success.
4.3.2 Checking for Multiply-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 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.
4.3.3 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.
4.3.4 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 above) 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.
4.4 Tool & Template Support
The taxonomy presented here has, as described above, several possible 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.
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 essential.
4.4.1 Requirements Database Tool
A tool (Figure 10) supporting some of the applications mentioned above, 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 7 above
incidentally illustrates part of the tool’s (very straightforward) data model.
26
Figure 10: Onion Model tool displaying current status of Stakeholder Slots
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 document-like
data structure (a Formal Module, see Figure 7) in which each Slot, Role, and
Stakeholder is represented as a separate Object within a hierarchy. Details of each
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 etc., 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.
27
4.4.2 Stakeholder Template
A document template (Figure 11) 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 2004). 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.
Figure 11: Fragment of the Stakeholder Template
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.
5. Discussion: Features & Limitations of the Taxonomy 5.1 ‘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:
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 necessarily 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
28
departments – is not far away either. Indeed, if changing the batteries is considered to
be a Maintenance Operation, then the role is multiply hybrid.
The Containing System
Our System
The Kit
or Product
Functional Beneficiary
Maintenance Operator
Normal Operator
‘User’ / ‘End-User’ Role
is a hybrid (possibly including a
little first-line maintenance also)
?
Figure 12: ‘User’ as a Hybrid Role across 2 or more Slots
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
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.
5.2 Overlapping Taxonomies
Clearly, this model is Product-centric, though 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 Research
Review, most of the requirements literature seems to be tightly product-centric 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, pages 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 5.4
‘Visual Metaphors’ below.
29
5.2.1 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 & Scott 1999) 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.
Bank CustomerBank CustomerBank Customer
Withdraw Cash
Figure 13: UML only explicitly addresses Stakeholders inside ‘Our System’
with its Use Case ‘Actors’
Readers from other backgrounds accustomed to paying attention to a myriad
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 helping to make even
the most software-fixated developers aware that stakeholders do matter.
5.2.2 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).
Onion Model tailored for Volere
All 37 Stakeholder roles defined in Volere.co.uk template
Volere Row No.
The Wider Environment
Financial Beneficiary ––– none –––
Negative Stakeholder
Opponents of project/product 38
Public Opinion 41
Developer
Packaging Designer 28
Manufacturer 29
Project Management 32
Business Analysts 33
Requirements Engineers 34
Technical Designers 35
Technical Systems Architect 36
Organisational Architect 37
Testing Specialists 42
Consultant
Business/Subject Experts 11
Future Ideas Specialists 12
Current System Specialists 13
Sales Specialist 17
Marketing Specialist 18
Aesthetics Specialist 19
Graphics Specialist 20
Usability Specialist 21
Safety Specialist 22
Security Specialist 23
30
Onion Model
tailored for Volere
All 37 Stakeholder roles
defined in Volere.co.uk template
Volere
Row No.
Cultural Specialist 24
Legal Specialist 25
Environmental Specialist 26
Standards Specialist 40
Financial Specialists 44
Negotiation Specialists 45
Regulator
Auditors 43
Political Beneficiary ––– none –––
The Containing System
Interfacing System ––– none –––
Purchaser
Customer 10
Functional Beneficiary
Client 9
Champion / Sponsor
Protectors of Project/Product 39
Our System
Maintenance Operator
Product Installer 30
Maintenance Specialist 27
Normal Operator
Clerical User 14
Technical User 15
Potential User 16
Operational Support
Training Staff 31
Table 1: Classification of Volere Stakeholder Roles into the Onion Model
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 Volere template is
perhaps more specifically requirement-centric than developer-centric. 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, e.g. ‘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.
31
The Wider Environment
The Containing System
Our System
The Kit
Financial Beneficiary
Negative Stakeholder
Developer
Consultant
Regulator Political Beneficiary
Interfacing System
Purchaser
Functional Beneficiary
Sponsor or Champion
Maintenance Operator
Normal Operator
Operational Support
Figure 14: Onion Model of Volere Stakeholder Roles
Several Slots (greyed-out) remain unfilled.
Several other Slots (especially Consultant, Developer) are heavily populated (see Table 1).
5.3 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 Research Review).
32
“Typical
Consumer”
“Operator of
Current Product”
“Salaried
Authority”
“Project
Intermediary”
The large (unreachable)
Population
present-for-future analogue
(small)
sample
professional interpretation
official
voice
e.g. soldier, pilot,
railway signaller
e.g. PDA user,
car driver
e.g. Safety
Regulator
e.g. Requirements Engineer,
Product/Marketing Manager,
User Interface Designer
Figure 15: Four Kinds of Stakeholder Surrogacy
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.
Type of
Surrogate
Stakeholder
Example Relationship with
Stakeholder
Population
Advantages Risks
‘Typical
Consumer’
Car drivers paid to give opinion
of new models of car
statistical sample is a real operator/
beneficiary of the product
may not be typical;
danger of mis-sampling
‘Operator of
Current Product’
Soldier helping to define military
equipment needs 25 years into
the future
present-for-future
analogue in the
domain
is a real operator of
analogous products
analogy may not hold in
future environment;
obsolescence
‘Project
Intermediary’
Requirements Engineer writing
other people’s requirements;
Product Manager purchasing
development of product on
behalf of both consumers and
financial beneficiaries (e.g.
shareholders)
professional
interpretation
familiar with engineering
development
misinterpretation through
lack of domain
knowledge; over-
technical focus (bias
towards technology);
invented requirements
(Potts 1995)
‘Salaried Authority’
Aviation Authority (Safety
Regulator) checking safety on
behalf of public
official voice statutory position;
enforcement of
requirements enshrined in
law
remote from population
and product operations;
bureaucracy
Table 2: Stakeholder Surrogacy Relationships
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.
Combinations and intermediate types can also be identified. For example,
environmental pressure groups and ‘not in my back yard’ campaigners may create
leaders who, though unofficial and unpaid, may act almost as Regulators, being
invited to meetings and having their (Negative) opinion sought.
33
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: successively more
human-oriented languages and tools (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: successively
more stakeholder-oriented documents and diagrams (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
<named stakeholder role> wants <result>.
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
<named surrogate role> believes that <named role> wants <result>.
In law statements of this kind are called ‘hearsay evidence’ which is rarely admissible
in court. But our surrogates often cannot even claim to have heard anyone else
expressing their requirement, however distantly. In the clearcut case of the
procurement of military equipment on behalf of as yet unborn soldiers, there can be
no claim even to hearsay evidence: the requirements are wholly invented.
Surrogacy thus interferes with the core trend and practical process of RE: the move
towards gathering requirements directly from real stakeholders. Yet as Figure 15
indicates, surrogacy cannot readily be avoided (even when the ‘unreachable
population’ is not especially large). Perhaps this is one of the fundamental limitations
on the engineering of requirements, systems, and software.
Suzanne Robertson comments that it can help to invent a surrogate, e.g. Erik the
systems analyst. Erik could then be ‘consulted’ on his needs:
“Whenever we were stuck (should this be in or out, more or less detailed) we went and talked to Erik. Yes really, on our noticeboard we had a photo of him clipped from an SAS airline magazine. He looks like a good journeyman systems analyst, he works for a company that make fruit juices. Medium height, pleasant expression, Scandinavian glasses.” (Robertson 2004).
Without the surrogate, they’d never have been able to finish the job.
5.4 Visual Metaphors
An Onion Diagram inherently embodies a set of visual metaphors, and these are
exploited more or less consciously to give a feeling for stakeholder relationships in a
development project. Metaphors inevitably break down at some point, so some
caution is required. Attention is drawn to the limitations of the onion model below.
34
The most immediate of these visual metaphors is the feeling of successive (indeed
recursive) containment of one 'onion' within another. As Peter Checkland and others
have emphasized, there are always many systems to consider (Checkland & Scholes
1990). This leads to practical issues of project scope. The scope of a system of
people-and-equipment is always larger than the scope of the equipment or product
alone, so it is essential to be clear about the existence of the two boundaries (e.g.
Robertson & Robertson 1999).
A circular diagram inevitably announces that something is in the centre of attention,
and in a development that is rightly the product; at the same time, it shows that people
are ‘all around’ it and have importance. It also suggests the metaphor of closeness for
relatedness, and for example developers are shown close to purchasers for this reason.
Distance could suggest that stakeholders in the outer circles are less important, but
this is not intended. Indeed, negative stakeholders, regulators, and political
beneficiaries are all able to ‘stop the show’ and must be considered essential.
We also habitually make use of other spatial metaphors; supporting roles seem
naturally to find a place below the product, while interfacing systems and regulators
can go ‘off to the side’ somewhere.
A cautionary note should be sounded here: a naïve reading of the onion model with
the equation: outer = higher in the system or company hierarchy, with regulator in the
outermost circle, would imply the equation regulator = responsibility for highest level
of system. This is simply wrong. As Michael Jackson cautions (Jackson 1995, and see
the Research Review), there may be many overlapping hierarchies. Three that are
often important in thinking about system development are:
1) the scopes of the product and the systems that contain it: this is the primary and intended meaning of the onion diagram. The operational stakeholders are those
inside ‘the system’, as explained below.
2) the organisation (e.g. company) hierarchy, with the workers at the bottom/inside and the managers and directors towards the top/outside. This is not what is
intended here. Managers may or may not be stakeholders in a development; non-
operational company workers and executives are not automatically assumed to be
relevant.
3) the structure of the organisations and stakeholder relationships involved in accepting or rejecting a development, e.g. the relationship of the regulator with the
developer. This structure is secondarily suggested by the onion diagram, but this
does not mean that questions like ‘which level of system is the regulator in?’ make
any sense. The regulator is in a system – that of the political and legal framework
of a country or the world – but that is certainly not the same as any onion-circle of
any ordinary development project.
The onion has its uses in helping people to think about multiple scopes and the need
to involve people outside the development team, but it can’t do everything.
Another metaphor that seems quite natural (though perhaps mixing oddly with
onions) is that of the chain of command, where a person makes use of a system under
their command as an instrument to achieve a ‘political’ goal. They do this by
instructing an immediate subordinate – some at the adjacent or immediately contained
level – to carry out some operation. That person in turn may achieve their goal (a
successful operation) by instructing an operator to use a piece of equipment to deliver
a specific result. The ‘chain’ metaphor could also be represented as a scale from
35
higher to lower if you like the idea of a Great Chain of Being from God to man to
animals (Lovejoy 1936); I have chosen to make it the rather more egalitarian left-to-
right (with the slight suggestion that actions, like writing, may proceed in that
direction).
6. Conclusion The trend in system specification away from the machine towards human “users”
leads to a natural end-point in modelling and analysing the nature, goals, and
viewpoints of human stakeholders. While there has been some academic interest in
goal and viewpoint modelling, the stakeholders themselves seem largely to have been
overlooked within systems and software engineering (though quite the reverse in soft
systems and information systems research).
The 'onion model' diagram has an attractive and intuitive simplicity about it,
organizing a substantial amount of complexity in analysis of stakeholder sociology
and relationships. This is part of a wider interest in and intention to improve the
attention that practising engineers pay to stakeholders, including surveys and a
reconsideration of development life-cycles and project information models
(Alexander & Robertson 2004). The default onion model with three circles and the
basic slots is often in itself helpful on projects, but it is readily tailored for more
complex situations with additional circles and slots. Ralph Young has adopted the
approach in his book (Young 2004, pp 65-67), and Suzanne and James Robertson are
similarly doing so in their new book (Robertson & Robertson 2004). Needless to say,
it is also pressed into service in my book (Alexander & Maiden 2004).
Tool support is available, but the approach can be applied with nothing more than a
hand-drawn diagram and a textual hierarchy of headings for circles, slots, roles, and if
desired named stakeholders.
The analysis of stakeholders does not presuppose any particular development
approach, and while it is clearly suitable for an object-oriented worldview with use
cases and their actors, it can equally be added to conventional or agile development.
This paper has presented a simple but it is hoped generally-applicable and readily-
customised taxonomy of stakeholders, and has suggested some uses for it. If it
contributes to encouraging even a few projects to think a little more deeply about who
their stakeholders are and what they want, it will have succeeded.
7. Acknowledgements I am grateful to Isabel Ramos for her suggestions and encouragement for this paper;
to Andrew Farncombe for his clarity on terminology and multiple hierarchies; to
Sabina Malfatti for drawing my attention to the onion-layers in Peer Gynt; and to
Suzanne Robertson for her continuing enthusiasm and support. I would also like to
thank the anonymous reviewers for their perceptive comments and suggestions
especially on the voluminous Information Systems literature, and the Editor – Bernd
Stahl – for his measured criticism and direction.
8. References Alexander, I. (2002). Initial Industrial Experience of Misuse Cases in Trade-Off
Analysis, IEEE Joint International Requirements Engineering Conference, 9-13
September 2002, Essen, Germany, 61-68.
36
Alexander, I. (2003). Stakeholders – Who is Your System For?, Computing & Control
Engineering, 14, Issue 1, 22-26, April 2003.
Alexander, I. & Maiden, N. (Editors) (2004). Scenarios, Stories, Use Cases through
the system development life-cycle, John Wiley.
Alexander, I. & Robertson, S. (2004). Understanding Project Sociology by Modeling
Stakeholders, IEEE Software, 21, No. 1, January/February 2004, 23-27.
Alexander, I. & Stevens, R. (2002). Writing Better Requirements, Addison-Wesley.
Avison, D. & Wood-Harper, A.T. (1990). Multiview: An Exploration in Information
Systems Development. Oxford: Blackwell Scientific Publications.
Bennetts, P. D. C. & Wood-Harper, A.T. (2000). Software Process Improvement
through the Lens of Multiview 2: The Development of a Contingent Factors Model, in
10th Conference on Business Information Technology, Manchester, UK.
Boehm, B., Grünbacher, P., Briggs, B. (2003). Developing Groupware for
Requirements Negotiation: Lessons Learned, IEEE Software, May/June 2001, 46-55.
Bowker, G.C. & Leigh Star, S. (1999). Sorting Things Out, classification and its
consequences. MIT Press.
Checkland, P. & Scholes, J. (1990). Soft Systems Methodology in Action, John
Wiley. New edition with a 30-year retrospective, 1999.
Coakes, E. & Elliman, T. (1999). Focus issue on legacy information systems and
business process engineering: the role of stakeholders in managing change,
Communications of the AIS, Volume 2, Issue 1es (July 1999), Article No. 4.
Damian, D.E. & Zowghi, D. (2002). The impact of stakeholders’ geographical
distribution on managing requirements in a multi-site organization, proceedings of the
IEEE Joint International Requirements Engineering Conference, Essen, Germany,
September 2002, 319-328.
Donaldson, T. & Preston, L.E. (1995): The Stakeholder Theory of the Corporation:
Concepts, Evidence, and Implications. In: Academy of Management Review 1995,
Vol 20, No 1: 65 - 91
Fowler, M. & Scott, K., (1999). UML Distilled, A Brief Guide to the Standard Object
Modeling Language, Addison-Wesley.
Gause, D. & Weinberg, G. (1989). Exploring Requirements, Quality Before Design,
Dorset House.
Hirschheim, R. & Klein, H.K. (2003): Crisis in the IS Field? A Critical Reflection on
the State of the Discipline. In: Journal of the Association for Information Systems
(4:5): 237 - 293
Ibsen, H. (1867): Peer Gynt. Modern English translation: Theatre Communications
Group, 1992. (First published in Norwegian, 1867).
Jackson, M. (1995). Software Requirements & Specifications, a lexicon of practice,
principles and prejudices. Addison-Wesley.
Kitapci, H. & Bhuta, J. (2004.) EasyWinWin Negotiations: Guidelines and
EasyWinWin Report, http://sunset.usc.edu/classes/cs577a_2003/assignments/Team/
EasyWinWin%20Negotiations.htm (downloaded 20 April 2004)
37
Kotonya, G. & Sommerville, I. (1998). Requirements Engineering : Processes and
Techniques, John Wiley.
Koyré, A. (1957). From the Closed World to the Infinite Universe. The Johns
Hopkins University Press, Baltimore and London. (Reprinted in paperback 1968)
Levine, R., Locke, C., Searls D. & Weinberger, D. (2000). The ClueTrain Manifesto,
The end of business as usual, FT.com, London.
Lovejoy, A.O. (1936). The Great Chain of Being. Harvard University Press,
Cambridge, Massachusetts. (Reprinted in paperback, 1990)
Mason, R. & Mitroff, I. (1981). Challenging Strategic Planning Assumptions:Theory,
Cases, and techniques. New York: John Wiley & Sons.
McGraw, K., & Harbison, K. (1997). User-Centered Requirements, The Scenario-
Based Engineering Process, Lawrence Erlbaum Associates.
Midgley, G. (1992). The Sacred and Profane in Critical Systems Thinking, Systems
Practice, (5)1, 5-16.
Mumford, E. (1996). Systems Design, Ethical Tools for Ethical Change. Macmillan.
Potts, C. (1995). Invented Requirements and Imagined Customers: Requirements
Engineering for Off-the-shelf Software (Invited workshop introduction paper), Proc.
RE'95: Second International Symposium on Requirements Engineering, York,
England, March, 1995, IEEE Computer Society Press. Available from
http://www.cc.gatech.edu/fac/Colin.Potts/pubs/1995/re95/re95InventedReqtsOTS.pdf
(downloaded 20 April 2004)
Pouloudi, A. (1999). Aspects of the Stakeholder Concept and their Implications for
Information Systems Development. Proceedings of the 32nd Hawaii International
Conference on System Sciences, Volume 7, January 5-8 1999, Maui, Hawaii.
Available from http://www.computer.org/proceedings/hicss/0001/00017/
00017030abs.htm?SMIDENTITY=NO (downloaded 20 April 2004)
Pouloudi, A., & Whitley, E. A. (1997). Stakeholder identification in inter-
organizational systems: gaining insights for drug use management systems. European
Journal of Information Systems, 6 (1), 1-14.
Robertson, S. (2004). Personal communication. 18 March 2004.
Robertson, S. & Robertson, J. (1999). Mastering the Requirements Process, Addison-
Wesley.
Robertson, S. & Robertson, J. (2004). Requirements-Led Project Management,
Addison-Wesley (to appear).
Scenario Plus (2004). Scenario Plus website: http://www.scenarioplus.org.uk (onion
model tool for Telelogic DOORS, stakeholders template for Microsoft Word, etc).
(downloaded 20 April 2004)
Sharp, H., Finkelstein, A. & Galal G. (1999). Stakeholder Identification in the
Requirements Engineering Process. DEXA Requirements Engineering Process
Workshop, 387-391.
Sommerville, I., Sawyer, P., Viller, S. (1998). Viewpoints for Requirements
Elicitation: a Practical Approach, Proceedings Third IEEE International Conference
on Requirements Engineering.
38
Sutcliffe, A. (2002). User-Centred Requirements Engineering, Theory and Practice,
Springer.
Volere (2004). Volere Stakeholder Analysis Template, http://www.volere.co.uk
(downloaded for analysis 20 February 2004)
Wood, D. (1999). Trends in Stakeholder Management & Measurement in the Public
Sector, http://www.navigate.co.nz/newsreti.htm (downloaded 20 April 2004)
Young, R.R. (2004). The Requirements Engineering Handbook, Artech House.
Younkins, E.W. (2001). Morality and Character Development: The Roles of
Capitalism, Commerce, and the Corporation, Journal of Markets & Morality 4, 1
(Spring 2001), 94-111 http://www.acton.org/publicat/m_and_m/2001_spring/
pdf/mm-v4n1-younkins.pdf (downloaded 20 April 2004)
Yu, E. & Mylopoulos, J. (1998). Why Goal-Oriented Requirements Engineering,
Requirements Engineering Foundation for Software Quality Workshop 1998,
http://www.cs.toronto.edu/pub/eric/REFSQ98.html (downloaded 20 April 2004)
View publication statsView publication stats
