Why we need to distinguish between Design and product verification?

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.  

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.

AUTHOR

VIJAY PATIL
B.Eng, MSc, CEng, MIMechE

Vijay is a Principal Systems Engineering Consultant. He is an expert systems integrator with wealth of experience in system architecture, requirements management, validation and verification. He has delivered complex and safety critical projects in the Aerospace and Railways industries. He has developed skills through extensive hands on work in manufacturing, design, analysis and test roles and really liked for his amicable personality and can do attitude.

More articles.

bsi and ukas         vijayavionconsulting.co.uk BPMark print base   Achilles RISQS Logo

Contact Get in Touch

  • AVION Systems Consulting Ltd.
    Hollywood Estate, Hollywood Lane, Bristol, BS10 7TW
  • 0117 325 7891
    8am - 6pm Mon - Fri
  • Start the conversation

   

Communicate Say Hello

Send
 
Reset
 

Thank you, your message has been sent!

* Please fill all fields correctly.