Blog

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.

74112011 S

 

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