Validation

• The development of software starts with a requirements document, which is also used to determine eventually whether or not the delivered software system is acceptable. It is therefore important that the requirements specification contains no errors and specifies the client's requirements correctly.
• Due to the nature of the requirement specification phase, there is a lot of room for misunderstanding and committing errors, and it is quite possible that the requirements specification does not accurately represent the client's needs.
• The basic objective of the requirements validation activity is to ensure that the SRS reflects the actual requirements accurately and clearly. A related objective is to check that the SRS document is itself of "good quality“.
• The most common errors that occur can be classified in four types:

1. Omission is a common error in requirements. Some user requirement is simply not included in the SRS; the omitted requirement may be related to the behavior of the system, its performance, constraints, or any other factor.
2. Inconsistency can be due to contradictions within the requirements themselves or to incompatibility of the stated requirements with the actual requirements of the client or with the environment in which the system will operate.
3. Incorrect fact, Errors of this type occur when some fact recorded in the SRS is not correct.
4. Ambiguity, Errors of this type occur when there are some requirements that have multiple meanings, that is, their interpretation is not unique.
5. On an average, a total of more than 250 errors were detected, and the percentage of different types of errors was:

• Checklists are frequently used in reviews to focus the review effort and ensure that no major source of errors is overlooked by the reviewers.

1. Are all hardware resources defined?
2. Have the response times of functions been specified?
3. Have all the hardware, external software, and data interfaces been defined?
4. Have all the functions required by the client been specified?
5. Is each requirement testable?
6. Is the initial state of the system defined?
7. Are the responses to exceptional conditions specified?
8. Does the requirement contain restrictions that can be controlled by the designer?
9. Are possible future modifications specified? 

Requirements reviews are probably the most effective means for detecting requirement errors.