Hi Covers!

I'd like to know your opinion about this..
Is prototyping a design output or design verification?
I understand that during the design output, R&D engrs do mechanical drawings, schematic diagrams, electrical diagrams, BOMs to meet the input requirements. Design verification checks if the output meets the input requirements. Where does protoyping included?

I am a little confused right now..
Please enlighten me..
thanks
:thanks:

In my experience a prototype is built and tested as a design verification activity. Once the test results were reviewed, then the next phase of design can be entered.

In my experience a prototype is built and tested as a design verification activity. Once the test results were reviewed, then the next phase of design can be entered.

Yes, and design output generally consists of specifications and requirements.

Some of the definitions depend on the industry you're working in. For example, the FDA states the following in its small entity compliance guide:

"Design input includes determining customer needs, expectations and requirements plus determining regulatory, standards, and other appropriate requirements. These various requirements are documented by the manufacturer in a set of device requirements. A set of design input requirements, when converted to engineering terminology, finalized and accepted as part of the device master record is called a device or product specification."

The FDA lists a separate procedural requirement under "Design Transfer" for final specification development. So basically, FDA considers product specs (at least the initial ones) to be design inputs. But I know that's not how everyone defines it.

The whole process is a continuum. The key thing regardless of the industry is to: 1) Plan design activities, 2) Determine the requirements, 3) Execute the initial design, 4)Test the design to see if it met requirements, 5) Change the design if you have to until you can confirm you met the requirements, 6)Document the process, specs and changes, and 7) Get the customer to confirm it's what they wanted.

If you do these things, you should meet requirements for controlling designs regardless of what you want to call the different steps.

....................... The whole process is a continuum. The key thing regardless of the industry is to: 1) Plan design activities, 2) Determine the requirements, 3) Execute the initial design, 4)Test the design to see if it met requirements, 5) Change the design if you have to until you can confirm you met the requirements, 6)Document the process, specs and changes, and 7) Get the customer to confirm it's what they wanted.

If you do these things, you should meet requirements for controlling designs regardless of what you want to call the different steps.

Good post and advice from Mark. Prototype is certainly verification if used to confirm design assumptions especially for those designs that are new and unconventional but again depending on what you are designing, it could be both verification and validation if used to check designs, buildability and aesthetics.

Thank you all for enlightening me..
:agree1:

How do you describe your design process?

The initial BOM is an output of the design process
The activity of building a prototype verifies the BOM and intial build spec
The built prototype is an output of the initial build verification
The built protype is then maybe verified against a test specification
The tested prototype is an output of the test programme
You get the idea ....

I would agree with all the above posts *IF* you intend to collect data using the prototype. If it's just going to be used in marketing shows, then no need to jump through unnecessary hoops. If you are going to use it to, say, verify some aspects of the design, then by all means, design controls should be met.

And I would consider it a design output - something that can be used in design verification.

Hi Covers!

I'd like to know your opinion about this..
Is prototyping a design output or design verification?
I understand that during the design output, R&D engrs do mechanical drawings, schematic diagrams, electrical diagrams, BOMs to meet the input requirements. Design verification checks if the output meets the input requirements. Where does protoyping included?

I am a little confused right now..
Please enlighten me..
thanks
:thanks:

I think by now you're beginning to get the picture. It is not a simple one or the other, rather it can touch on several aspects of design. When you stop and think about it, many of the elements of design overlap each other. Design review, for example, is a part of all of the rest.

Our company is doing design on signalling devices (e.g. beacons). I get the idea of the design output and verification.
For the design output, our R&D engineers prepare schematic diagrams, mechanical drawings, BOMs and software programs. To be able to verify these outputs against the input, we build prototype of these drawings and designs and see whether it meets the required specifications. Functional testing follows according to our test plans.

Thank you for all your help!

Is the prototype not an output of the initial design process and an input into the validation process? IMO this is where Quality Management Systems tend to let us all down. We become consumed by the semantics and don't focus on the real issue of what value is added, regardless of what it is called.

I like the security and sense of "order" as much as anyone, but how much time do we spend trying to structure and pigeon hole certain aspects of what we do.

That said, please don't think I don't see this as a valuable question, we all need clarification, my opinion is that if your system effectively translates the requirements of whatever customer you have (internal or external), via your design process, your designs are validated against these requirements and the process is deemed effective and efficient to your organisation, then you can call the prototype whatever you like!

Dyeysi,

I’d like to present my viewpoint by combining a few of the thoughts already posted here. I’ll start with Mark’s comments regarding FDA’s view. FDA does not make a clear distinction between what are design requirements and design specification, especially in the realm of software. Essentially, they view Design Specifications as final design inputs. So, in this instance, the Product Specification is a Design Input deliverable, not a Design Output. It is true that other industries view it differently as do some other standards bodies.

Paul and Yodon make good points in that regardless of what we are telling you – what does your design model look like? In ours we have a process we call engineering test, which is where a design engineer does ‘sniff testing’. This is not considered formal design verification as the design is in a fluid state but essential to the development process. When an engineer is dialed in, at least to a rather solid state, he/she will develop design verification and validation test protocols to verify the design requirements and validate the user needs.

From what you describe in your latter post, the data you are collecting will be used for design verification and validation. From that perspective, your prototype should be coming from a latter stage in you design model. Perhaps first and second run prototypes are used for engineering test and third prototypes are used for most of your design verification and validation activities. Take a look at your model and confirm the point of development you are in and decide.

Regards,

Kevin

Is the prototype not an output of the initial design process and an input into the validation process? IMO this is where Quality Management Systems tend to let us all down. We become consumed by the semantics and don't focus on the real issue of what value is added, regardless of what it is called.

I like the security and sense of "order" as much as anyone, but how much time do we spend trying to structure and pigeon hole certain aspects of what we do.

That said, please don't think I don't see this as a valuable question, we all need clarification, my opinion is that if your system effectively translates the requirements of whatever customer you have (internal or external), via your design process, your designs are validated against these requirements and the process is deemed effective and efficient to your organisation, then you can call the prototype whatever you like!


Good call,

We have written a procedure specificaly calling out what a prototype is and how it should be handeled i.e. if it's used for marketing then we don't go through steps ABC, but if it may be used to validate a design aspect we go through steps ABC. Again you want to add value in everything you do so we decided that the procedure would serve this process it has also helped new engineers adapt moe qucikly in R&D.

Best regards,

al40