20 Tips for Effective Requirements Elicitation

July 3rd, 2015 by inflectra

Requirements Elicitation is the act of teasing the true needs from users and other stakeholders, including most departments in the development organization such as sales and training. Elicitation is not simply gathering: gathering is a passive action, whereas elicitation is proactive. It uses ideas to help users see requirements they may not have been aware of themselves. For simplicity, I shall use the term ‘requirement’ to cover all expressions of need, including User Stories and Use Cases.

In Agile processes, work is done ‘just-in-time’ so it’s important not to dig too deep during elicitation. A broad understanding of needs from all parties is more important. Once the minimal marketable functions have been identified, requirements can be selected for a release and any intermediate iterations. Only then will the requirements be fleshed out, requiring further discussion and elicitation. Breadth first, depth later.

The simplest form of elicitation is a question: “What problem are you trying to solve?” But there are so many more techniques that can be used to make elicitation more successful. A selection of techniques can be found here. In this article we are interested in making those techniques more effective. Here are some ideas for getting the best from requirements elicitation methods.

Include a cross-section of all stakeholders in the process; customers, end users, suppliers, management, quality assurance, trainers, regulators, project sponsors, operational support and domain subject matter experts. Include industry experts to avoid being limited by the thinking of existing users.
As well as group settings, meet with individuals one-on-one, especially those who might be squeezed out of group discussions by those with stronger personalities.
Listen actively. Don’t interrupt. Do not lead the witness. Paraphrase what you heard to make sure you understood.
Drill down on disagreements; a little conflict can uncover a lack of understanding.
Be that annoying kid; keep asking why? Don’t be afraid to pry!
Don’t be too quick to reign in a discussion that ends up in a perceived backwater. Again, this may unearth a disagreement about what is important.
Remember to discuss the difference between needs and wants.
Don’t forget performance, scalability, and other non-functional requirements.
Do not reject the seemingly impossible. You never know where the next big idea may come from.
If the problem is too big, the mere discussion of how to break it down can be revealing.
Use whiteboards, large flip-charts, cards and push-pins; anything that can be physically handled and manipulated. People become far more animated and involved when they can move things around or point, than they do when staring at a projected computer display. Use software to record the results, not to facilitate the elicitation.
Do not assume the meaning of institutional jargon. Try to eliminate it entirely.
Don’t be afraid to inject wild ideas and test the reaction.
Don’t organize the requirements too formally at the start, it may impose an initial solution or design and may constrain the thinking process. Use concepts such as mind-mapping to get away from the typical linear list.
When using observational techniques, remember that the simple act of observing changes the behavior of those observed.
Hypothesize conditions under which the process might break down and discuss possible resolutions.
When users try to define the solution, guide them back to the problem.
Don’t hold all elicitation meetings, one after the other. Give users time to think between meetings.
Ask for the same written user stories from multiple users. Identify and discuss any discrepancies.
When you serve a group of disparate industries, bringing them together into combined focus groups can result in unexpected ideas and new opportunities.