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”:
Gather:
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….”
(Source:Â http://dictionary.reference.com/browse/gather)
Elicit:
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.
Well, frankly, I was just relieved that the course wasn’t called “Essential Solicitation Skills.” That would have been harder to pitch to my boss…
This is a good discussion. While I do think this kind of terminology matters in how we’re seen as BAs — mostly what I think is that the best way to make that perception clear is to do the work (whatever it’s called) really well. Anyone who’s worked with a good BA knows that person did a lot more than collect documents and take notes! But I’m not sure there’s any way you can truly understand that process until you’ve seen in action — and certainly no single word is going to capture it.
I’m an English major and I love words, especially using the right one for the right job. I think “elicitation” is accurate for at least part of what we do, but I do agree that it’s not a common term, and won’t resonate for most people.
Although I do kind of like the “magic and trickery” bit, I have to admit…
🙂
Very glad to have you as part of the course Jenn – your contributions are awesome. We are very much of the same mind. You might like this post too.
https://www.bridging-the-gap.com/the-road-to-respect-starts-with-solid-delivery/
Thanks an interesting sequence of events, Felicia. Keep us posted on how the part II of the story plays out.
Jake, you are such a word nerd! 🙂
Coming a bit late to the party, this is quite interesting for me as a BA still learning and putting my tool kit together. I am at the tail end of Laura’s Essential Elicitation Skills class, in which it is apparent that elicitation is not just grabbing items off a desk.
After reading the this blog and comments, it has become clear to me how common the term ‘requirements gathering’ is and how ‘elicitation’ is not so common. I used the term eliciation the other day at work and someone said to me ”Are you sure you didn’t make that word up?” 🙂 Somewhere along my journey I was told eliciation is pulling information that is not at the surface, rather than writing a list of items stakeholders need. I like this because it demonstrates to me the importance of BAs and the skills we posess. Call me fancy, but I like using the fancy word.
Felicia,
If you like to elicit, you might enjoy my post from some time ago. http://businessanalysisexperts.com/elicitation-is-more-than-just-a-word/
Enjoy
Tom Hathaway
If you want a really really fancy word… try “educe”. 🙂
Thanks for sharing your experience here Felicia. As BAs we definitely need to be prepared to speak to the terminology and explain it to our stakeholders. I’ll be adding a discussion of “gathering” vs “elicitation” back into the next session of the Essential Elicitation Skills course. We ended up glossing over it this time because there was so much good discussion in the first session. 🙂
Great discussion, Laura et al. I agree with most of what is posted, in particular with Wessel’s point regarding the fact that elicitation and elicit are not common words in the English language. Since I am a proponent of simplicity, I always suggest that requirements should be written in no more than 8th grade level terms. Based on that, I don’t think we should be describing what we do with words that are not common. Ergo, I also champion the use of the term “requirements discovery” and I have seen a growing use of that term in organizations with which I work.
If you would like some additional input into the choice of words, I posted “Do you Really Want to Elicit” at http://businessanalysisexperts.com/elicitation-is-more-than-just-a-word/ in March 2011. In the meantime, my research led to the discover that the word “elicit” comes from a Latin stem meaning “to draw forth through magic or trickery”. Sounds to me like what business analysts really do.
Tom,
This is interesting too – I saw the “magic or trickery” phrase in my research but chose not to include it as that seems to not be the kind of thing we’d want to attribute to business analysts. There should be nothing “magic” about asking good questions and getting to the root business needs/wants. And we definitely never want our stakeholders to feel tricked. But then again we are nearing Halloween here in the U.S., maybe we should further explore that angle. 🙂
For me, as a non-native English speaker, the reason for tending to use gathering in stead of elicitation is that the latter is not a real common word. To be honest the first time I read the word in the babok I had to look up the exact meaning.
A short test among some colleagues learned me that everybody can give a quit accurate definition of the word gathering, but are mostly unfamiliar with the word elicitation.
Thank you Laura for pointing out the difference between the two terms so
clearly. Together with Jacks point it really motivates me to make myself more aware when to use which term.
Thanks for starting this dialogue with the community, Laura. I think this an important point to differentiate from a practitioner’s POV.
In my tweet the other day I mentioned about how we specifically tackled the use of the word “gathering” as a dedicated topic and discussion in the CBAP prep course; to bring home the importance of elicitation as a key activity in analysis.
Requirements gathering makes it sound like we just show up and have the magnetism and charisma to gather precisely what the problem definition or stakeholder needs are.
In my opinion, the industry refers to “elicitation” as “gathering”. And gathering encompasses the process of elicitation, since it is at a higher level of abstraction and hierarchy. When they refer to “Should be adept in requirements gathering”.. from our perspective, should be able to elicit using the right technique, at the right level along with any assumptions, constraints and concerns and package them appropriately.
Another example that I could think of from medical world is, when the whole world thinks it is a sore throat, doctors see it as “Pharyngitis”. 🙂
@Jake – Great point about undermining what we do, couldn’t agree more.
@David – I can reach up 68th floor and try that. 🙂
@Aniket – I agree with you viewpoint; this is debatable indeed. We share a common ground on “gathering” being more generic.
@Yamo – interesting. My first reaction is that I would think it is the other way around… elicitation encompasses gathering. As part of my elicitation process with the business, I may gather some artifacts, but I will them work with the customer and team to elicit information – using people’s knowledge and the artifacts.
Jake – It’s interesting. As I’ve explored this further, there’s a sense that gathering involves the collecting of information, the organizing, and the specifying – sort of like gathering together requirements for implementation. Not sure that I agree that the word accurately represents that activity, but it is seen as a broader task by some.
I have a terminology fustration where everybody spends too much time using the word “Requirements” : I’d prefer people to talk much more about the ‘analysis’ as I see people focus too much on document completion and gathering/elicitation for a list: but then don’t analyse it enough or produce other artefacts as output of the analysis.
Talks back to some articles I saw about whether BAs are ‘Requirements Specification authors’ (which could still be constrained to gathering and eliciting) or are we Business Analysts?
I would say here that “gathering” is most commonly used term in the routine activities and hence we found it more frequent in the job postings. On the other hand “elicitation” seems to be a heavy word and thus people are quite skeptical to use it. The term elicit, as mentioned by you is bringing out something potential, and there are many situations when BAs don’t have to bring out or call forth some information, instead they just need to gather the information from the available resources (may be documentation, reverse engineering etc.).
Anyways I believe the topic is quite debatable and even gathering the information is not easy. But Jake’s point that “gathering” sometimes reduces the value of the activities we do is accepted.
Above all nice post Laura, it again grilled me to think about the usage of terminologies.
Thanks,
Aniket
@Aniket – there can be various items that need to be done, but if all that is needed if for someone to pickup some documents from a desk (gather), then there is no value. I would “argue” that what you are really doing is eliciting information from those documents. Unless someone else did the reverse engineering already… you have information that needs to be reverse engineered, then there is actual thinking, learning, eliciting, analyzing work to be done.
A well-articulated positioning statement on both uses. Isn’t it amazing that this still keeps cropping up, time and again?
I love Jake’s point on how the use of ‘gathering’ reduces the value of what we do.
Let’s shout it from the rooftops and hillsides, “We’re BAs and we don’t ‘gather’ we elicit”!
@David – To the Roof!!
The new PMBOK draft had ‘gathering’ in it. I did provide some comments related to changing it, some of which were accepted. Hopefully others did as well.
Many people still use the term “gather” I think it just continues to lower the bar… which is saying something (because it can be on the ground sometimes). The problem is that everyone “gathers” things – but that has nothing to do with a BA role.
Gathering information from documents? You may gather the documents – you have to elicit the information from them. Is there even any value in gathering? Very little at best. That may explain some other things as well.
Perhaps we should gather code, gather product strategies, and gather people (instead of coaching them) as well!
Perhaps saying “I go well beyond the simplicity of gathering requirements – I elicit and analyze requirements with the customer and team! This provided dramatically more value that simple requirements gathering efforts.” Then you have both SEO terms as well.
Thanks for writing this Laura! Some may think this is not a big deal, but when you self identify with something that does not appear to have value – it leads to people assuming you do not bring any value.
Maybe we should let the PMs “gather” requirements while we BAs elicit them! (I’m kidding, but only partially.)
Thanks for adding your comments here Jake. I do think it’s important to think carefully about the words we use. What struck me most about the job postings was the inclusion of different techniques – maybe we can side step the whole gathering vs. elicitation debate by drilling right into the techniques? (That’s a topic for another post, about what this means for the profession, as opposed to the aspiring BA…but I do recognize that it’s difficult to change a well-established use of terminology without changing the frame of reference.)
I once had a recruiter tell me that she never uses the term “requirements elicitation” because she confuses the words “elicit and illicit.” Apparently, she once had an embarrassing experience due to that misuse. {shrug}
Deanna,
That’s a good one! Thanks for sharing!