The most difficult part of requirements elicitation is not the act of recording what the user wants, it is the exploratory development activity of helping users figure out what they want.
Requirements elicitation is the first step in the requirements engineering process. It’s goal is to to elicit information relevant to the problem or the solution. This information will be then analysed, documented in form of requirements and associated models, validated and finally managed throughout (at least) the project life cycle.
Requirements elicitation is a highly “human-intensive” activity, which relies on the involvement of the right stakeholders. Elicitation activities are likely to intervene with requirements analysis and documentation during the requirements development process.
The quality of the elicitation phase impacts the overall quality of requirements. If we miss a stakeholder during the elicitation, we risk to miss important requirements, too. Therefore a thorough stakeholders analysis upfront contributes to a more complete requirements set at the end.
Requirements elicitation faces many problems, which could be classified into three main categories: scope, understanding and volatility.
- Not knowing what is the scope of the elicitation may result, a business analyst wastes his time on things that are not important at the end.
- Stakeholders have often incomplete understanding of their needs, or conflicting views on the problem at hand. Much of business or technical requirements is not documented anywhere—it resides in the minds of stakeholders (it’s also called tacit knowledge). During elicitation stakeholders communicate what they think should be communicated and omit facts, which they assume a Business Analist has knowledge of (also called as “knowledge taken for granted”).
- Finally the requirements evolve over time as stakeholders get more insight in what they really want.
A skilled business analyst uses a combination of requirements elicitation techniques to help him understanding the current business situation and uncover the real requirements. This section describes in the nutshell the most important requirements elicitation techniques.
The primary elicitation techniques we all use are interviews and workshops. Next to these primary techniques, some additional techniques may be used. In general we can divide elicitation techniques into two categories:
- Qualitative elicitation techniques. They help to discover the widest possible range of facts about an issue at hand. Interviews and workshops fall into this category.
- Quantitative elicitation techniques. These techniques provide further insights into the issue at hand and are concerned with volumes and frequencies (e.g. how many orders are taken, how long does it take to process them).
The list of elicitation techniques can be quite long. Therefore here are some examples of elicitation techniques:
- Qualitative elicitation techniques: observations (like formal observation, shadowing, protocol analysis, apprenticeship), prototyping, focus groups, scenario’s, card sorting, background research.
- Quantitative elicitation techniques: questionnaires, document analysis, timesheet.
Workshop is a facilitated meeting with a set of clear objectives. During a workshop a group of people engage in intensive discussion and activity in order to reach the agreed objectives.
An interview is one of the most popular investigation technique used by Business Analysts. It is a qualitative investigation technique where the interviewer formally or informally asks questions to a stakeholder to obtain answers that will be used to create formal requirements.
Questionnaire is a useful technique to investigate trends, shifts in user attitudes and opinion, user satisfaction with products and/ or services, and priorities and preferences.