Requirements Gathering vs. Elicitation
I feel like I’ve been living in a cave of terminology. For the last three years, I’ve been using elicitation to talk about the activities business analysts participate in to discover information related to requirements. But lately, I’ve been asked over and over again about this task called requirements gathering.
Job seekers ask: “How do I answer questions about what I’ve done to gather requirements?” Course participants ask: “How can I get better at gathering requirements from my stakeholders?”
I don’t blame them. While mature business analysis professionals and organizations have adopted elicitation as a preferred term, the business analyst job market has not gotten the memo.
Did you know that requirements gathering as a job requirement outpaces elicitation on the major job boards by a factor of nearly 10 to 1?
On October 4, 2012, I ran a test at CareerBuilder.com. A search for “requirements gathering” (in quotes to only pick up instances of the phrase) returned 1,327 jobs. Elicitation returned only 151. Searches on Monster.com and Dice.com yielded results in similar proportions.
As Adriana Beal so rightly pointed out a full two years ago, business analysts don’t "gather” requirements. Requirements don’t sit on bushes waiting to be plucked like berries. Wouldn’t it be nice if they did? Maybe. But then what would be the fun of being a business analyst?
Adriana actually wants to take our preferred language several steps further and discard elicitation in favor of discovery. She wrote:
Conscious requirements are those which one or more stakeholders are aware of, and probably part of the reason for building the solution in the first place. There are other requirements, however, referred to as unconscious and/or undreamed of requirements, that may remain forgotten, overlooked, or simply unimagined until stakeholders start to use the system and experience the need—unless a skilled business analyst is successful in identifying them during the requirements process.
My guess is that those job postings looking for experts in requirements gathering are not looking for professionals who can write down what they are told or pluck the requirements from stakeholders like berries from a bush. They are looking for talented professionals who know how to root out the true business and problem to be solved, understand the current organizational and technological context, and discover both the conscious requirements and the unconscious or undreamed of requirements that no stakeholder ever thinks to communicate to the business analyst.
While our terminology is out-of-date, our expectations of what makes a great business analyst aren’t.
