Have you ever thought about how experts know what a computer program should do? It’s a bit like doing research! In this article, we explore how planning and carrying out requirement activities, known as elicitation, are similar to a research process. Both need careful planning, observation, and analysis. Read more to see how Eliciting Requirements Doing Research helps us discover what users really need.
What Is Requirements Elicitation?
I use requirements elicitation to discover and understand what stakeholders need from a system.
However, those needs rarely arrive as complete requirements. Stakeholders may describe problems, goals, expectations, constraints, or possible solutions. In addition, they may leave important information unstated because they consider it obvious.
Therefore, I investigate the situation systematically.
For example, I use interviews, workshops, observation, document analysis, existing systems, and prototypes. I then compare what I learn from these different sources.
I do not use requirements elicitation to collect ready-made answers; I use it to develop a reliable understanding of the problem and its context.
This characteristic creates a strong connection between requirements elicitation and research.
Just like research uncovers hidden truths, elicitation reveals the real needs behind every successful tech project. Understanding this connection helps us build systems that truly solve problems, not just meet assumptions. To explore this fascinating link further, click to read Understanding the Importance of Requirements Elicitation in Tech Projects.
Why Elicitation Resembles Research
Research often starts with incomplete knowledge. I may know the general subject, but I do not yet know every relevant fact or relationship.
Requirements elicitation starts in a similar way.
At the beginning, I may understand the business goal but not the detailed user needs. Alternatively, I may understand the existing system but not why stakeholders want to change it.
Therefore, I begin with questions.
I identify what I already know. Then I identify what remains unclear. Based on this distinction, I decide where I need more information.
This process resembles research because both activities involve:
- defining questions
- examining assumptions
- selecting suitable methods
- gathering information
- comparing evidence
- interpreting findings
- refining the original understanding
Both research and requirements elicitation reduce uncertainty through structured investigation.
The goal differs, however. Research usually aims to create or test knowledge. In requirements engineering, I investigate a situation so that I can define and support an appropriate system or change.
I Start With Questions and Assumptions
At the beginning of elicitation, I rarely know enough to create a complete picture.
Therefore, I make my initial assumptions visible.
For example, I may assume that users need a particular feature because an existing process causes delays. However, an interview may reveal that the real problem comes from missing information rather than missing functionality.
In that case, I revise my understanding.
This is important because an assumption can easily turn into an incorrect requirement if nobody challenges it.
Therefore, I treat assumptions as starting points for investigation rather than facts.
I use questions to test what I think I know before I turn that knowledge into requirements.
This approach helps me distinguish evidence from interpretation.
I Plan the Investigation Without Pretending to Know Everything
Research needs planning. Requirements elicitation does as well.
I define the purpose of the elicitation. Then I identify relevant stakeholders, information sources, techniques, and important topics. I can also plan workshops, interviews, reviews, and analysis activities.
However, I avoid planning every detail too early.
The reason is simple: elicitation exists because important information remains unknown.
For example, one interview may reveal a previously unknown stakeholder. A process analysis may expose an external system that nobody mentioned. Likewise, a workshop may uncover a conflict that requires additional investigation.
Therefore, my plan must allow change.
A useful elicitation plan gives me direction while leaving enough flexibility to respond to new knowledge.
This principle does not mean that I work without structure. Instead, I update the structure when evidence shows that I should.
I Gather Evidence From Different Sources
One source rarely gives me the complete picture.
A manager may explain the business objective. Users can describe their daily work. Existing documentation may contain formal rules. Meanwhile, observation may show that actual practice differs from the documented process.
Therefore, I compare information from multiple sources.
For example, I can combine:
- stakeholder interviews
- collaborative workshops
- workplace observation
- process documentation
- regulations and contracts
- existing software
- support tickets
- reports and data
- prototypes
This comparison helps me identify gaps and contradictions.
If several independent sources support the same conclusion, my confidence increases. However, if they disagree, I investigate the reason.
This is another clear similarity with research.
I Analyze Instead of Simply Recording
Information becomes useful only after I analyze it.
Therefore, I ask what each finding means for the system.
I look for goals, needs, constraints, dependencies, business rules, exceptions, and conflicts. In addition, I examine whether a stakeholder has described a requirement or merely suggested a possible solution.
For example, a stakeholder may ask for an additional approval screen. Further investigation may reveal that the actual need is to prevent unauthorized decisions.
Once I understand that need, I can discuss several ways to satisfy it.
Good elicitation separates the underlying need from the first solution that comes to mind.
This analysis protects the project from premature design decisions.
New Findings Change My Understanding
Elicitation creates knowledge progressively.
Therefore, new findings can confirm my initial understanding. However, they can also challenge it.
I may discover that a requirement is unnecessary. Another requirement may become more important. I may identify a new dependency or stakeholder. In addition, a previously simple requirement may become more complex after I examine exceptions.
I then update my questions, models, requirements, and elicitation activities.
This iterative refinement does not indicate poor planning. Instead, it shows that the investigation produces useful information.
I expect my understanding to change during elicitation because learning is one of the main purposes of the activity.
Iterative Development Supports This Approach
Iterative and agile development approaches fit well with this research-like view of elicitation.
I do not always need to discover every requirement before development starts. Instead, I can explore important needs, develop an initial solution, gather feedback, and refine my understanding.
For example, a prototype can expose usability needs that stakeholders could not describe beforehand. Similarly, an early increment may reveal assumptions about business processes or interfaces.
Therefore, implementation and feedback can also become sources of knowledge.
However, iteration does not remove the need for requirements engineering. It changes when and how I perform it.
I still need clear questions, relevant stakeholders, analysis, validation, and controlled decisions.
Where the Research Comparison Has Limits
I find the research analogy useful, but I do not treat both activities as identical.
In requirements engineering, I normally work toward a practical decision or system change. I must consider costs, schedules, organizational constraints, technical feasibility, and stakeholder priorities.
In addition, stakeholders do not merely provide research data. They often participate directly in decisions about the future system.
Therefore, elicitation combines investigation with negotiation and decision-making.
The analogy remains useful because it reminds me not to assume that requirements already exist in a complete form and only need documentation.
Conclusion
I approach requirements elicitation as a disciplined learning process.
I begin with incomplete knowledge. Therefore, I formulate questions and identify assumptions. Next, I select suitable sources and elicitation techniques. I analyze what I discover and compare different perspectives. Finally, I update my understanding when new evidence appears.
Eliciting requirements resembles research because both activities transform uncertainty into better-founded knowledge through systematic inquiry.
This mindset helps me avoid premature conclusions. More importantly, it helps me define requirements that reflect real needs rather than untested assumptions.
Discover the Value of Requirements Engineering
Read the main article Requirements Engineering to get a clear and practical overview of this essential field. It explains the key ideas, main tasks, and benefits of working with precise requirements. As a result, you can understand how clear requirements help software teams stay aligned, make better decisions, and deliver stronger solutions.
Credits: Photo by Mikhail Nilov from Pexels