The Role of Stakeholders in Requirements Elicitation

Michael J. Ryan
School of Engineering and Information Technology, University of New South Wales Canberra
at the Defence Force Academy, Northcott Drive, CANBERRA,
ACT, 2600.
Telephone: 02 62688200. Facsimile: 02 62688443. E-mail: m.ryan@adfa.edu.au
Copyright © 2014 by Michel J. Ryan. Published and used by INCOSE with permission.

Abstract. The requirements definition process begins with the elicitation of

stakeholder requirements, the first step of which is to identify the stakeholders from
whom those requirements are to be gathered. It is common in requirements
engineering to define a stakeholder as someone who has a stake in the project—that is,
someone who is affected by the system in some way, or can affect the system in some
way. In most systems, this definition is not useful since, regardless of where the
system boundary is set, it is often difficult to find someone who is not affected by the
system. While we must take into account anyone or anything that is affected by, or
that can affect, the system when considering requirements, such entities are not
automatically (nor necessarily) stakeholders. This paper proposes that a more useful
definition of a stakeholder is someone who has a right to influence the system. A
method for selecting stakeholders is proposed, and a simple example is provided to
illustrate the process.

INTRODUCTION
In requirements engineering, a stakeholder is commonly defined as someone who has
a stake in the project—that is, someone who is affected by the system in some way, or
can affect the system in some way. Stakeholders are the people from whom we first
elicit requirements, and then from whom we obtain the input necessary during
requirements analysis and negotiation, and then who will finally accept the system
into service. Their input to the system lifecycle is crucial—careful selection of
appropriate stakeholders is therefore fundamental to the success of the project.

The term stakeholder originally applied to a third party who holds the money (the
stake) wagered by one or more parties—the money is held in escrow and paid out,
under the terms and conditions of the wager, to the winning party or parties. The
stakeholder is trusted by the wagering parties to act fairly in accordance with the terms
and conditions of the wager—with a level of a trust that the wagering parties
presumably do not have in each other. To assure all parties of a sufficient level of
trust, it would be normal that the stakeholder is independent of the wager and
therefore does not themselves have a vested interest (a stake) in the event. The term is
therefore originally applied to a person who is trusted by the parties involved in an
event but is independent of the outcome of that event.

In the early 1980s, Mason and Mitroff (1981) made use of the term stakeholder to
refer to any person or thing that can affect or is affected by the matter under
consideration (whether a venture, process, project, system, organization or
decision)—they were keen to differentiate a ‘stakeholder’ from a ‘shareholder’ or
stockholder’ who had a vested interest and therefore would act in accordance with that
interest (presumably at the expense of other interests). Since that time the use of the
term has become such that, rather than being a trusted, independent human in a
particular type of (gambling) event, stakeholders are seen to be present in any event;
they may or may not have a vested interest; are not necessarily trusted to the extent
that they may even have a negative or malicious intent; and, finally, may not even be
human since organizations, entities, regulations, and even environmental aspects
(including animals as well as inanimate objects) are now often considered to be
stakeholders.

CURRENT DEFINITIONS OF A STAKEHOLDER

Mason and Mitroff (1981) defined stakeholders as claimants who have a vested
interest in an organizations’ plans. Glinz and Wieringa (2007) suggest that the first
definition of a stakeholder in the context of requirements engineering was in a paper
by Macaulay (1993) based on the work by Mitroff (1983) “… all those who have a
stake in the change being considered, those who stand to gain from it, and those who
stand to lose” (Macaulay, 1993). This use is consistent with the use in the broader
context of project management. Littau, Jujagiri, and Adlbrecht (2010) conducted a
survey of 25 years of project management literature and identified three main types of
definition which characterized a stakeholder as: 1) interested in, or 2) affected by or
can affect the project; or 3) some combination of the first two (that is, interested in, or
can affect, or be affected by).

