Over the years, the BA profession has shifted from using the term "requirements gathering" towards the preferred term "requirements elicitation". This might sound like a subtle semantic shift, but in reality this nuanced change signals an important shift in intent. It highlights the active role that BAs play in the requirements engineering lifecycle and showcases the fact that requirements work is a specialised discipline. Others might think they can pick up a pen and do requirements work, but as anyone who has actually done the job will attest to, the reality is far more complicated than that. 

Requirements Gathering

Let's examine and unpack this issue further. On the face of it "requirements gathering" might sound like an appropriate term, however upon reflection the word "gathering" has connotations that just aren't true in the vast majority of requirements-related circumstances.  It implies that requirements are lying around, in plain view, for anyone to come and collect. It implies a somewhat passive approach where requirements start their life fully formed and the BA is a scribe, dutifully noting down what their stakeholders tell them without thought or question. When was the last time you worked in a situation where the requirements were all clear, known and well-articulated from the very beginning? The answer is likely to be "never"!     

Requirements Elicitation

On the other hand, "requirements elicitation" accepts the difficult reality faced by business analysts. Collins English Dictionary defines elicit as: 

This definition fits extremely well with the challenges faced when undertaking requirements work. Requirements aren't simply there waiting for us to "gather" them as if they were products on a supermarket shelf. They often start their life as vague ideas,  expressed imprecisely by stakeholders with conflicting perspectives and priorities. Other times they will be implicit and tacit; they won't even be expressed as the expert business actor doesn't think to mention them (either because they seem so obvious, or because something has become second nature so is not consciously considered).  

In all of these situations BAs help "lure forth" and "add light" to potential requirements. A variety of elicitation techniques are utilised to achieve this: from interviews and workshops, to document analysis and record searching, right through to scenario analysis and observation, and everything in between.  Once the requirements have been articulated, then requirements analysis can take place so that they are refined, prioritised and specified to the required level of precision. 

The term "elicitation" reflects the very proactive role that BAs play and highlights that requirements work is a specialist discipline that can be tricky.  It signals this expectation to stakeholders subtly and sets the expectation that requirements work is far more than just asking people what they want.  It's very easy to accidentally slip back into old habits and to use the term "requirements gathering" - I suspect we've all done that from time to time. Yet, given the significant difference in meaning, it's important to catch this and centre back on the term "elicitation".

The BA role is active, specialised and valuable. Using terms that reinforce this is crucial in setting expectations and clearly signposting the real nature of the BA role. 

Looking to update your BA toolkit? Check out AssistKD's wide choice of business analysis courses.