What is Requirement Elicitation? Is it the same as Requirement Gathering?

Requirement elicitation is the practice of discovering the requirements of a system from its intended users, customers, and other stakeholders through careful analysis of scenarios.Though the practice is also sometimes referred to as “requirement gathering”, they are not the same.

Gathering simply means collecting something that is already laid out. It assumes that the requirements already exist in plain sight and are ready to be acted upon. “Elicitation” means collecting and understanding data and carefully analyzing that data to draw out useful information. Requirements need to be generated (and not gathered) through a careful elicitation process.

Gathering requirements nullifies the BA’s role as a specialist or a consultant as it implies just taking orders, orders that might or might not be the best possible solution, or in some cases, a solution at all.

There is a huge difference between wants and needs. A BA should focus on the latter as wants are mostly based upon opinions, biases, tech preferences etc. 

During the elicitation process, business analysts work directly with the client , stakeholders or focus groups, collecting and studying their needs and assumptions, which they will then use to draw out requirements. The scope, budget, and time estimation for a project fully depend on how complete, clear, and relevant the requirements are. As the saying goes- ‘Do not treat the symptoms, address the problem’. A BA should identify the needs before designing a solution.

Before we get into the process of drawing out requirements, let’s understand their types. Requirements can be broadly classified into 3 types-

Functional: What actions do the user need to undertake to reach their objective? What is involved to get to the objective (features)?

Non-Functional/software: Constraints that have to be kept in mind and that the site/app has to perform with.

Business Requirements: These are the dynamic rules like formulas for various calculations, business definitions, legal obligations etc that define the business and have to be complied with.

So now that we know what requirements are, how do we get to them? Here are a few simple steps-

1. Explore User journey

• Interview stakeholders/focus groups and jot down their journey. Pay attention to the process they go through to fulfill a need. 
• Avoid nudging the discussion in biased directions. Let them speak freely.
• Identify different types of the said scenarios. Group them together or separate them based on the need they fulfil.
• Develop each scenario further based on the motivations behind them, data exchanged, design principles, etc.
• List down user persona and the journey they undergo to fulfil a scenario.
• Prepare a visual representation and communicate them with stakeholders using storyboards/high-level diagrams.

2. Draw out requirements from the scenario

• Once the scenarios and personas are approved, draw out supporting requirements for each scenario.
• You may sort the requirements as Functional, non-functional & business requirements for further development.

Eg of a scenario: Priya conveys the requirements to the developers in the form of user stories which contain a detailed description, as well as supporting images. She mostly does this from her phone and sometimes from laptop.

Requirements from the scenario:

• Ability to enter,edit and save text.
• Ability to upload, view and delete images.
• See a list of such stories.
• UI-UX suitable for portable devices as well as desktop/laptop.
• Multiple user access to a single dashboard.

3. Prioritize the requirements and design appropriate solutions that complies with all the constraints while answering the needs

• Use MoSCoW or CoD or any other suitable technique to sort the requirements in order of importance.
• Remember that requirements are not features. Requirements are just needs that call for a solution. This solution will develop into features.
• Design the Minimum Viable Product first and iterate on that. Have a very defined scope to avoid perpetual beta.

To sum it up, requirement elicitation requires careful analysis of user scenarios to draw out requirements. Keep in mind that there are things that people think they need, things people actually need and things that people don’t even know that they need. As a BA, the job is to provide the best possible solution keeping in mind the needs of stakeholders and business as well as the constraints involved.

---