The 2013 version of the Project Management Body of Knowledge places increased
emphasis on stakeholders and has added a tenth knowledge area “Project Stakeholder
Management”, offering the definition of a stakeholder as: “… persons or
organizations who are actively involved with the project, or whose interests may be
positively or negatively affected by the performance or completion of the project”
(PMBOK, 2013). This definition reflects common usage of the term and highlights the
possibility of negative effects (from such people as competitors and adversaries). This
extension of the categories of stakeholder is even broadened by some to include other
beings—for example, Starik (1995) argues that “…the natural environment, its
systems, and living and non-living components can be considered stakeholders by all
organizations, since all organizations significantly affect or are significantly affected
by these entities.”

THE UTILITY OF THE CURRENT DEFINITIONS

With such a wide definition, the list of stakeholders for a system therefore includes all
those people and any other living and non-living systems and objects which are
perceived by somebody to have, or perceive themselves to have, some interest in the
project, or some ability to affect it or be affected by it. In most systems this is simply
not a useful definition since it is often difficult to identify someone who is not affected
by, or interested in, the system in some way. Even in a relatively straightforward
system such as an ATM network for a bank, there may be millions of stakeholders by
such a definition. This is also true in committee-based organizations such as public
sector organizations, where the number of potential stakeholders is enormous, even
when the definition is restricted to just humans.
We simply cannot progress with such a definition of the stakeholders from whom we
are expected to elicit requirements. First, if there are so many, we cannot possibly
have the time to engage with everyone who will have an involvement with the new
system (even if we only restricted ourselves to representatives of selected groups).
Second, it assumes that anyone affected by the system is a source of
requirements—competitors will be affected, for example, but they are not going to be
asked what they would like to see in the new system (although they would always be
taken into account). Additionally, it would mean that anyone who wants to have a say
should be able to influence requirements—the system design would therefore be at the
mercy of the stakeholder(s) who want to contribute requirements, whether they are
useful or not. Further, designers cannot engage with the natural environment and other
inanimate objects but must choose a human representative to speak on their behalf.
Finally, the new system will have disparate effects on stakeholders—they will not be
affected equally and they would not normally therefore have equal rights in
expressing requirements.

THE NEED TO IDENTIFY RELEVANT STAKEHOLDERS

Although the extant definitions are very broad and therefore not very informative, we
know that we ignore potential stakeholders at our peril. The requirements engineering
literature contains many warnings of the risk to a project of not identifying the
relevant stakeholders from whom requirements are elicited—identifying the correct
stakeholders will help prevent missed requirements. For example, Katonya and
Sommerville (2000) suggest that: “You need to identify the important stakeholders in
a system and to discover their requirements.” Or else, if you don’t do so, they insist on
changes during development or after delivery of the system (Katonya and
Sommerville, 2000). Further, Aslaksen (2009) points out that clear identification of
stakeholders is essential since “… the dissatisfaction with the performance of the
delivered system will just as often be due to inadequate definition and understanding
of the stakeholder group and its dynamics as to any shortcoming in the subsequent
design process”. On the other hand, we also know that no complex system can be
optimum to all parties concerned nor can all functions be optimized (Maier and
Rechtin, 2000), so these ‘soft’ aspects must be taken into account before settling on an
appropriate set of stakeholders.

A BETTER DEFINITION OF A STAKEHOLDER

The first step of identifying stakeholders is therefore much more complicated than
simply listing all those people and things that could be considered to have a stake in
the new system. More usefully, if a stakeholder is to be a source of requirements (that
is, to be of assistance in defining the system in some way), they must have a right to do
so, rather than simply be someone who is affected by the system. Alexander and
Stevens (2002) provide a similar definition of a stakeholder as someone who has a
justifiable claim to be allowed to influence the requirements.

Still, this improved definition does not assist us to identify our stakeholders
automatically. If a stakeholder has a right to influence the requirements, we need to
identify what or who gives them that right. Even then, as discussed earlier, we need to
examine candidate stakeholders more carefully. For example:
• Who gives a stakeholder the right to state requirements?
• Do all stakeholders have equal rights?
• If not, who decides which stakeholders have higher priority?
• What do we do if stakeholders do not agree?
• If a group of people is considered to be a stakeholder, do they all have a voice, or
is a spokesperson to be elected/nominated?
• How do we collect requirements from stakeholders that do not have a voice (such
as animals and inanimate objects)?
• How do we discount requirements collected from a stakeholder who is clearly
confused and whose contributions are unenlightening?
• How do we identify and deal with adversarial stakeholders who do not wish the
project to be successful?

