Requirements Validation in Software Engineering

The development of software begins once the requirements document is ‘ready’. One of the objectives of this document is to check whether the delivered software system is acceptable. For this, it is necessary to ensure that the requirements specification contains no errors and that it specifies the user’s requirements correctly. Also, errors present in the SRS will adversely affect the cost if they are detected later in the development process or when the software is delivered to the user. Hence, it is desirable to detect errors in the requirements before the design and development of the software begins. To check all the issues related to requirements, requirements validation is performed.

In the validation phase, the work products produced as a consequence of requirements engineering are examined for consistency, omissions, and ambiguity. The basic objective is to ensure that the SRS reflects the actual requirements accurately and clearly. Other objectives of the requirements document are listed below.

1. To certify that the SRS contains an acceptable description of the system to be implemented
2. To ensure that the actual requirements of the system are reflected in the SRS
3. To check the requirements document for completeness, accuracy, consistency, requirement conflict‘, conformance to standards and technical errors.

Requirements validation is similar to requirements analysis as both processes review the gathered requirements. Requirements validation studies the ‘final draft’ of the requirements document while requirements analysis studies the ‘raw requirements’ from the system stakeholders (users). Requirements validation and requirements analysis can be summarized as follows:

1. Requirements validation: Have we got the requirements right?
2. Requirements analysis: Have we got the right requirements?

Various inputs such as requirements document, organizational knowledge, and organizational standards are shown. The requirements document should be formulated and organized according to the standards of the organization. The organizational knowledge is used to estimate the realism of the requirements of the system. The organizational standards are specified standards followed by the organization according to which the system is to be developed.      

The output of requirements validation is a list of problems and agreed actions of the problems. The lists of problems indicate the problems encountered in the” requirements document of the requirements validation process. The agreed actions is a list that displays the actions to be performed to resolve the problems depicted in the problem list.

Requirements Review

Requirements validation determines whether the requirements are substantial to design the system. The problems encountered during requirements validation are listed below.

1. Unclear stated requirements
2. Conflicting requirements are not detected during requirements analysis
3. Errors in the requirements elicitation and analysis
4. Lack of conformance to quality standards.

To avoid the problems stated above, a requirements review is conducted, which consists of a review team that performs a systematic analysis of the requirements. The review team consists of software engineers, users, and other stakeholders who examine the specification to ensure that the problems associated with consistency, omissions, and errors are detected and corrected. In addition, the review team checks whether the work products produced during the requirements phase conform to the standards specified for the process, project, and the product.

At the review meeting, each participant goes over the requirements before the meeting starts and marks the items which are dubious or need clarification. Checklists are often used for identifying such items. Checklists ensure that no source of errors, whether major or minor, is overlooked by the reviewers. A ‘good’ checklist consists of the following.

1. Is the initial state of the system defined?
2. Is there a conflict between one requirement and the other?
3. Are all requirements specified at the appropriate level of abstraction?
4. Is the requirement necessary or does it represent an add-on feature that may not be essentially implemented?
5. Is the requirement bounded and has a clear defined meaning?
6. Is each requirement feasible in the technical environment where the product or system is to be used?
7. Is testing possible once the requirement is implemented?
8. Are requirements associated with performance, behavior, and operational characteristics clearly stated?
9. Are requirements patterns used to simplify the requirements model?
10. Are the requirements consistent with the overall objective specified for the system/product?
11. Have all hardware resources been defined?
12. Is the provision for possible future modifications specified?
13. Are functions included as desired by the user (and stakeholder)?
14. Can the requirements be implemented in the available budget and technology?
15. Are the resources of requirements or any system model (created) stated clearly?

The checklists ensure that the requirements reflect users’ needs and provide groundwork for design. Using the checklists, the participants specify the list of potential errors they have uncovered. Lastly, the requirements analyst either agrees to the presence of errors or states that no errors exist.

Other Requirements Validation Techniques

A number of other requirements validation techniques are used either individually or in conjunction with other techniques to check the entire system or parts of the system. The selection of the validation technique depends on the appropriateness and the size of the system to be developed. Some of these techniques are listed below.

1. Test case generation: The requirements specified in the SRS document should be testable. The test in the validation process can reveal problems in the requirement. In some cases test becomes difficult to design, which implies that the requirement is difficult to implement and requires improvement.
2. Automated consistency analysis: If the requirements are expressed in the form of structured or formal notations, then CASE tools can be used to check the consistency of the system. A requirements database is created using a CASE tool that checks the entire requirements in the database using rules of method or notation. The report of all inconsistencies is identified and managed.
3. Prototyping: Prototyping is normally used for validating and eliciting new requirements of the system. This helps to interpret assumptions and provide an appropriate feedback about the requirements to the user. For example, if users have approved a prototype, which consists of graphical user interface, then the user interface can be considered validated.