In my last article, I explained why I don’t see any benefit in moving beyond the term “requirements” when describing the key activities performed by a business analyst. My point was that business requirements and solution requirements represent the logical progression toward establishing a solution for an identified business need. This article from Practical Analyst illustrates with a diagram such progression from problem definition to solution definition, in which the business analyst takes an active role focused on moving from an ambiguous description of a problem to establishing the scope and the requirements of its optimal solution.
Today I’m heading to the opposite direction, discussing terms frequently used in the literature I don’t particularly like to use to describe the BA work: requirements gathering, capture, elicitation, and trawling.
For a period, “requirements gathering” was the term commonly used to describe the task of identifying requirements. Arguing that defining requirements is more than simply assembling them together, many authors opted to use the expression “requirements elicitation” instead. “Elicitation” is also the term adopted by the BABOK, which provides the following definitions for the verb elicit:
1. to draw forth or bring out (something latent or potential)
2. to call forth or draw out (as information or a response)
It’s common to see specialists disagreeing with the use of words like gather, capture and elicit to describe the process of looking for requirements, claiming that these words assume that the requirements already exist, even if in a concealed or latent manner, and simply need to be exposed. Robertson and Robertson, the authors of Mastering the Requirements Process, proposed the term “trawling”, using the analogy of fishing, “running a net” through the organization to “trap” as many requirements as possible.
Even though now favored by writers such as Mike Cohn, author of User Stories Applied: For Agile Software Requirements, to me the verb “trawl” is even less ideal than “elicit”, as it suffers from the same problem associated with “gather”: it presumes that the requirements are out there, in the solution space, waiting to be captured.
Admittedly, the words elicit and trawl have positive attributes. The former has the advantage of highlighting the need to actively engage the stakeholders in defining requirements. The latter provides a useful metaphor that emphasizes the fact that skill is an important factor in identifying requirements (like a person who fishes by trawling, an unskilled requirements trawler may waste time and miss requirements looking for them in the wrong places, or using the wrong techniques).
Both become unsatisfactory, though, when we think in terms of conscious, unconscious and undreamed of requirements.
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.
Which term, then, would be more appropriate to describe the tasks performed by business analysts to define requirements? What we are looking for is a term that can be used to describe the process of not only eliciting conscious requirements, but also figuring out the unconscious and undreamed of ones.
“Requirements elicitation” is a term that could fit the bill, if interpreted in the sense that some requirements being elicited may be, indeed, “something potential”, as mentioned in the definition of the word elicit. It seems to me that the dislike for the expression “requirements elicitation” comes from the fact it is not easily associated with devising requirements that are possible but not yet in existence–the unconscious or undreamed of requirements.
I would be interested in the suggestions others may have, but the word I have been favoring recently is discover, for which the Webster Dictionary has the following definitions:
1. to make known or visible
2. to obtain sight or knowledge of for the first time
While the first description is similar to the ones associated with word elicit, the second, “to obtain sight or knowledge of for the first time”, helps clarify an important dimension of the requirements definition process: identifying requirements that may need to be invented, formed in the mind by new combinations or applications of ideas or principles, or devised through the use of investigation, imagination or ingenuous thinking. Seen in this light, the word discovery presents a more comprehensive view of the requirements process, emphasizing how such process typically demands from the analyst more than simply “bringing out”, “making known”, or “capturing” requirements.
What do you think? Are you comfortable with the expression “requirements elicitation” or “trawling for requirements”, or do you also believe that there must be a better term to describe the key task of defining requirements?