6 Basic Criteria For Testing Requirements

by Emma Dallas | May 7, 2011 10:00 am

Note: the article was updated in November 2019

Why clear requirements are so vital during the software development life cycle? How not to waste time writing them but get benefits from this process? Read this blog article to get clear criteria on how testing requirements should look like.

The importance of requirements for testing a software

All kinds of requirements have the goal to set up some process, show the directions and boundaries. In case of requirements testing, it is the starting point for the quality assurance process to run. Below are the benefits you receive if prepare requirements for a software testing team:

The majority of software bugs can be tracked on the stage when QA specialists work with the requirements. That is why it is better to revise the testing requirements before things go to coding.

The list of basic testing requirements

Six basic criteria must be used during the static testing of specification requirements. These criteria check if each requirement corresponds to the principles of completeness, unambiguity, consistency, traceability, practicability, and testability.

Completeness. A set of requirements is considered to be complete if all its constituent parts are represented and each part is made in full. During testing of the set of requirements for completeness, testers should pay special attention to the following moments:

• Requirements should not contain expressions such as “and so on,” and others “and the like.
• Requirements must not refer to non-existent background information such as for example, a non-existent specification[1].
• The requirement should not rely on functionality that is not defined.

Unambiguity. Each claim must be clearly and precisely formulated, it should allow a unique interpretation. The demand must be legible and understandable. If the demand is particularly complex, then to facilitate understanding, it can be called an auxiliary material such as diagrams, or tables. If convincing expressions like “it’s obvious” or “self-evident” are used, it is quite possible that the author is trying to divert your attention from one or another ambiguous statement.

Consistency. Requirements should not contradict each other or current standards. If the requirements conflict with each other, we must introduce priorities to resolve such conflicts. The ability to detect damages resulting from the violation of the requirements involves a good knowledge of the document containing the requirements and familiarity with the existing standards or other external specifications.

Traceability. Each claim must have a unique identifier, which allows you to trace its development throughout the life cycle. In the work products that appear at later stages of the life cycle, such as the test plan[2], every reference to the property system must be traceable to the definition and specification requirements.

Practicability. Each claim should include the system task to provide such remedies as appropriate to develop and maintain. If a customer makes unrealistic demands in terms of time spent and funds for the development or requires the development of functions that will be unreliable and dangerous to use, you must define risks and take appropriate action. In fact, the developed system must be economically feasible, reliable, easy-to-use and accompaniment.

Testability. We should be able to develop economically viable and easy to use tests for each requirement to demonstrate that the tested software product possesses the necessary functionality, performance, and appropriate current standards. This means that each claim must be measured and that testing should be performed under acceptable conditions.

Conclusion on testing requirements

One of the main ideas of software testing services is to prevent bugs and faults in production. Testing requirements for future software[3] is a reliable solution to avoid mistakes during the development stage. It is when the continuous testing starts, to guarantee the required quality of the developed software and eliminate possible business risks.

We hope that the above testing procedure template will assist you while preparing the requirements, and that advice from QATestLab testers will be useful for your project.

Related Posts:

• What to Do if Requirements Are Changing Constantly?[4]
• How to Test without Specification[5]
• Does Your Project Need a Test Plan?[6]

Source URL: https://blog.qatestlab.com/2011/05/07/6-basic-criteria-for-testing-requirements/

---