These issues are addressed by the formal process described in the next section.

IDENTIFYING STAKEHOLDERS
In order to accommodate the issues discussed in the previous sections, the act of
identifying stakeholders has a number of activities that are discussed in more detail in
this section:
• Identify a business owner that is able and willing to conduct/endorse the activity
of identifying stakeholders and to assist in stakeholder management.
• Identify all candidate stakeholders (anyone affected by the system or able to
affect it).
• Evaluate candidates and select stakeholders (individuals or groups of
stakeholders by type).
• Understand roles, responsibilities, and interrelationships of stakeholders and
stakeholder groups.
• Identify a stakeholder representative (an individual) for each stakeholder group
(or non-human stakeholders).
• Prioritise stakeholders.
• Form the Stakeholder Board.
• Develop stakeholder management strategies.
• Prepare the Stakeholder Management Plan (SMP).

Identify business owner

In the context of a particular system development, there must be a business owner
(most likely at the business management level) who is responsible for (and answerable
for) the system development. This individual (or perhaps committee) must have
sufficient authority to make decisions with regard to the project and the system
development. Additionally, they must be able to endorse the Stakeholder
Management Plan, to appoint stakeholder representatives, and to agree stakeholder
priorities. They must also have sufficient authority to settle disputes between parties.
Without such an owner of the process, very few of the necessary trade-offs will be
able to be made during the requirements-engineering process. With this broad range
of responsibilities, the responsible business owner is also commonly referred to as the
project champion (Leffingwell & Widrig, 2000)—here we call them the business
owner.
 In this key role, the business owner:
• nominates stakeholders;
• allocates stakeholder rights and priorities;
• manages the elicitation/elaboration process;
• chairs the Stakeholder Board;
• arbitrates stakeholder conflict and makes hard decisions where necessary;
• provides the conduit between the business (the business case) and the project
(particularly the requirements-engineering effort);
• negotiates resources on behalf of the project;
• protects the project from any vagaries of the business environment; and
• manages stakeholder and business expectations.

Identify all candidate stakeholders

The first task in identifying stakeholders is to identify the candidate
stakeholders—that is, to list anyone or anything that may have, or may be perceived to
have (or who may perceive themselves to have) a stake in the project. As with the
definition of stakeholder most commonly used, we should identify anyone or anything
that meets the very general criteria of someone or something that is interested in the
system, or is affected by the outcome of the system, or is able to affect it in some way.
Where possible we should identify candidates by type—that is, we should group them
in accordance with common interest/effect and common requirements.

We should recognize that we may not be able to identify all candidate stakeholders at
the outset—like most aspects of requirements engineering, our ability to identify
stakeholders will improve as we understand the system better as we progress through
the design.

Evaluate candidates and select stakeholders

Once we have a comprehensive list of candidate stakeholders, we evaluate each to
determine whether they are a genuine stakeholder, or whether they are simply an actor
within the system, or a constraint placed either on the way in which the system is to
operate or the manner by which it is developed. Again, it must be emphasized that
anyone on our list of candidate stakeholders is important and we must understand their
interest in the system. The crucial difference lies in what we make of their
contribution.

Stakeholders have the right to influence the system requirements, so it is from them
that we allow opinions as to what the system should do and how it should look and
perform. Others such as operators and maintainers may be stakeholders but, since it
not necessarily their business, we are normally interested in their requirements as
constraints that may need to be accommodated by the system, rather than considering
them as stakeholders.

Understand roles, responsibilities, and interrelationships

Once we have defined the stakeholders and stakeholder groups, we must understand
the roles and responsibilities of each individual group and how they interact. This
understanding is essential to guide the requirements-engineering process in aspects
such as requirements elicitation/elaboration, and trade studies—it is also an essential
precursor to the prioritization (categorization) of stakeholders.

Identify stakeholder representatives

