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”!
Requirements Gathering Techniques
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.
Gathering Information
There are many different ways to capture the information, from a simple Word document, spreadsheet or presentation to sophisticated modeling 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.
Precautions
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.
