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 | Requirements Engineering Process
- Software Engineering | Requirements Elicitation
- Software Engineering | Challenges in eliciting requirements
- Software Engineering | Classification of Software Requirements
- Software Engineering | Verification and Validation
- Software Engineering | Project size estimation techniques
- Basic fault tolerant software techniques
- Software Engineering | Reverse Engineering
- Software Engineering | Introduction to Software Engineering
- Software Engineering | Re-engineering
- Software Engineering | Software Project Management Plan (SPMP)
- Software Engineering | Jelinski Moranda software reliability model
- Software Engineering | Schick-Wolverton software reliability model
- Software Engineering | Role and Responsibilities of a software Project Manager
- Software Engineering | Software Project Management Complexities
If you like GeeksforGeeks and would like to contribute, you can also write an article using contribute.geeksforgeeks.org or mail your article to email@example.com. 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.