People don’t simply “gather” requirements

Requirements aren’t lying around waiting for the business analyst to collect them. Requirements elicitation is a more accurate term.

Karl Wiegers
Analyst’s corner
Published in
5 min readJan 9

--

A photo of a woman’s hand reaching down to pick some pretty flowers.
Photo by Cameron Ahlvers on Unsplash

People often speak of gathering requirements on a software project, but this conveys an inaccurate impression. The word gathering suggests that the requirements are lying around out there somewhere, just waiting for the business analyst (BA) or product owner to collect them. When I hear someone say “gathering requirements,” I conjure a mental image of picking flowers or hunting for Easter eggs. It’s not that simple.

Gathering versus elicitation

Requirements rarely exist fully formed in users’ minds, ready to be passed to a BA or development team on demand. Assembling requirements does involve some collection, but it also involves discovery and invention. The term requirements elicitation more accurately conveys how software people collaborate with stakeholders to explore a future solution’s capabilities.

A dictionary definition of elicitation means calling forth, drawing out, or provoking. (BAs aren’t trying to provoke their stakeholders, though that happens inadvertently sometimes.) A big part of the BA’s function during elicitation is to ask questions to stimulate the stakeholders’ thinking and get beyond the superficial and obvious.

The least useful questions to ask when exploring requirements are “What do you want?” and “What are your requirements?” Such vague questions trigger a lot of random — yet important — input, blended with extraneous information and seasoned with unstated assumptions. A BA is not a mere scribe, writing down whatever stakeholders tell them. A skillful BA facilitates elicitation conversations, guiding the participants to discover pertinent knowledge in a structured fashion.

When to elicit requirements

Elicitation demands an iterative and incremental approach with cycles of refinement, clarification, and adjustment. The discussions could move from fuzzy, high-level concepts into details, or they could begin with specific functionality fragments that the BA must then synthesize to a higher level of abstraction. Information…

--

--

Karl Wiegers
Analyst’s corner

Author of 14 books, mostly on software. PhD in organic chemistry. Guitars, wine, and military history fill the voids. karlwiegers.com and processimpact.com