newsletter

If you would like to receive this occasional newsletter, please sign up here.

Ten Tests for Requirements

This newsletter discusses the ten most useful ways of testing requirements. The aim of testing requirements is to ensure that they will achieve the desired result.

Requirements Visibility
We all accept that testing the software is a necessary activity when building a system. However, if the software is written to inaccurate requirements, then no matter how skilled the developer is, the software will not do what it is needed to do. Instead of limiting testing to after code has been developed, we should be testing the requirements before they get anywhere near a keyboard. By making the requirements visible we can test them for qualities like relevance, coherency, traceability and completeness. As a part of its visibility, a requirement needs a fit criterion that makes it measurable. By being able to measure the precise meaning of a requirement we can ensure that it will be interpreted in exactly the same way by the owner of the requirement, the developer of the solution as well as the tester of the solution.

The Quality Gateway
The Quality Gateway is an organizational point through which all requirements must pass. The intention of having this gateway into the specification is to trap incorrect requirements as early as possible, thereby preventing incorrect requirements from passing into the design and implementation. To get through the quality gateway a requirement must satisfy a number of tests. The tests are devised to make sure that the requirement is an accurate statement of the business needs.

Following are ten tests for requirements. There is no priority between the tests, nor is there an order in which they are applied. None of the tests takes very long—in fact, the Gateway activity usually takes only a few seconds.

Requirements Test 1
Does each requirement have a fit criterion that can be used to test whether a solution meets the requirement?
The fit criterion measures the requirement in such a way that the tester can know if the solution meets the requirement. Whereas the requirement might say that the product has to be intuitive, the fit criterion would say that a first time user could open an account in 90 seconds without using any help.

Requirements Test 2
Is every requirement in the specification relevant to this system?
There are two tests here. Firstly check the requirement against the stated goals for the system. Then check if there is a flow of data on the context diagram that contains the data needed for this requirement. Adding new flows to the context without recognising them as a change that will affect estimates and resources means that you are allowing scope creep.

Requirements Test 3
Does the specification contain a definition of the meaning of essential terms within the specification?
Our experience is that each project has an almost-unique vocabulary. Misunderstandings are common unless there is a lexicon defining the terminology. This is also useful for business stakeholders reading the specification.

Requirements Test 4
Is every reference to a defined term consistent with its definition?
Not only do you need to define the terms but also you need to ensure that they are being used in accordance with their definitions.

Requirements Test 5
Is the context of the requirements study wide enough to cover everything we need to understand?
Have you stepped back far enough to include the scope of the business problem rather than just focusing on software product interfaces. The goal of the project is to improve the work. Without studying that work it is difficult to improve it.

Requirements Test 6
Does the requirement contain a rationale?
The rationale is a justification, or a reason for the requirement. This justification tells the developers and the testers how important the requirement is, and how much effort to put into it. If the requirement cannot be justified, then you should consider deleting it.

Requirements Test 7
Have we asked the stakeholders about conscious, unconscious and undreamed of requirements?
If you ask people for requirements they usually just tell you their conscious requirements. Have you explored the problem enough to discover the things that stakeholders assume, and the things they do not realise are possible?

Requirements Test 8
Does the specification contain solutions posturing as requirements?
A requirement is something needed to support the business. This is stated in a technology-free manner. If it mentions some implementation technology, then it is a solution. The problem with solutions is that they are limited by the stakeholder’s experience, and very frequently disguise the real need.

Requirements Test 9
Is the stakeholder value defined for each requirement?
Do we know what benefit a solution to this requirement will provide? It helps if you also ask what is the damage if we do not implement a solution to this requirement?

Requirements Test 10
Is each requirement uniquely identifiable?
Each stage of system development shapes, repartitions and organises the requirements to bring them closer to the form of the new system. To insure against loss or corruption, we need to be able to map the original requirements to the solution for testing and maintenance purposes.

The point of trawling for requirements in the first place is to ensure that the delivered software product meets the needs of the business. Testing the requirements before they are released to the rest of the development effort is simply making sure that the objective for the requirements is met.

You know that all software projects have problems. Making the requirements visible, and testable, means that you discover any problems as early as possible, and correct them before they become major issues. We hope that this checklist helps you to do this.

Our best regards,

Suzanne Robertson

James Robertson