Requirements Testing

Requirements testing seem to be brief. They fly in and out of projects; they are unpredictable, inflexible and sometimes invisible. While gathering requirements we are looking for all the criteria for a system’s success. Some of the techniques Using gathering information for requirements testing are Blitzing, Rapid Application Development (RAD), Joint Application Development (JAD), Quality Function Deployment (QFD), interviewing, apprenticing, data analysis.

1. Abstract
Testing the software is an integral part of building a system. But if the software is based on inaccurate requirements, then with well written code software will be unsatisfactory.

2. The Quality Gateway:
As the requirement got singled out then testing can start. The aim is to catch requirements-related defects as early as identified. It would prevent from incorporating incorrect requirements in the design and implementation. To pass through the quality gateway, requirement must pass a number of tests. These tests are concerned about ensuring that the requirements are accurate. This will make sure that the requirement will not cause any problem in design and implementation in later stages.

3. Make the Requirement Measurable
There would be a quality measure for each requirement. Each requirement should have a quality measure that makes it possible to divide all solutions of the requirement into two classes: those which that fit into the requirement and those which that they do not fit into the requirement. In other words quality measure for a requirement means that any solution that meets the measure will be acceptable. Of course it is also true to say that any solution that does not meet the measure will not be acceptable. The quality measures are used for testing the new system against the requirements.

4. Quantifiable Requirements
Quantifiable requirement are those which the system respond quickly to customer enquiries. First thing to find a property of this requirement that provides us with a scale for measurement within the context.

5. Non-quantifiable Requirements
An attempt to define the quality measure for a requirement helps to rationalize fuzzy requirements. Something like “the system must provide good value” is an example of a requirement that everyone would agree with, but each person has his own meaning. By investigating the scale that must be used to measure “good value” identify the diverse meanings.

6. Coherency and Consistency
The requirements engineer has the intention that each requirement to be understood in the same way by every person who reads it. This subjectivity means that many systems are built to satisfy the wrong interpretation of the requirement. The obvious solution to this problem is to specify the requirement in such that it is understood in only one way.