Do you refer to some of your business analysis activity as “requirements gathering”? Are you looking at BA jobs and seeing “requirements gathering” responsibilities and wondering what that looks like? And how do you reconcile this with the BABOK’s use of “Elicitation” as a knowledge area name?
Or perhaps you use the term with a well-read BA or with someone like me who happens to facilitate a course called “Essential Elicitation Skills” and they tell you “elicitation” is the better term. They might even jump down your throat and give you 20 reasons why we don’t use “gathering” anymore when it comes to requirements. (Well, not me, but those other people. I happen to be nice. :-))
But the thing is, we do use the term “requirements gathering.” It turns out we use it a lot more frequently than “elicitation”.
In this post, we’ll take a look at the difference between the terms “requirements gathering” and “elicitation,” analyze a few job postings that use each of the terms, and then I’ll provide my take on what this means for the BA job seeker.
The Dictionary Definitions
Let’s start by looking at the dictionary definitions of “gather” and “elicit”:
To bring together: collect.
To reach a conclusion often intuitively from hints or through inferences
And under the synonyms section: “Gather is the most general term for bringing or coming together from a spread-out or scattered state. Collect often implies careful selection or orderly arrangement….”
To draw forth or bring out (something latent or potential)
To call forth or draw out (as information or a response)
Which Term is “Right?”
The common argument against the use of the term “requirements gathering” is that requirements don’t just sit around waiting to be picked up and collected together. They must be drawn out by a variety of techniques that get to the true problem to be solved, stakeholder need, and requirements.
I agree with this argument, though in reviewing the definitions there is an element of “gathering” that we do as business analysts. We do bring together information from disparate sources. Some information is sitting around ready to be collected. For example,
- information that is stored in documents (such as process models or regulations),
- systems (such as business rules or as-is functionality), and
- knowledgeable requirements-oriented stakeholders who have already drawn out their own needs and are ready to tell us exactly what they need and want (they are relatively rare, but they exist).
The information that can be gathered together is part of the picture and it’s often what we do before elicitation. In fact, I would argue that it’s part of the Preparing for Elicitation knowledge area in the BABOK.
But gathering is part of what we do, it is not all-encompassing. With all the possible information gathered together, we analyze it, and then go about figuring out what’s missing. That’s where the elicitation starts. That’s when we begin to draw out what’s latent in our stakeholder’s minds. We might invest in discovering the problem to be solved, ask a series of questions, or demo a user interface prototype.
What Do the Job Postings Say?
At this point I want to come back to why I am tackling this question in the first place. Despite whatever we might want the terminology to be, the job postings tell a completely different story.
As I pointed out in my recent TechWell post, instances of “requirements gathering” outnumber instances of “elicitation” as a job requirement by a factor of about 10 to 1. That’s right.
“Requirements gathering” is listed ten times more frequently than “elicitation.”
Let’s look at some sample job qualifications. (I make no guarantee that these are representative language, just postings with the job title of “Business Analyst” that were the most current on CareerBuilder.com at the time of this post being published.)
For “requirements gathering”:
This position will be responsible for translating business requirements into software requirements and specifications; defining and owning the research process and due diligence process; designing, organizing, and leading requirements gathering sessions with internal departments;
Create business process flows, manage changes and provide subject matter expertise for requirements gathering process.
Proven experience and passion for facilitating requirements gathering sessions, designing customer facing interfaces (navigation, look, and feel) for complex web applications and websites.
Gather requirements from business units and translate those to programmers and developers
And for “elicitation”:
Demonstrated experience in Requirements elicitation, setting up and tracking of verification and validation procedures
5+ years experience in requirements elicitation through the use of application design sessions, interviews, document analysis, requirements workshops, surveys, site visits, business process descriptions, use cases, scenarios, event lists, business analysis, competitive product analysis, task and workflow analysis, and/or viewpoints.
Participate in requirement elicitation efforts, including the elicitation and mapping of the AS-IS and TO-BE processes.
Select the appropriate methods to elicit and document requirements
What This Means for BA Job Seekers
While we still have a ways to go in selling the use of the term “elicitation,” that doesn’t mean that employers expect BAs to be “gatherers.” In each of the gathering posts there were additional elicitation techniques listed, such “interviews” or “confer on business needs” or “evaluate” or “liaise” or a variety of other terms that mean elicitation.
Employers each have their own various ways of asking their business analysts to draw out what’s latent.
No matter what terms you use to talk about this part of the business analysis process, it’s important to realize that you will be responsible not just for picking up the requirements and putting them in a document. Employers do expect you to draw out the requirements using a variety of techniques and they will want to hear examples of how you’ve done this before.