We cannot engage with all stakeholders of a certain type because we don’t have time
and we would be at the mercy of such a large number of opinions (even if they are
similar, each person will provide us with a slightly different view). In some cases,
when an animal or an inanimate object is considered a stakeholder, we cannot engage
directly with them at all. We must therefore identify appropriate representatives who
can speak on behalf of that stakeholder community—it is from these representatives
that we elicit requirements and from whom we seek the input necessary during
requirements analysis and negotiation. Since their input to the system life cycle is
crucial, careful selection of appropriate representatives is very important.

Within each group of stakeholders, we must identify which individual is suitable as a

representative of the group. In addition to being able to contribute to the requirements
elicitation process, it is very important that each representative is supportive and
powerful (at least within their community). This individual must be accepted by the
group as their spokesperson (that is, they must be able to speak with authority on
behalf of the group).

Ideally, a suitable stakeholder representative must:

• understand the business domain;
• understand this particular application area within the business domain;
• understand the specific problem;
• understand systems engineering;
• understand the requirements-engineering process;
• understand engineering;
• understand the associated technology;
• faithfully represent the requirements of their stakeholder community;
• be supportive of the system and the requirements definition process;
• be well respected, at least within their stakeholder community; and
• have sufficient time to be able to contribute when required.

Clearly, the success of the requirements-engineering process (particularly elicitation

and elaboration) will depend heavily on the careful selection of stakeholder
representatives. Even then, since there are not likely to be too many stakeholders that
possess all of the above attributes, a period of training and education will no doubt be
required at the beginning of every project to ensure that stakeholders are aware of the
requirements-engineering processes to be implemented.

Prioritize stakeholders
As with most human endeavors, stakeholder management works best when everyone
involved in the process understands their role—that is, they understand their position
(and that of their requirements) in the context of the business, the system, and the
system life cycle. It is almost impossible to progress with a large number of
stakeholders, each of whom has equal rights to the others—two conflicting
requirements of equal priority cannot be traded off effectively. Stakeholders should
therefore be grouped into categories and the priority and the rights of each category
should be made explicit.

In particular, requirements analysis is greatly aided if stakeholders’ inputs are

prioritized—design spaces are much more readily identified if some dimensions have
more weight than others. Additionally, the priority of stakeholders will assist the
requirements engineers to prioritize their elicitation and elaboration activities,
particularly early in the process.

Form the Stakeholder Board

The Stakeholder Board provides the mechanism by which stakeholder needs and
requirements are elicited, crystallized, endorsed and then managed throughout the life
of the system. The board is formed from the selected stakeholder representatives, each
of which has a voice commensurate with the priority allocated to them. The board is
chaired by the relevant business owner, who is responsible for leading the
requirements-engineering effort. There should be an even number of stakeholder
representatives on the board so that any deadlock can be broken by the casting vote of
the chair (should the business environment be one that requires consensus).

Develop stakeholder management strategies

Once all stakeholders have been identified and grouped, and representatives have
been identified and prioritized, strategies can be developed to maximize stakeholder
involvement in the requirements engineering process. Largely, this involves creating a
favorable environment by recognizing that, while there are some technical difficulties
with requirements engineering, it is fundamentally a process dominated and driven by
humans (and their preconceptions, prejudices, and agendas)—it is therefore often less
concerned with what we can do and more concerned with what we want to do. These
‘soft’ aspects must be accommodated and managed if the system development is to
succeed.

Prepare Stakeholder Management Plan (SMP)

As a minimum, the Stakeholder Management Plan should:
• identify the business owner responsible;
• list stakeholders by category (priority) and type;
• identify stakeholder representatives;
• identify stakeholder roles and responsibilities;
• nominate the Stakeholder Board and identify the chair; and
• nominate stakeholder management strategies (this may be in a separate
document, or in an annex available only to business management).

A SIMPLE EXAMPLE—BUILDING YOUR OWN HOUSE

By way of a simple example that highlights the issues associated with stakeholder
selection, consider a project in which you and your partner are building a home for
yourselves and your two children.
Business owner: In this case there would no doubt be a team approach and you and
your partner would be the business owners (assuming that the mortgage is in joint
names). Of course, there may be circumstances (for a variety of reasons) in which one
of you may take a principal role.

Identify candidate stakeholders: The following may be considered candidate

