Requirements mean many different things for many different people. The dictionary’s definition of a requirement is one that – I believe – we can all agree on:
“A thing that is needed or wanted”
That definition is so succinct that it is impossible to disagree with, although I’ve no doubt that some will want to. A person may require a lift, they may require food and drink; those are both needs and / or wants and align with the dictionary definition.
However when we use the term requirement within the context of business analysis, it does imply – as one would hope – more specificity and and clarity. Where it can be accurately expressed as the following:
A documented representation of a business need; a condition or capability needed by a stakeholder to achieve a business objective.
Whilst it stays true to the broad dictionary definition, there are a variety of key qualifying words that provide the additional context required: documented, condition, capability, stakeholder, achieve, objective.
So now we have clarity in what a requirement means in the context of business analysis: a need from a business to achieve an objective. How should it be digested and documented?
As I expect you were able to guess, there are specific criteria that a requirement needs to meet in order for it to be considered fully formed, as per the excellent Business Analysis 3rd Edition by Debra Paul & James Cadle. These are:
- Unambiguous
- Testable
- Atomic
- Clear
- Correct
- Understandable
- Feasible
- Independent
- Necessary
Or the slightly shorter – and much easier – to remember through the INVEST mnemonic, which fits into / is aligned with user stories:
- Independent
- Negotiable
- Valuable
- Estimable
- Small (ie can fit into an iteration)
- Testable
This was potentially the quickest overview of requirements definition in the history of definitions. In summary a requirement within business analysis is: something a business needs to achieve an objective. The job of the business analyst is to get enough detail and structure the need in such a way to ensure that the something is fully defined to the point where it can be built, tested and released by the delivery team.
