Introduction
Here in the blog we will discuss about requirement gathering vs elicitation. Requirements gathering and elicitation are fundamental processes in the field of software development. It is a base on which software projects are built. Here we will discuss requirements gathering and elicitation in detail, what they are, how to perform it, and why they are important. Software requirement elicitation helps to find the hidden Requirements of the system in Requirements analysis phase of the software development process. We will highlight how the requirements gathering differs from the elicitation process.
What are the Requirements?
Requirements are basically a comprehensive set of statements that define:
- The functionalities or features
- The constraints,
- The expectations
The software system satisfies the needs of its stakeholders. The stakeholders can include clients, users, developers, and other relevant parties.
Example
Let’s try to understand it with an example, you need a mobile app for a food delivery service. The requirements are:
- Functionality: The app should allow users to browse restaurant menus, select dishes, add them to a cart, and place orders for home delivery or pickup. It has features like a search bar to find specific dishes or restaurants.
- Constraints: App is needed for iOS as well as Android platforms. App must be GDPR compliance.
- Expectations: Easy to use and with accurate delivery time estimates, and a user-friendly interface.
These requirements is a base for developers, designers, and other stakeholders involved in building the app to make sure that it meets the needs of both clients and users.
Requirements Gathering
Requirements gathering is the first step of software development for collecting, identifying, and documenting all the requirements for a software project. Objective is to have clear understanding of what the software needs to acomplish and how it should function. This phase contains activities like:
- Stakeholder Interviews:
- Surveys and Questionnaires
- Brainstorming Sessions
- Document Review
Software Requirement Elicitation
Requirements elicitation differs from requirements gathering. Here our focus is to extract further information about the requirements from the stakeholders, or to extract such requirements that are missing from stakeholders. It is a continuous process that occurs throughout the software development lifecycle. The goal of requirements elicitation is to obtain a deeper understanding of stakeholder needs and translate them into well-defined requirements. Key techniques for requirements elicitation include:
- Prototyping
- Observations
- Workshops
Software Requirement Elicitation with Example:
Imagine you’re tasked with creating a new online shopping app. Instead of immediately listing what features it should have (e.g., search, checkout), start with “why” questions:
The first question could be Why do people shop online?
- To save time, find better deals, and access a wide range of products.
The second question could be Why is the existing app insufficient?
- Users find it slow, and they struggle to locate specific products quickly.
The third question could be Why do they abandon carts?
- High shipping costs and complicated checkout processes.
Starting with “why” helps uncover the real needs and pain points, leading to a more effective app that addresses users’ concerns and aligns with business goals.
Requirement Gathering vs Elicitation
Now you have clear understanding about the requirement gathering and elicitaion. Lets discuss about requirement gathering vs elicitaion. The process of gathering is simple but the process of elicitation is more error-prone than the gathering in software development. The elicitation process demands intensive communication with different stakeholders. It will create problems for those who consider that both processes are the same.
Gathering Mindset vs Elicitation Mindset
They are two different mindsets. Gathering Mindset” neglects the elicitation process with an assumption that the requirements are already exist, and ready for development.
The Elicitation mindset” is aware of the information that is not readily available. Using different approaches as discussed above in the blog get the hidden information to make a path for smooth development.
Requirements Elicitation is greater than Requirements Gathering
Software requirements elicitation covers more than what requirements gathering covers, as in the elicitation process, we do research about what requirements are shared with us, and about that information which is yet not discovered. Requirements elicitation is like searching for buried treasure, where you must actively dig deep to find valuable information, while requirements gathering is more like picking up seashells on the beach, where the information is readily available.
Starting with “Why” in Requirement Elicitation
The approach of conducting the said process significantly impacts the success of the projects. Unfortunately, people start asking “what” needs to be built, but there’s a smarter approach – start by asking “why” it needs to be built, which helps to know about the hidden part of the project.
Problem or Opportunity
When the process is initiated with “why”, it opens the cases that have not yet been discussed. We consider it an opportunity. It encourages stakeholders to share challenges with the current system and the potential benefits of a new one.
Broad & High-Level View
Beginning with “why” gives us a big-picture perspective. It helps us see how our project fits into the larger organization.
Alignment with Business Goals
By asking “why,” we ensure that the project aligns with broader business objectives. It improves teamwork between clients and developers.
Practical Questions to Find the “Why”
To execute or get information using the concept of “Why”, you could ask questions like below.
- What are the main issues with the current system?
- It provides insights into current problems.
- What improvements do you expect from the new system?
- It Shifts focus to potential benefits and inspires stakeholders.
- Who are the key users, and what are their needs?
- It Identifies key users and their requirements, ensuring inclusive solutions.
Role of Quality Assurance
Quality Assurance (QA) professionals play an important role in the requirements analysis or gathering process by closely collaborating with business analysts and stakeholders.
Their expertise in understanding both technical and user perspectives help to ensure that the requirements are clear, testable, and aligned with the project’s quality goals. QA professionals can identify potential issues early, suggest improvements, and ensure that the gathered requirements are feasible and well-documented.
In the requirement-gathering process, QA could search for:
- Missing information
- Conflicts in the information
- Ambiguous information
In the requirements evaluation process, QA could help the business analyst discover unknown parts of the system by using different techniques and approaches.
Key Points | Requirement Gathering vs Elicitation
We can say that requirement elicitation seems simpler process, but it is not, however, it has advantages like:
- Gathering and comprehending stakeholder and user needs.
- Incorporating research, reading, conversations, and observations.
- Discovering end users’ work processes.
- Identifying enhancements to facilitate their tasks within our system, product, or process.
Conclusion | Requirement Gathering vs Elicitation
Software Requirement Elicitation is like laying a strong foundation for a building. Making any mistake in this phase will give you tough time later in the development phase of the software. You invest a little more time and effort upfront, you can save a lot of time and trouble down the road.
With effective requirements gathering and elicitation activities, we can minimize misunderstandings, reduce project risks, and deliver software that meets stakeholders’ expectations. This process constructs the strong foundation for successful software development by aligning the project’s goals with the needs of its users and clients.
Disclaimer:
I want to acknowledge that this post is inspired by my team lead, who has shared similar blogs on LinkedIn at Tayyab Ali’s LinkedIn Profile. Any resemblance to their work is coincidental, and I do not claim sole ownership of these ideas.