stakeholders:
• You and your partner.
• Your children.
• In-laws who may visit and may stay occasionally.
• Friends who may visit and may stay occasionally.
• The bank holding the mortgage.
• Local government.
• Neighbors.
• The architect and draughtspersons.
• The builder and subcontractors.
• The tree that is inconveniently located in the front yard.

Evaluate candidates and select stakeholders: Let’s look at each of these candidates
in a little more detail:
• You and your partner. Assuming once again that you and your partner are the
joint mortgage holders, it is difficult to imagine that any other candidate
stakeholder has the right to mandate to you any aspect of the system design. So, in
this case, the business owners (you and your partner) are clearly stakeholders.
• Your children. You will certainly take into account the wishes of your children
but they will have rights that are significantly moderated by your desires (and
budget). Of course, in some cases, such as the right to choose the color of their
room, you may give them limited stakeholder rights, but you are not likely to do
that when deciding on the inclusion of a swimming pool.
• Relatives who may visit and may stay occasionally. You are also unlikely to
give your relatives the right to dictate any requirements of the system. However,
should an aged parent be occupying the house with you, you may give them
similar rights to the children with regard to the layout of their room. Additionally,
should you have a relative who is limited in their physical ability in some way,
you might place increased emphasis on access requirements—although this does
not make them a stakeholder. In some cases (abnormal, of course), you may not
like your relatives and may deliberately design the house without a spare room so
that they cannot come and stay with you—that is, you may deny them any rights
and deliberately exclude them from the system. Of course, there may be
circumstances where this harsh exclusive view may change. If a relative has
contributed significantly to the purchase of the house, they may have the right to
dictate requirements (although, if their donation was purely philanthropic, they
may well waive that right).
• Friends who may visit and may stay occasionally. Depending on your
relationship with your friends and relatives, friends may have a similar priority to
relatives. They are, however, most likely to play only a minor role.
• The bank holding the mortgage. Despite the fact that the bank has significant
power over you and the house, it is not a stakeholder—it does not have the right to
dictate any aspect of the house design. Since the bank does dictate the budgetary
 limit of your aspirations, they quite clearly provide a number of external
constraints on the project—but they are not stakeholders and you will not engage
with them again during the project providing that you do not default on your
mortgage, or need to apply to exceed its current limit.
• Local government. Similarly, the local government regulations will place
significant constraints on the house design and its location on the block, the
utilities it will access, and so on. The ability to impose regulatory constraints does
not make them a stakeholder, however. Their principal impact will be as a source
of constraints.
• Neighbors. Again, neighbors are constraints, not stakeholders. They may cause
you difficulty in the building approval process if some aspect of the design
impinges on their community rights, but the fact that they are a stakeholder in the
community does not make them a stakeholder in your project. Their principal
impact, if any, will be as a source of constraints.
• The architect and draughtspersons. The architect has a considerable interest in
the success of the project in that their reputation will suffer of the building falls
down or even looks awful when completed. This interest in the success of the
project does not make them a stakeholder, however—their skill and ability, their
availability, their interest, and their enthusiasm are again constraints for the
project.
• The builder and subcontractors. Similarly, builders and their subcontractors
are constraints, not stakeholders. Although, for example, you may be purchasing
your home from a developer/builder and you have arranged some form of
discount on the purchase price in return for allowing the builder to use your home
as a display home for a short period—in that case, the builder may become a
stakeholder with limited rights.
• The tree. The role played by the tree will depend on a number of factors. Perhaps
there are council regulations which state that trees over a certain size cannot be
removed, in which case the location of the tree is a constraint on the building
project. Otherwise, assuming the owners are not constrained in any way by
relevant legislation, it is up to the business owners as to what ‘rights’ may be
attributed to the tree—if the owners favor the tree over the layout of the house, the
tree will remain; if a convenient layout of the house is more important, the tree
will be felled. In either case, the location of the tree is a constraint, which may or
may not be lifted depending on extant regulations and the desires of the business
owners.

