Why Business Analysts Don't Elicit Requirements
In “Requirements Gathering vs. Elicitation,” I provided some context as to why requirements gathering is not such a good term to use to talk about the process of discovering information related to requirements from our project stakeholders.
I would like to point out that requirements elicitation, while better, is also misleading. In this case I’m talking about the phrase requirements elicitation and not the word elicitation. Why? Because we don’t actually elicit requirements.
In full disclosure, I must admit that I am 100 percent guilty of using the term requirements elicitation—it’s littered through my old blog posts. But if you refer to the BABOK Guide, you’ll find that the BA Knowledge area is called simply “Elicitation." This is an important distinction. Let’s look at why it matters.
When is the last time you sat down and had a productive conversation in requirements speak? It’s pretty rare, right? It’s simply untrue that a business analyst can sit down with a stakeholder and ask questions that lead directly to the requirements.
No, the business analyst elicits information from the stakeholders about their needs and wants, probing more and more deeply until they get to the root of it. Any given piece of information discovered through this probing might fall into the bucket of risk, benefit, problem, issue, potential requirement, task, or just plain noise.
The business analyst sorts through all of this information to discover the actual requirements and then proceeds through a series of analysis and validation steps to align everyone involved around what the requirements actually are.
The business analyst then applies analysis to categorize that information and drafts a set of easy-to-consume requirements specifications that are then reviewed and validated. At that point in the process (of which we might go through several iterations), we might finally have a few brief conversations or requirements walk-throughs in “requirements speak.” But at that point the difficult work is done, and we’re crossing our T’s and dotting our I’s.
So no, we don’t gather requirements, but we don’t elicit them either. As business analysts, we have conversations with stakeholders to understand their needs and wants, and this information leads us in the direction of identifying the requirements.
