6 Basic Criteria For Testing Requirements

6 Basic Criteria For Testing Requirements
May 07 10:00 2011 Print This Article

There are six basic criteria that must be used during the static testing of specification requirements. The criteria require that each requirement consistent with the principles of completeness, unambiguity, consistency, traceability, the practicability and testability.

6 Basic Criteria For Testing Requirements

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 set of requirements for completeness 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.
• The requirement should not rely on the functionality that have
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 table. If a more convincing use expressions like “It’s obvious” or “self-evident, it is quite possible that the author 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 in order to resolve such conflicts. The ability to detect damages resulting from 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 life cycle, such as the test plan, 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 to the system of unrealistic demands in terms of time spent and funds for the development of various functions or else requires the development of functions which 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 in order to demonstrate that the tested software product possesses the necessary functionality, performance, and appropriate current standards. This means that each claim must be measured or be quantifiable and that testing should performed in acceptable conditions.

Related Posts:

  • No Related Posts

About Article Author

view more articles
Nataliia Vasylyna

View More Articles
  • Cor van Rijn

    Hello Anastasia,

    I like your article. Good stuff.
    IEEE 830 (Software Requirements Specification).
    You might want to add that the requirements must not be out-of-date.