Requirements validation is the process of checking that requirements defined for development, define the system that the customer really wants. To check issues related to requirements, we perform requirements validation. We usually use requirements validation to check error at the initial phase of development as the error may increase excessive rework when detected later in the development process.
In the requirements validation process, we perform a different type of test to check the requirements mentioned in the Software Requirements Specification (SRS), these checks include:
- Completeness checks
- Consistency checks
- Validity checks
- Realism checks
- Ambiguity checks
The output of requirements validation is the list of problems and agreed on actions of detected problems. The lists of problems indicate the problem detected during the process of requirement validation. The list of agreed action states the corrective action that should be taken to fix the detected problem.
There are several techniques which are used either individually or in conjunction with other techniques to check to check entire or part of the system:
- Test case generation:
Requirement mentioned in SRS document should be testable, the conducted tests reveal the error present in the requirement. It is generally believed that if the test is difficult or impossible to design than, this usually means that requirement will be difficult to implement and it should be reconsidered.
In this validation techniques the prototype of the system is presented before the end-user or customer, they experiment with the presented model and check if it meets their need. This type of model is generally used to collect feedback about the requirement of the user.
- Requirements Reviews:
In this approach, the SRS is carefully reviewed by a group of people including people from both the contractor organisations and the client side, the reviewer systematically analyses the document to check error and ambiguity.
- Automated Consistency Analysis:
This approach is used for automatic detection of an error, such as nondeterminism, missing cases, a type error, and circular definitions, in requirements specifications.
First, the requirement is structured in formal notation then CASE tool is used to check in-consistency of the system, The report of all inconsistencies is identified and corrective actions are taken.
A walkthrough does not have a formally defined procedure and does not require a differentiated role assignment.
- Checking early whether the idea is feasible or not.
- Obtaining the opinions and suggestion of other people.
- Checking the approval of others and reaching an agreement.
- Software Engineering | Project size estimation techniques
- Types of Software Testing
- Software Testing | Basics
- Software Engineering | Architectural Design
- Software Engineering | Halstead’s Software Metrics
- Beta Testing | Software Testing
- Software Engineering | Debugging Approaches
- Pairwise Software Testing
- Software Engineering | COCOMO Model
- Software Engineering | Classification of Software Requirements
- Software Engineering | Classical Waterfall Model
- Software Engineering | Iterative Waterfall Model
- Software Engineering | Spiral Model
- Software Engineering | Requirements Engineering Process
- Software Engineering | Requirements Elicitation
If you like GeeksforGeeks and would like to contribute, you can also write an article using contribute.geeksforgeeks.org or mail your article to firstname.lastname@example.org. See your article appearing on the GeeksforGeeks main page and help other Geeks.
Please Improve this article if you find anything incorrect by clicking on the "Improve Article" button below.