Testing Validation

Validation refers to a set of activities that ensure that software that has been built is traceable to the customer requirements. "Are we building the right product?"
"Confirmation by examination and provisions of objective evidence that the particular requirements for a specific intended use are fulfilled."
There are several ways to accomplish validation, the most common being

i) Inspection
Focused on meeting particular customer constraints. For example: An inspection of a machine to see that it will fit in the desired space or an inspection of code modules to ensure their compliance with maintenance demands.

ii) Demonstration
Having the customer or a representative use the product to ensure it meets some minimum constraints (i.e., usability). Also can be used to perform some acceptance tests where the product is running in the intended environment versus some test or development lab. For example: Having pilots fly an aircraft before the customer signs off on the program.
iii) Analysis
Using some form of analysis to validate that the product will perform as needed when demonstrating it is too costly, unsafe, or generally impractical. For example: Using interpolation of performance load based on the worst case, that is feasible to generate, to validate a need that is more stringent than this worst case. If it can be shown that there is no scaling problem, this would be sufficient to validate the performance need.
iv) Prior data
When a component being used has been already validated for a previous project that had similar or stricter constraints. For example: Using a well-known encryption component to meet security needs when the component has been already validated for tougher security requirements.
Early validation
Leaving validation until the end of the project severely increases the risk of failure. Validation activities early in the project can reduce that risk. Early validation activities reveal:
i) Clarifications
Perhaps the most important purpose of early validation is to clarify the real meaning of requirements. The obvious cases are where requirements are incomplete. However, the riskiest requirements are subjective. These include phrases such as "readable" or "user-friendly" or involve human interfaces in general. Early validation can get a response to various interpretations and provide more specifics in areas such as acceptable size, placement, or motion.
ii) Drivers
Some requirements are more critical to the customer than others. Some have larger cost or design impact on the product. With early validation you can uncover the customer�s priorities and relate them to the development impact to identify the serious drivers.

iii) Additions
You can use early validation to discover and coordinate new requirements during the program. An issue is that no spec is totally complete, and it is assumed that the designer has a familiarity with the intended end use environment. Particularly in a new environment that the designer is not familiar with, early validation of requirements can uncover missing requirements. Another use is to coordinate derived requirements with the customer. In this case, the need is often driven by the customer�s lack of knowledge with the technologies being applied and their impact on the use of the product.
iv) Hidden expectations:
Discussions with the customer can reveal unstated expectations or assumptions about the design. One hint is extreme detail in the requirements that may be surrogate for "I want it to work like the old or another system."
Various approaches to early validation include:
Very early validation of requirements closely parallels good requirements elicitation and analysis. Techniques for doing this include involving the user, site visits, or goal-based use cases.