In software project management, software testing, and software engineering, Verification and Validation (V&V) is the process of checking that a software system meets specifications and that it fulfils its intended purpose. It is normally part of the software testing process of a project. In pharmaceutical industry, verification involves testing the suitability of well established procedures or (compendial) methods, whereas validation varies from Cross validation, Empirical validation, periodic partial validation, internal/external validation, competence validation by nature, and Cleaning validation, Process validation, Equipment validation, or Documentation validation by tasks.
Also known as software quality control
Validation checks that the product design satisfies or fits the intended usage (high-level checking) — i.e., you built the right product. This is done through dynamic testing and other forms of review.
According to the Capability Maturity Model (CMMI-SW v1.1), “Validation – The process of evaluating software during or at the end of the development process to determine whether it satisfies specified requirements. [IEEE-STD-610] Verification- The process of evaluating software to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. [IEEE-STD-610].”
In other words, verification is ensuring that the product has been built according to the requirements and design specifications, while validation ensures that the product actually meets the user’s needs, and that the specifications were correct in the first place. Verification ensures that ‘you built it right’. Validation confirms that the product, as provided, will fulfill its intended use. Validation ensures that ‘you built the right thing’.
 Related concepts
Both verification and validation are related to the concepts of quality and of software quality assurance. By themselves, verification and validation do not guarantee software quality; planning, traceability, configuration management and other aspects of software engineering are required.
 Classification of methods
In mission-critical systems where flawless performance is absolutely necessary, formal methods can be used to ensure the correct operation of a system. However, often for non-mission-critical systems, formal methods prove to be very costly and an alternative method of V&V must be sought out. In this case, syntactic methods are often used.
 Test cases
A test case is a tool used in the V&V process.
The QA team prepares test cases for verification–to determine if the process that was followed to develop the final product is right.
The QC team uses a test case for validation–if the product is built according to the requirements of the user. Other methods, such as reviews, when used early in the Software Development Life Cycle provide for validation.
Verification can be called a part of validation process.
 Independent Verification and Validation
Verification and validation often is carried out by a separate group from the development team; in this case, the process is called “Independent Verification and Validation”, or IV&V.
Verification and Validation
Verification and Validation (V&V) is the process of checking that a product, service, or system meets specifications and that it fulfils its intended purpose. These are critical components of a quality management system such as ISO 9000.
Verification is a quality process that is used to evaluate whether or not a product, service, or system complies with a regulation, specification, or conditions imposed at the start of a development phase. Verification can be in development, scale-up, or production. This is often an internal process.
Validation is the process of establishing documented evidence that provides a high degree of assurance that a product, service, or system accomplishes its intended requirements. This often involves acceptance and suitability with external customers.
It is sometimes said that validation ensures that ‘you built the right thing’ and verification ensures that ‘you built it right’. ‘Building the right thing’ refers back to the user’s needs, while ‘building it right’ checks that the documented development process was followed. In some contexts, it is required to have written requirements for both as well as formal procedures or protocols for determining compliance.
Verification of machinery and equipment usually consists of Design Qualification – DQ , Installation Qualification – IQ , Operational Qualification – OQ  and Performance Qualification – PQ . DQ is usually a vendor’s job. However, DQ can also be performed by the user, by confirming through review and testing that the equipment meets the written acquisition specification. If the relevant document or manuals of machinery/equipment are provided by vendors, the later 3Q needs to be thoroughly performed by the users who work in an industrial regulatory environment. Otherwise, the process of IQ, OQ and PQ is the task of validation. The typical example of such a case could be the lost or absent of vendor’s documentation for a legacy equipment or DIY assemblies (i.e. cars, computers etc.) and, therefore users should endeavour to acquire DQ document beforehand. Each template of DQ, IQ, OQ and PQ usually can be found on the internet respectively, whereas the DIY qualifications of machinery/equipment can be assisted either by the vendor’s training course materials and tutorials, or by the published guidance books, such as step-by-step series if the acquisition of machinery/equipment is not bundled with on- site qualification services. This kind of the DIY approach is also applicable to the qualifications of software, computer operating systems and a manufacturing process. The most important and critical task as the last step of the activity is to generating and archiving machinery/equipment qualification reports for auditing purposes, if regulatory compliances are mandatory. At the same time, one should bear in mind to kindly share the original work with others, if the activity, especially validation of newly invented machinery/equipment, is worth of publishing.
Qualification of machinery/equipment is venue dependent and re-qualification needs to be conducted once the objects are relocated. The full scales of some equipment qualifications are even time dependent, and hence re-certification is necessary when a specified due time laps , . Re-qualification of machinery/equipment should also be conducted when replacement of parts, or coupling with another device, or installing a new application software and restructuring of the computer which affects especially the pre-settings, such as on BIOS, registry, disk drive partition table, or an ini file etc, have been necessary. In such a situation, the specifications of the parts/devices/software and restructuring proposals should be appended to the qualification document whether the parts/devices/software are genuine or not. Torres and Hyman have discussed the suitability of non genuine parts for clinical use and provided guidelines for equipment users to select appropriate substitutes which are capable to avoid adverse effects . In the case when genuine parts/devices/software are demanded by some of regulatory requirements, then re-qualification should not be conducted on the non genuine assemblies. In stead, the asset has to be recycled for non regulatory purposes.
When machinery/equipment qualification is conducted by a standard endorsed third party such as by an ISO standard accredited company for a particular division, the process is called certification , . Currently, the coverage of ISO/IEC 15408 certification by an ISO/IEC 27001 accredited organization is limited, the scheme requires a fair amount of efforts to get popularized.