Requirement Validation Organization of SRS & Requirement Validation

VALIDATION It is very important that the requirements specification contains no errors and specifies the client's requirements correctly. Because the longer an error remains undetected, the greater the cost of correcting it. Due to the nature of the requirement specification phase, there is a lot of room for misunderstanding and committing errors. The basic objective of the requirements validation activity is to ensure that the SRS reflects the actual requirements accurately and clearly.

Different Types of Errors in SRS Most common errors that occur can be classified in four types: Omission: Here the requirement may be simply Omitted the omitted requirement may be related to the behaviour of the system, its performance, constraints, or any other factor. 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. Incorrect fact: when some fact recorded in the SRS is not correct. Ambiguity: when there are some requirements that have multiple meanings, that is, their interpretation is not unique.

Requirement Errors In a Study, a total of more than 250 errors were detected, and the percentage of different types of errors was: In the errors detected in the requirements specification of the A-7 project (which deals with a real-time flight control software) were reported. A total of about 80 errors were detected, out of which about 23% were clerical in nature. Of the remaining, the distribution with error type was:

Requirement Errors If we take the average of the two data tables, it shows that all four classes of errors are very significant, and a good fraction of errors belong to each of these types. This implies the validation should focus on uncovering these types of errors. Requirement is Generally Textual Document, Hence it cannot executed, So we have to review requirements, validation must involve the clients and the users. Requirements review is a review by a group of people to find errors and point out other matters of concern in the requirements specifications of a system .

Checklist Questions A checklist for requirements review should include items like: Are all hardware resources defined? Have the response times of functions been specified? Have all the hardware, external software, and data interfaces been defined? Have all the functions required by the client been specified? Is each requirement testable? Is the initial state of the system defined? Are the responses to exceptional conditions specified? Does the requirement contain restrictions that can be controlled by the designer? Are possible future modifications specified?

Requirement Errors if requirements are reviewed then not only a substantial fraction of the errors are detected by them, but a vast majority of the remaining errors are detected soon afterwards in the design activity. Sometimes the formal languages or formal specifications are used for SRS in those cases we may have to use some other tools than reviews, But even then some kind of errors e.g. behavioral errors can only be removed by the requirement reviews.