ISO 9000:2000 Clause 7.3 Design and Development Requirements Summary

[Andy Bassett]

I actually value most of the changes in the new ISO 9000:2000, i think it makes it a much more user friendly beast.

However Design and or Development still has me confused.

Can you help me out, can we take an unusual example ie the design of a NASCAR Racecar, and specify what each section could be. This is my understanding;

7.3.1 Design and/or development planning
OK so we need a procedure for how design is going to be done.

7.3.2 Design and/or development inputs.
Could the NASCAR regulations be described as design inputs? ie Car shall weigh at least 450Kgs and not be wider than 1.8 Meters etc

7.3.3 Design and/or developement outputs.
Could this simply be the drawings that come of the CAD machines for the chassis and suspension etc?

7.3.4 Design and/or development review
Could this simply be the weekly project meeting?

7.3.5 Design and/or developement verification.
What could this be? Can you offer any realistic suggestions. How can you verify designs,? FEM is the only thing that crosses my mind.

7.3.6 Design and/or development validation
What could this be? In this example does it actually mean doing a product test? ie taking the car to the race circuit. This seems to be more like a product test than a design test.

7.3.7 Control of Design and/or development changes.
This should be relatively clear, some form of Engineering Change System.

Any help greatfully accepted.

------------------
Andy B

[This message has been edited by Andy Bassett (edited 20 September 2000).]

Andy, this may help. My company build racks that hold car parts (just for brief background). Here is how we respond to those items:
7.3.2 Inputs: Input is infomration received in order to begin. This can be written/verbal instructions from an engineer, parts, math data, etc.
7.3.3 Outputs: Ours are in the form of prints, disk, prototype racks, etc.
7.3.4 Review: FMC requires us to document reviews. We have concept(preliminary ideas/sketches), protoype(design only and sometimes includes an actual proto rack) and final design. The reviews are with the designer and the engineer and may include, estimating, production, and QC.
7.3.5 Verification: From our business we can verify a design by building a prototype for approval.
7.3.6 Validation: Our company cannot do validation for our products in house. Besides 95% of our customers who have us do design do the validation testing(which by the way for a rack usually means SHAKE / IMPACT tests)for us and copy us on the results(sometimes).
7.3.7 Changes: You're rights, you need to develop a way to track changes and how you relay these changes to the operations involved. We use a Design Revision Form with a distribution list on the bottom.
I hope this helps, I'm new to this site and don't want to make a fool of myself.

hope this helps.

Verification checks whether the design meets the original specifications (design input).

Validation checks whether the new product works (does what it's supposed to).

Both are important, but different ways of looking at a new product.

Dave

------------------

Thanks for the help so far, sometines i need real examples to fully understand how the standard can be interpreted in real-life, your example was a very good one.

Sherri O dont worry if you make a fool of yourself, you are in good company.

BTW
7.3.5 Verification: From our business we can verify a design by building a prototype for approval.

How do you verify the prototype if you arent actually testing it? Do you say 'Yes this looks lie what the engineer wanted'. Who and how do you sing it off? Does somebody approve the BoM.

Regards

Andy,
Verification can begin before the prototype is built and tested. Verification should begin in the design stage using analyses, alternate calculations, simulation, modelling, whatever tools are available to the engineer.

To verify our prototype against the design, we do dimensional checks and also part checks. We can load the prototype with parts to make sure they fit properly. The customer's engineer will usually come to ur plant and sign off on the protoype/design if approved and/or make changes to restart the process.
Yes i agree verification can begin before a prototype, but for most of our builds, racks are similar in design/function. We use past builds, TGR/TGW etc.

[Rick Goodson]

Andy,

Re Verification and Validation

The input to your example would be the NASCR regs, but also would include and the owner/engineer/driver input. One of those inputs might have to do with the speed the vehicle needs to be capable of. That speed requirement is translated into an engine design in terms of displacement, horse power, torque, etc.

When the engine is designed and built we 'verify' that it is the displacement specified, does supply the specified torque, produces x amount of horsepower. This is design verification. We then take it to the track to determine if it can meet the speed requirement, which is the 'end user' requirement. Does it perform. This is design validation. Now, in theory, we should do the validation under use conditions, which would imply running it in a race. In fact, the validation probably is performed in a more 'sterile' condition with just that vehicle on the track.

Hope that helps.

[Andy Bassett]

Thanks everyone, im just mulling over the responses to decide how best to translate them into a present problem. I now have a better understanding of how different companies are interpreting design verification and design validation.

My only problem at the moment is exactly how to insert the design verification into the sample NASCAR environment REALISTICALLY, ie without burdening somebody with the need to sign something that he doesnt really understand why he is doing it.

This type of environment is in someways an ISO nightmare, as development is not done in nice clean packets that can be completed and then signed off, rather development is a permanent activity taking place in the office, at the track and during the night.

Regards

------------------
Andy B