It's hard to imagine meeting an experienced Business Analyst who's never elicited, analysed and documented requirements. Yet the term has somehow become linked to outdated approaches involving piles of paperwork, with BAs just recording the requirements as they are described by stakeholders. Some practitioners feel even mentioning the 'R' word could be seen as 'anti-agile' or 'pushing a waterfall approach onto a project.' 

This whole perception could not be further from the truth. Requirements engineering is a valuable tool in the hands of the expert Business Analyst. It involves drilling down past surface discussion to uncover tacit knowledge. It requires expertise far beyond just recording what stakeholders say.

Requirements can exist at different levels of abstraction, from high-level statements of business intent to detailed statements that specify exactly what a solution needs to do. 

Even when stakeholders seem to agree, there can be unexplored areas where their views are completely contradictory, which can then become an issue when the solution launches. 

User Stories as Requirements

Many agile projects express statements of need as 'user stories'. In a high-performing agile team, user stories are acting as a requirements artefacts whether or not anyone refers to them in those terms. 

A single user story articulated as an isolated "As a…." statement, is not a well-formed requirement that communicates users', stakeholders' and wider organisations' needs effectively. However, it's an important part of the picture, especially when elaborated and testable. How much should be written on a user story card and how much should be discussed verbally will depend on the specific business, project and product contexts. Specific details may be discussed via an informal conversation and added to the story card, but more usually acceptance criteria will be added. Additionally, other artefacts can be cross-referenced with the story (prototypes, user journeys or process models can be useful visualisations). 

While it might not be popular to make the connection between user stories and requirements, surely they are fulfilling exactly the same purpose - communicating a need amongst a group of diverse stakeholders.

Reinventing the 'R' Word

Requirements engineering (at various levels of abstraction) is a core component of business analysis. This is true whatever the project, or the product development lifecycle. Teams willing to embrace effective requirements practices, adapting them to their context, will achieve better outcomes.

It's time to dispel those requirements myths, and give the 'R' word the respect and attention it deserves.

Photo by Caleb Jones on Unsplash