Software Requirement Quality Criteria

Requirements for an application or a new feature are very important in terms of Quality Assurance. But since the requirements can not always be documented, the main criteria for the quality of the requirement is the fact of the presence of these software requirements. The requirements themselves must satisfy the quality criteria, which we will describe below.

There are nine criteria for the quality of requirements:

Correctness

It happens that the requirements make mistakes when compiling those. This can be detected by analyzing the requirements as a whole, finding another place where there is a discrepancy with the previous value, for example, an incorrect interest rate for a loan in a banking application, but if this place is unique, then such a inaccuracy can be recognized by the tester and only the user or the one who details introduced to the course of data accuracy, can recognize and correct it.

Read more about: Independent software testing services

Unambiguity

The accuracy of the wording in the requirements can be interpreted in different ways by testers, developers and other project participants. The problem arises because the requirements are written in “natural language” and different team members belonging to different groups are so used to their interpretation of words or phrases that it is already difficult for them to imagine that this for someone else has a completely different meaning.

Completeness

Often in requirements they forget to describe validations on fields or units of measure in which values ​​or even whole sections will be displayed that can be skipped by carelessness.

Consistency

Conflicts in the description of the same functional in different parts of the requirements are often found through mechanical analysis. One part of the requirements may say that for some action you need to perform something, while in the other part of the requirements you can find that the same functionality should perform something else.

Sort by importance and stability

In good requirements, you can see how the customer, customers or other interested parties have ordered the requirements according to their importance and stability. For this, an attribute can be assigned to each requirement. The most useful ones are sequencing in terms of cost, risk and complexity.

Verifiability

Requirements should be made in such a way that testers literally draw test cases from there, for each good point from the requirements, you can usually write several test cases that will cover this point of requirements.

Modifiability

Requirements should be well organized and have cross-references, breakdown. In large systems, applications, requirements can be supported by an automated tool and are easily modifiable.

Comprehensibility

The requirements should be such that they could be understood by both the developer, the tester and the user if he took this document into his own hands. For this, a description of the terms used as well as illustrations and storyboards are used.