What Is a Requirement?
Let's consider the definition of a requirement. This is not a topic without adequate discussion, that’s for sure! But one of my most trusted business analysis collaborators, Adriana Beal, recently put forward a thoughtful synopsis defining a requirement.
According to Adriana: A requirement is a description of what we have to do to achieve an objective.
Derived from the IEEE definition (from which the IIBA definition, found in the Business Analysis Body of Knowledge, is also derived), Adriana’s phrasing strikes me as incredibly simple and easy to understand.
As someone who coaches new and aspiring business analysts, this is incredibly important. Let me explain. Recently one of my course participants asked me: "I need to write a requirements specification. The problem I’m facing is that there are no solution requirements. What do I include in my specification?"
Assuming that “solution” was being used to refer to “software” (which it was), my answer included a detailed description of how we can write requirements that are not just about what the software needs to do, but also what the business needs to do to make change happen.
Very often, new business analysts are aware of the formal definitions but find themselves uncertain about how to apply them in the real world of their project work. Or, having business analysis experience that is constrained to one particular type of project, they’ve created an operating definitions of terms like requirement that are not easily extended to a new project context.
While my advice has always been to start with your stakeholders, as they will tell you (directly or indirectly) what they need to see in your documentation, it’s equally important to have a definition in mind that can be easily recalled and referenced.
Thank you, Adriana, for a simple definition of the term requirement that any project professional should be able to understand.
