The Business Analysis role revolve around the ability to writing requirements and yet we often get it wrong. It is simple to get it right, you just need to learn the recipe. This is the most fundamental skill a business analyst should master before any other!
Become a GREAT Business Analyst and do our Online Business Analysis Practitioner Course and BOOK ONLINE NOW.
Attributes of a good requirement
A requirement should be written as a single unit of understanding or concept. It can only include one concept and be one requirement for each requirement statement.
A requirement should be very specific in nature. You should avoid words that could make it vague. Avoid terms like: may, is some cases, sometimes, frequently.
A requirement should be written in such a way that it can only have one meaning to anyone that reads it.
A requirement should be able to stand on it’s own in a such a way that it has meaning to the reader. It should not need a category or another requirement for it to make sense to the reader.
Example of a badly written requirement
“There is a need for a feature that calculates the salary and the bonus when it applies.”
The above requirement doesn’t tell you:
- whether the system calculates the salary automatically or the user can select to calculate the salary – non specific
- whether it is a monthly, yearly or fortnightly salary – non-specific
- whether it is the gross, net or average salary – ambiguous
- there are two requirements in one requirements description – not singular
- it uses a vague term “when it applies”, it should be more specific
Example of a well written requirement(s)
“Ability for the user to select to calculate the Net monthly salary for employees using the system.”
“Ability for the user to select to calculate the annual bonus for employees using the system.”
The above requirement is adhering to all attributes – it is specific, singular (broken into 2 requirements), independent (it has meaning by itself) and is unambiguous!