22 November, 2017
What Makes a Good Requirement
Poor requirements can often lead to a project failure by causing delays, increasing the drain on the budget, producing an end-product that is not fit for purpose and worst of all - an unhappy customer.
Requirements are used by all the stakeholders of a product at every stage of development up until final delivery. Therefore, it is imperative to have quality requirements that define and call out all the business expectations from the product. By removing room for misinterpretation and providing good requirements, you can avoid common pitfalls and situations such as this:
How do you know if a requirement is good or bad?
“The page should load quickly”
“There has to be a way to authenticate the account”
“I want a sign-up functionality”
“I want the home page to look better than my competitor’s website”
The above examples fail to follow the basic rules of good requirements advocated by all Testers:
Rule 1: CLEAR
All requirements should be clear, simple, unambiguous and contain no vague language. They should not be open to interpretation and be understood in the same way by the whole audience. This also includes breaking down high level requirements into simple, lower level objectives.
Rule 2: COMPLETE
All requirements should be fully outlined and complete before they are published. They should be free of ‘unknowns’, ‘TBCs’, ‘to be determined’, etc. If development is based on incomplete requirements then there is a much greater chance of the ultimate product containing unexpected defects.
Rule 3: UNIQUE
Each requirement should only cover one objective at a time. They should not be combined or mixed with other requirements even if they are related or similar. This ensures that development and testing are performed efficiently. Usage of ‘&’, ‘and’, ‘!’, etc. should be avoided at all times to define a requirement. Avoid the duplication of requirements as this could lead to confusion and waste of resources.
Rule 4: MEASURABLE
Requirements should be measurable by ranges using exact measurement units like seconds, and avoiding vague statements like ‘reasonable’. It is very hard to gauge the acceptance criteria for testing purposes if the requirements cannot be properly measured against results.
Rule 5: RELEVANT
Developing and testing a function that is not in scope is a waste of time and resources. Therefore, requirements should be appropriate for the proposed solution.
Rule 6: TESTABLE
All requirements should be testable and it should be easy to determine that the requirement has been met
Rule 7: FEASIBLE
Requirements should be able to be implemented with the available environments, tools and other existing resources. Consideration should be given to costs, risks, schedule and skills while drafting requirements.
Rule 8: BENEFICIAL
To avoid unnecessary costs to the project, there should be a business benefit to be gained from all requirements.
In summary, adhering to these 8 rules while drafting requirements will ensure timely delivery of a quality product; guaranteeing customer satisfaction and safeguarding company reputation.
By Scott Livingstone and Reeba Vyas, Test Analysts at Edge Testing
Back to Blog