CAPTURING REQUIREMENTS
Problems can arise when a system is introduced without a full understanding of all the people
who will be affected by it. But how can we better understand and support complex organizational
structures, workgroups and potentially conflicting stakeholder needs? We begin by capturing and
analyzing requirements, but we need to do this within the work context, taking account of the
complex mix of concerns felt by different stakeholders and the structures and processes
operating in the workgroups. Here we consider participatory design which is aimed at
understanding the reality of work contexts and the perspectives of different stakeholders. It
recognizes that technology can be successfully deployed only if it is done with an understanding
of the context of use.
WHO ARE STAKEHOLDERS
Understanding stakeholders is key to many of the approaches to requirements capture, since in an
organizational setting it is not simply the end-user who is affected by the introduction of new
technology. Imagine that a new billing system is to be introduced by a local gas supplier. Who will
be affected by this decision? Obviously, the people who are responsible for producing and sending
out bills – they will be the ones using the system directly. But where do they get the information
from to produce the bills? To whom do they send the bills? Who determines the level of charging
and on what grounds? Who stands to make a profit from increased revenue? Who will suffer if
customers choose to switch supplier due to the improved service? Meter readers, customers,
managers, regulators, shareholders and competitors are all stakeholders in the system. We need
approaches that will capture the complexity of their concerns, which may be in conflict with each
other.
A stakeholder, therefore, can be defined as anyone who is affected by the success or failure of
the system.
CATEGORIES OF STAKEHOLDERS
Primary stakeholders are people who actually use the system – the end-users.
Secondary stakeholders are people who do not directly use the system, but receive output from it
or provide input to it (for example, someone who receives a report produced by the system).
Tertiary stakeholders are people who do not fall into either of the first two categories but who are
directly affected by the success or failure of the system (for example, a director whose profits
increase or decrease depending on the success of the system).
Facilitating stakeholders are people who are involved with the design, development and
maintenance of the system.
The aim of the design team is to meet the needs of as many stakeholders as possible. However, the
reality is that usually stakeholder needs are in conflict with each other. As a general rule, the
priority of stakeholder needs diminishes as you go down the categories. So primary stakeholders
usually take priority over the others. However, this is not always the case. Imagine designing the
control panel of a hospital life support machine. The primary stakeholders will be medical staff
monitoring a patient’s condition. But who, in fact, has the greatest interest in this system working?
