Requirement reviews remain the most commonly used and viable means for requirement validation. However, there are other approaches that may be applicable for some system or parts of system or system that have been specified formally.
We’ll be covering the following topics in this tutorial:
Automated Cross Referencing
Automated cross-referencing uses processors to verify some properties of requirements. Any automated processing of requirements is possible if the requirements are written in a formal specification language or a language specifically designed for machine processing.
We saw example of such language earlier. These tools typically focus on checks for internal consistency and completeness, which sometimes leads to checking of external completeness. However, these tools cannot directly checks for external completeness. For this reason, requirement reviews are needed even if the requirements are specified through a tool or in a formal notation.
If the requirements are in machine process able form, they can be analyzed for internal consistency among different elements of the requirement.
The goal in reading is to have someone other than the author or the requirements read the requirement specification document to identify potential problems. Having the requirement read by another person who may have different interpretation of requirements, many of the requirements problems caused by misinterpretations or ambiguities can be identified. Furthermore, if the reader is a person who is in interested in the project (like a person from the quality assurance group that will eventually test the system) can address issues that could cause problem later.
For example, if a tester reads the requirement, it is likely that the testability of requirement will be well examined.
Scenarios describe different situations of how the system will work once it is operational. The most common area for constructing scenarios is that of system user interaction. Constructing scenarios is good for clarifying misunderstandings in human computer interaction area. They are of limited value for verifying the consistency and completeness of requirements
Though prototypes are generally built to ascertain requirements, a prototype can be built to verify requirements. Prototype can be quite useful in verifying the feasibility of some of the requirement (such as answering the question Can this be done?) A prototype that has been built during problem analysis can also aid validation. For example, if the prototype has a use interfaces and the client has approved them after use, then the user interface, as specified by the prototype, can be considered validated. No further validation need be performed for user interface.
The basic purpose of metrics at any point during a development project is to provide qualitative information of the management process so that the information can be used effectively to control the development process.