Facing a long list of requirements and not knowing if they’ll produce logical, bug-free code can be daunting. Luckily, getting started with basic requirements testing is easier than you think.

In my last post, I outlined how reviewing your requirements before any code is written saves time and produces stronger, more resilient software.

But what exactly should you look out for when you’re reviewing?

The 4 Cs

I often get asked ‘what’s the point of software requirements?’ and ‘how do you go about testing them?’

Software requirements are descriptions of features and functionalities you want to include in the software you’re creating. They sum up what your users will expect the product to do, e.g. to be able to navigate between web pages, or to be able to place items in a basket and pay for them.

If these requirements are incomplete, or logically flawed, you could end up with a confusing or buggy product with features missing. It’s easy to make mistakes when you’re trying to anticipate and plan for hundreds of scenarios at a time – writing up and testing your requirements ahead of time is vital.

Before coding can begin, you should work your way through your requirements one by one, considering each of ‘The 4 Cs’ in turn:

Completeness – check all possible scenarios have been considered and find any gaps or uncovered cases. Each requirement should contain all the detail needed to express the user’s need and the developer should have all the information they need to do their job.
Correctness – try to find ambiguities and mistakes in the requirement and ensure it follows common sense. The requirement should be consistent with source materials such as marketing plans and specification documents.
Consistency – uncover duplications and contradictions with other requirements and ensure it’s internally and externally consistent. You should use the same vocabulary and terminology for every requirement.
Clearness – check that the statement is correct, logical and truthful – nothing should be left open to interpretation. You may need to provide definitions in a glossary or diagrams to ensure everyone’s on the same page.

Testability and purpose

An additional consideration is testability – making sure there will be a way to check if the end product meets the requirement.

If you anticipate a requirement being hard to test, try breaking it down into smaller steps or components, or rewrite it so that it’s less abstract and more quantifiable, e.g. ‘the system should be faster’ could become ‘the system should be able to respond in x seconds or fewer to any processing request of any type, from any user type request, with up to x active users’.

Good requirements are also related to identified business needs or opportunities – if a function doesn’t fit an obvious purpose, does it need to be there at all? Bearing this in mind will keep your requirements in check and prevent the purpose of your software from drifting as you adjust them over time.

Once defects are identified, either the tester or a wider testing team should suggest ways to resolve the issue and update the requirements. Once everyone involved is satisfied, the developers can begin coding.

See ‘Save time by squashing hugs before writing code’ for more advice on how to implement requirements testing in your team.

Do you perform any reviews in your projects? Do you find processes daunting? Please share your stories and comments with us on Twitter.