In Systems Integration, the terms Validation and Verification serve different purposes.
In the context of systems integration practices, 'Verification' means the process of providing undisputed evidence that the system meets the requirements. Thus, 'performing the system verification' means proving that we are 'building the system right'. Not to be confused with Validation, which focuses on developing a better understanding of the customer requirements to ensure that we are 'building the right system'.
Verification is a continuous process spanning the entire development and certification programme for a system. Throughout the development phase, several activities are being performed to ensure that the design will or does meet the requirements. If the activity uses the same product configuration as the production article, then evidence generated by the activity can be used for the purpose of verification.
Types of verification
Verification activities are classified as 'Design' or 'Product' verification activities. Design verification activities involve a theoretical exercises e.g. design description documents, simulation, analysis and review of engineering drawings. The product configuration referred to in the design verification activities must be the actual or similar to the production article (system or component) configuration. The product verification activities consists of direct assessment of function or performance on the system or component of the product e.g. a performance test, an EMC test.
Now that we know what design and product verification is, lets understand why the activities should be classified as either 'design' or 'product' verification, a real million dollar question.
When it comes to submitting deliverables to the customer, such a distinction could be very useful. Deliverables from the design verification activities contain detailed information about the system design and the architecture definition process. such information is invaluable, crucial for your survival and is your 'Intellectual Property'. If freely available through deliverables, such information can potentially allow the customer to have more knowledge than they need, in order to accept the system. This can lead to a unintentional transfer of IP, perfectly legitimate if agreed in the project delivery framework.
A good practice is to agree on the definition of the design and product verification when agreeing the engineering deliverables with the customer. The terms and conditions should clearly state that the 'Design Verification' evidence remains available for review at your discretion and be withheld to protect the IP, if satisfactory product evidence is provided.
