<< Back to Requirements Management Home
Requirements Gathering / Capture / Elicitation
This section outlines some of key techniques and methods that can be employed for gathering and capturing
requirements on a project. It includes suggestions and ideas for ways to best capture the different
types of requirement (functional, system, technical, etc.) during the gathering process.
What is Requirements Elicitation?
Requirements elicitation (also known as Requirements Gathering or Capture) is the process of
generating a list of requirements (functional, system, technical, etc.) from the various stakeholders
(customers, users, vendors, IT staff, etc.) that will be used as the basis for the formal
Requirements Definition.
The process is not as straightforward as just asking the stakeholders what they want they
system to do, as in many cases, they are not aware of all the possibilities that exist, and may
be limited by their immersion in the current state. For example asking people in the 19th Century
for their requirements for a self-propelled vehicle, would have just resulted in the specification for
a faster horse-drawn carriage rather than an automobile. Beware the old adage, "it's everything
I asked for, but not what I need"!
What Techniques Can Be Used?
-
Interviews - These are an invaluable tool at the beginning of the process for
getting background information on the business problems and understanding a current-world
perspective of what the system being proposed needs to do. You need to make sure that
your interviews cover a diverse cross-section of different stakeholders, so that the
requirements are not skewed towards one particular function or area.
-
Questionnaires - One of the challenges with interviews is that you will only
get the information that the person is consciously aware of. Sometimes there are latent
requirements and features that are better obtained through questionnaires. By using
carefully chosen, probing questions (based on the information captured in prior
interviews), you can drill-down on specific areas that the stakeholders don't know
are important, but can be critical to the eventual design of the system.
-
User Observation - One of the best ways to determine the features of a system,
that does not result in "paving the cowpath" (i.e. building a slightly improved version
of the current state) is to observe users actually performing their daily tasks, and
ideally recording the actions and activities that take place. By understanding the
holistic context of how they perform the tasks, you can write requirements that will
reinvent the processes rather than just automating them, and will ensure that usability
is paramount.
-
Workshops - Once you have the broad set of potential requirements defined,
you will need to reconcile divergent opinions and contrasting views to ensure that
the system will meet the needs of all users and not just the most vocal group.
Workshows are a crucial tool that can be used to validate the initial requirements,
generate additional detail, gain consensus and capture the constraining assumptions.
-
Brainstorming - This is a powerful activity, which can be performed either
in the context of a workshow or on its own. By considering different parts of the system
and considering 'what-if' scenarios, or 'blue-sky' ideas, you can break out of the
context of the current-state and consider visionary ideas for the future. Tools
such as whiteboards or mind-mapping software can be very helpful in this phase.
-
Role Playing - In situations where the requirements depend heavily on different
types of user, formal role-playing (where different people take on the roles of different
users in the system/process) can be a good way of understanding how the different parts
of the system need to work to support the integrated processes (e.g in an ERP system).
-
Use Cases & Scenarios - Once you have the high-level functional requirements defined,
it is useful to develop different use-cases and scenarios that
can be used to validate the functionality in different situations, and to discover any special
exception or boundary cases that need to be considered.
-
Prototyping - There is truth to the saying "I don't know what I want, but I know
that I don't want that!". Often stakeholders won't have a clear idea about what the
requirements are, but if you put together several different prototypes of what the
future could be, they will know which parts they like. You can then synthesize the different
favored parts of the prototypes to reverse-engineer the requirements.
How Should the Information Be Captured?
There are many different ways to capture the information, from a simple Word document, spreadsheet
or presentation to sophisticated modelling diagrams. We recommend that the initial high-level
brainstorming and requirements discovery be done on a whiteboard to foster collaboration.
Once the initial ideas have crystallized, we recommend using a formal
Requirements Management System to record the information
from the whiteboard and drill-down the functional requirements in smaller focus-groups
to arrive at the use-cases and system requirements.
What Pitfalls Exists?
The biggest risk is that by asking existing users or stakeholders to help define the requirements,
you will get a requirements specification that is unduly
influenced by the current ways of doing business. Therefore we recommend that you ensure that sufficient
third-party research into industry-wide trends and usability research (e.g. observation) is done to
ensure that the requirements take into account future opportunities as well as current problems.