Roles, responsibilities, and interrelationships. Although you and your partner are
the only genuine stakeholders in this venture, you may wish (even if only to increase
their enthusiasm for the impending move to a new house) to provide the children with
some stakeholder rights. In that case, the roles responsibilities, and interrelationships
of the children within the family will be obvious and straightforward to describe.

Stakeholder representatives. You and your partner will no doubt jointly share the
role as principal stakeholder, although one of you may waive this right in most
circumstances and defer to the opinions and preferences of the other. Assuming you
have decided that the children will share a single room, you may choose one as the
representative, or you may decide to make them equally responsible for their
decisions—that is, they must agree on those requirements you have allocated to them
(such as the color and layout of the room) and therefore each be a stakeholder. Should
they have separate rooms, then you would most likely allow each child to be a
stakeholder in their own right.

Prioritize stakeholders. You and your partner will be Category 1 stakeholders. The
children would be (may each be) Category 2 stakeholders with very limited rights as
defined at the beginning of the project. Similar rights may be extended to an in-law
who has provided funding to the house. In the same vein, you may wish to refer to the
architect and builder as Category 3 stakeholders to assist in ensuring that they have
some ownership of the project, although their rights will not extend much beyond that.
The bank, neighbors, local council, architects, builders, and the location of the tree
will largely be a source of constraints.

SUMMARY
Careful selection of appropriate stakeholders is fundamental to the success of the
project and, in particular, to the success of the requirements elicitation process. The
traditional definition of a stakeholder—someone who is affected by the system in
some way, or can affect the system in some way—is not useful in being able to
identify those who should contribute to the requirements engineering process. More
usefully, a stakeholder is defined as someone who has a right to influence the outcome
of the system, rather than someone who is simply affected by the system. A
stakeholder is therefore an owner of the problem, not just someone involved in or with
it. This paper has proposed a formal method for the identification of stakeholders and
has provided a simple example to illustrate each of the steps.

References
Alexander I.F. and R. Stevens, Writing Better Requirements, London: Addison
Wesley, 2002.
Aslaksen, E.W., Designing Complex Systems: Foundations of Design in the
Functional Domain, Boca Raton: CRC Press, 2009.
Glinz, M. and R.J. Wieringa, “Stakeholders in Requirements Engineering”, IEEE
Software, March/April 2007, pp. 18–20.
Kotonya, G. and I. Sommerville, Requirements Engineering: Processes and
Techniques, Chichester, England: John Wiley & Sons, 2000.
Leffingwell, D. and D. Widrig, Managing Software Requirements: A Unified
Approach, Reading, M.A.: Addison-Wesley, 2000.
Littau, P., N.J. Jujagiri, and G. Adlbrecht, “25 years of Stakeholder Theory in Project
Management Literature (1984-2009)”, Project Management Journal, pp.
17-29, 2010.
Maier, M. and E. Rechtin, The Art of Systems Architecting, Boca Raton, F.L.: CRC
Press, 2000.
Mason, R.O, and I.I. Mitroff, Challenging Strategic Planning Assumptions: Theory,
Cases, and Techniques, New York, NY: John Wiley & Sons, 1981.
Macaulay, L., “Requirements Capture as a Cooperative Activity”, Proceedings of the
1st IEEE International Symposium on Requirements Engineering, IEEE CS
Press, 1993, pp. 174–181.
Project Management Institute Standards Committee, A Guide to the Project
Management Body of Knowledge, Upper Darby P.P: Project Management
Institute, 2013.
Starik, M., “Should Trees Have Managerial Standing? Toward Stakeholder Status for
Non-human Nature”, Journal of Business Ethics, Vol. 14 No. 3, pp. 207-17,
1995.

Biography
Dr Mike Ryan is a Senior Lecturer with the School of Engineering and Information
Technology, University of New South Wales, Canberra. He holds Bachelor, Master
and Doctor of Philosophy degrees in electrical engineering as well as a Graduate
Diploma in Management Studies. For the first seventeen years of his career he held a
number of communications engineering, systems engineering, project management,
and management positions. Since joining UNSW in 1998, he lectures and regularly
consults in the fields of communications and information systems, systems
engineering, requirements engineering, and project management. He is the author or
co-author of eleven books, three book chapters, and over one hundred technical papers
and reports.