If you’re sitting down to write a business analysis approach document, update your CV, or explain your methodology to a new client, and you find yourself pausing over whether to say requirement elicitation or requirement gathering, this article is for you. The question of requirement elicitation vs requirement gathering trips up even experienced practitioners, and it matters more than most people think. The term you choose signals something about how you understand the BA role itself.
I’ll give you the short answer upfront: they are not the same thing, even though they are used interchangeably in most organisations, most job postings, and a surprising number of BA textbooks. The distinction is subtle but worth owning, particularly if you work in an environment where requirements quality is scrutinised, or where you need to build credibility with a senior stakeholder audience quickly.
The Actual Difference, Without the Textbook Waffle
Gathering implies that requirements exist somewhere, fully formed, waiting to be collected. You go out, you find them, you bring them back. It’s a passive metaphor. The image is of picking apples that are already on the tree.
Elicitation implies that requirements need to be drawn out, often from stakeholders who don’t yet know what they need, can’t articulate it clearly, or hold conflicting views. You are not collecting something that exists. You are actively helping to surface, shape, and sometimes create clarity where none existed before. The image is closer to a skilled interviewer helping someone articulate a problem they’ve never put into words.
That difference matters enormously in practice. When I worked on a large-scale service redesign for a public sector body (Organisation A), the project sponsor genuinely believed that running three workshops would produce a complete set of requirements. He had a gathering mindset. What actually happened was that stakeholders across four directorates had fundamentally different assumptions about what the new service needed to do. The requirements didn’t exist to be collected. They had to be negotiated, challenged, and constructed over eight weeks of structured elicitation. If I’d treated it as a gathering exercise, I’d have left that first workshop with a contradictory list and called it done.
Why Both Terms Persist
The honest reason both terms survive is that neither professional bodies nor hiring managers have settled on one. BABOK (the Business Analysis Body of Knowledge published by IIBA) uses elicitation consistently and treats it as an active, collaborative discipline. PMI’s materials tend to blend the terms. In practice, most job descriptions, project plans, and internal BA frameworks use gathering because it’s shorter, more familiar, and doesn’t require anyone to know the difference.
This means you will encounter both in your working life. Correcting a project manager who says “go and gather the requirements” in a kick-off meeting is not a good use of your social capital. But in the documents you own, and in interviews where you’re explaining your approach, using elicitation accurately and confidently is worth doing.
Comparing the Two Terms Side by Side
| Aspect | Requirement Gathering | Requirement Elicitation |
|---|---|---|
| Underlying assumption | Requirements already exist and need to be found | Requirements are latent and need to be drawn out |
| BA’s role | Collector or recorder | Active facilitator and analyst |
| Stakeholder’s role | Information provider | Co-creator of clarity |
| Typical techniques associated | Surveys, document review, structured interviews with fixed question sets | Workshops, observation, prototyping, contextual inquiry, open-ended interviews |
| Risk if misapplied | Captures stated wants rather than underlying needs | Can over-complicate simple, well-understood requirements |
| Preferred in BABOK? | No | Yes |
| Common in job postings? | Very common | Common in specialist BA roles and senior positions |
When Gathering Is Actually the Right Word
There are situations where the gathering framing is accurate and appropriate. If you’re onboarding to an existing system with documented business rules, reading legacy specifications, pulling data from a requirements management tool, or reviewing regulatory obligations, you genuinely are gathering. The information exists. Your job is to locate it, assess it, and consolidate it. Calling that elicitation would be overstating the interpretive work involved.
I’ve written before about the value of desktop analysis before any stakeholder conversation. That phase is essentially gathering. You’re not eliciting anything from a policy document. The distinction becomes important when you move from desk research into live stakeholder engagement.
A Worked Example: Where the Distinction Had Real Consequences
On Project X, a technology modernisation programme for a mid-sized financial services firm (Organisation B), I was brought in three weeks after a previous analyst had run what the project plan described as a “requirements gathering exercise.” She had produced a twelve-page list of requirements. The development team had started estimating against it.
The problem became apparent when I ran a two-hour workshop with the operations team, who hadn’t been consulted. Their understanding of the “customer onboarding capability” (to borrow the language from the capability mapping work the firm had done) was fundamentally different from the front-office view that had dominated the earlier sessions. The original list captured what the sales team wanted. The operations team needed something that integrated with a completely different part of the process.
The operations manager was frustrated, and understandably so. She pushed back hard, questioning why she hadn’t been involved earlier and whether the whole requirements list needed to be thrown out. We didn’t throw it out, but we did have to revisit approximately a third of the requirements and renegotiate scope with the project sponsor. That renegotiation took two weeks and nearly cost the project its business sponsor’s confidence.
The root cause was a gathering mindset applied to a situation that demanded elicitation. The previous analyst had treated stakeholders as sources of pre-existing requirements rather than as people whose needs had to be actively explored, challenged, and reconciled. If you’d like to see how structured questions during a project kick-off can prevent this kind of gap from forming, the article on kick-off meeting questions is worth reading alongside this one.
How to Use Each Term in Practice
- In a business analysis approach document, use elicitation when describing your planned stakeholder engagement activities, and specify your techniques. This signals that you understand requirements are constructed, not just collected.
- In a CV or interview, use elicitation deliberately and be ready to explain what it means. If an interviewer uses gathering, mirror their language conversationally but use elicitation in your written submissions.
- In project plans and status reports written for non-BA audiences, use whichever term your audience is comfortable with. Winning the terminology argument with a project manager mid-delivery serves nobody.
- When describing desk research or document review, gathering is the accurate term and you should use it without apology.
- When presenting your methodology to a senior stakeholder or governance body, elicitation signals professional rigour. It tells the room that you understand your role involves more than taking notes.
- In templates and reusable artefacts, standardise on elicitation so that your documentation is consistent with BABOK and with the vocabulary used in most BA certification frameworks.
What This Means for Your Documents Right Now
If you’re partway through writing a business analysis approach document, go back and check which term you’ve used. If you’ve written “requirements gathering sessions” to describe a series of stakeholder workshops, consider whether elicitation is more accurate. Workshops are an elicitation technique, not a gathering one. They are designed to surface, challenge, and refine, not simply to record what people already know they want.
If you’re writing a CV or preparing for an interview, the same logic applies. The full range of elicitation techniques available to a BA, from observation and prototyping to structured workshops and contextual inquiry, is much broader than the word gathering implies. Using the right term in your career materials signals that you understand the depth of the discipline.
The Bottom Line on Which Term to Use
Most practitioners will use these terms interchangeably for their entire career without serious consequence. But if you want your documents to be precise, your interviews to be credible, and your approach to requirements to reflect what the job actually involves, elicitation is the right word for the active, facilitative, interpretive work that sits at the heart of business analysis. Gathering is fine for what you do at your desk before you talk to anyone. The moment you’re in a room with stakeholders who don’t yet know what they need, you’re eliciting, and that distinction is worth owning.
Frequently asked questions
What is the difference between requirement elicitation and requirement gathering?
Requirement gathering assumes that requirements already exist and simply need to be collected from stakeholders. Requirement elicitation recognises that requirements are often latent, unclear, or conflicting and must be actively drawn out through facilitation, questioning, and analysis. Elicitation is the more accurate term for the active work a BA does with stakeholders.
Is requirement elicitation or requirement gathering the correct term to use?
Elicitation is the preferred term in professional BA frameworks, particularly BABOK published by IIBA. Gathering is more common in everyday project language and job postings but implies a passive role that undersells the analytical work involved. Use elicitation in formal BA documents and professional contexts.
Can I use requirement gathering and requirement elicitation interchangeably?
In informal conversation and most project environments, the terms are used interchangeably without causing problems. In formal BA documents, approach papers, and professional interviews, it is worth using elicitation accurately since it signals a deeper understanding of the BA role. Gathering is appropriate when describing desk research or document review.
Which term do employers use in BA job postings?
Most job postings use requirement gathering because it is more widely understood by hiring managers who are not BA specialists. Senior and specialist BA roles are more likely to use elicitation. You can use gathering in your CV to match job posting language but should be comfortable explaining elicitation in interviews.
What are examples of requirement elicitation techniques?
Common elicitation techniques include facilitated workshops, one-to-one interviews with open-ended questions, observation of work in context, prototyping to surface reactions, and focus groups. These are distinct from gathering activities such as reviewing existing documentation, analysing legacy systems, or completing structured surveys where the information largely already exists.
Try Ash, Your Virtual BA
If you’re working through a requirements elicitation approach right now and want support structuring your questions, choosing the right techniques for your stakeholders, or drafting the elicitation section of your BA approach document, Ash can walk you through it. Ash is trained in BA methodology and knows the difference between a gathering mindset and a genuine elicitation approach, so the guidance you get is grounded in real practice, not generic prompts. Try Ash Virtual BA and get your elicitation plan moving today.
Further reading
- What a project manager really needs to know about requirements
- Requirements improved project performance
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.