Design Verification - Design outputs not verified against customer requirements

B

Bill Rudnicki

Good morning;

I need some help related to an issue found during our last third party audit that is related to design verification. I work for a OEM manufacturer of material handling systems. The specific finding the auditor put on his report (I have taken out the fluff) stated:" the records did not include clear design outputs verified against the system inputs from the customer." He is looking for a checklist of some sort that shows the design outputs being verified against the system inputs. This is not necessarily an issue for smaller projects but how could it be done for our bigger projects? By bigger I am talking about multi million dollar projects that can take a couple of years to complete. It is not feasible to do prototypes for a project like this. Our engineering directors are concerned that we are going to have to add more resources just to handle this aspect of a project. The design specs/scope are large, multiple documents that call out hundreds of different specs and requirements. Given all this I want to include a stand alone sentence that is directly from a bid package from one of our large projects. "The contractor shall provide new conveyor systems that are safe, workable and defect free." Any inputs, thought, ideas on how we can correct this issue would be greatly appreciated.

Thanks,
Bill
 
D

ddunn

Re: Design Verification

I have used a requirements matrix to provide the relationship between design inputs and outputs. The matrix links each customer requirement to the required design attribute, design requirement, test plan, test procedure and result. The requirements matrix is also a useful tool for development planning, tracking product development, evaluating requirements and attribute changes, resource planning, and requirements compliance.
 
M

madannc

Re: Design Verification

Good morning;

I need some help related to an issue found during our last third party audit that is related to design verification. I work for a OEM manufacturer of material handling systems. The specific finding the auditor put on his report (I have taken out the fluff) stated:" the records did not include clear design outputs verified against the system inputs from the customer." He is looking for a checklist of some sort that shows the design outputs being verified against the system inputs. This is not necessarily an issue for smaller projects but how could it be done for our bigger projects? By bigger I am talking about multi million dollar projects that can take a couple of years to complete. It is not feasible to do prototypes for a project like this. Our engineering directors are concerned that we are going to have to add more resources just to handle this aspect of a project. The design specs/scope are large, multiple documents that call out hundreds of different specs and requirements. Given all this I want to include a stand alone sentence that is directly from a bid package from one of our large projects. "The contractor shall provide new conveyor systems that are safe, workable and defect free." Any inputs, thought, ideas on how we can correct this issue would be greatly appreciated.

Thanks,
Bill


Hi Bill

My initial thoughts

Start at beginning

CRS Customer (sometimes called Commercial) Requirement Specification, have known it to be URS as well (User Requirement Spec (for smaller projects)

This document records the desired requirements in "top mgt" speak... in otherwords very general and loose but give the spirit of what is desired.

Each "desired" requirement is numbered

SRS - System Req Spec, this doc takes the CRS and compiles a list of specific system requirements that cross reference the numbers in the CRS this is then accepted/approved as meeting req's of CRS, this phase is usually reffered to as definition.

The end result should be a set of requirements that your prod creation team can take and start working on, but also cross references the CRS... meeting customer initial requirements.

next is Realisation, this phase creates prototypes and tests until they are satisfied they can meet SRS req's, during this phase there should be a number of design reviews that capture where project is, looks at FMEA, risk Analysis etc etc, but also that the output is meeting the input (SRS).

Once satisfied a design freeze is put in place and Verification starts

The Verification documentaion should have requirement (from SRS), a test for this req, and a space to record result... some companies also include expected result too. A VCRI (Verification Cross Reference Index) is created around this time, this document provides instant overview of CRS req to SRS req to test in place and result.

Then onto design transfer and Validation

The point I am trying to make if this process (which I have not done justice there is a lot of info out there on this) is followed it ensures that design input meets design output.

With large corporate projects it can take a while to nail down SRS due to the number of requirements it contains. The project manager also needs to ensure that any amends to the CRS do not affect the project... e.g. the inclusion of a req 7 months into the project means that the SRS and Verification and VCRI need updating.

I hope this helps :rolleyes:
 

michellemmm

Quest For Quality
Re: Design Verification

I have used a requirements matrix to provide the relationship between design inputs and outputs. The matrix links each customer requirement to the required design attribute, design requirement, test plan, test procedure and result. The requirements matrix is also a useful tool for development planning, tracking product development, evaluating requirements and attribute changes, resource planning, and requirements compliance.

Excellent. Thanks.

Do you use a specific format or template? I would love to see a copy of your matrix. I tried to visualize a matrix and had difficulty coming up with a multi-dimensional format.
 
M

madannc

We use something called Test Director, this is part 11 compliant software that hold all test cases for a SRS.

We use this for our VCRI within this we also hold the test cases for regulatory and standard requirements.

Whatever you use you need show that you have verified that all requirements (user & compliance) have been met.

We manufacture Linear Accelerators for use in oncology and because of the huge amount of regs and stds this works well for us to control a lot of requirements, if you don't have that many to adhere to then a simple cross reference sheet is fine.
 
V

vanputten

I would review the defintions in ISO 9000 for validation and verification. You may find that you are already verifying and validating your designs.

And if the auditor is looking for a checklist, think twice. You can provide eveidence of design verification and validation without a checklist.

Verify to the provided specific requirements.

Validate to intended use or application.

I bet your organization already does both and this is lost in translation between ISO 9001, the auditor, and your organization.

For example, the customer may want you to design a bucket with a hole in it. The intended use is to carry water. You design the bucket, and verify the location and size of the hole just as the requirements stated. Then you make some samples and validate that it can hold water which is the intended application. It does not hold water. The design was both verified and validted, however the design did not pass the validation.


Regards,

Dirk
 
Top Bottom