Are detailed engineering requirements Design Inputs or Design Outputs

[david316]

Hello,

Often with a complicated project, the user needs will get broken down in more and more detailed requirements. For example for a medical device you may end up with specific electronic, software or mechanical requirements. Are the detailed engineering requirements (which some people call engineering specifications) design outputs? Note, I am not talking about drawings etc, these are detailed requirements and are written as requirements which are then ultimately verified.

Thanks

 

[sagai]

Design inputs are the inputs that you have at the early stage of the design.
Design outputs however is the design of the device, packaging and labelling, and the DMR that is for all procedures and specifications that you have for the finished device.

So, yes, for me the Design output does contain the specifications and requirements developed over the course of design actitivites based on the design inputs.

Cheers

 

[yodon]

Indeed, I've seen the "line drawn" in different places. Some draw the line right after Product Requirements. I don't necessarily agree with that - I tend to consider, as Inputs, all those through what I consider "domain specific" requirements (e.g., Software Requirements Specifications, Labeling Requirements Specifications, etc.). Drawings, to me, are the elaboration of the requirements and thus fall into the Design Output category.

Where the line is drawn is probably not the biggest concern: showing that, indeed, the design outputs meet the design input requirements is most important.

 

[Al Rosen]

The specifications and requirements are inputs. Engineering drawings are outputs.

 

[david316]

Indeed, I've seen the "line drawn" in different places. Some draw the line right after Product Requirements. I don't necessarily agree with that - I tend to consider, as Inputs, all those through what I consider "domain specific" requirements (e.g., Software Requirements Specifications, Labeling Requirements Specifications, etc.). Drawings, to me, are the elaboration of the requirements and thus fall into the Design Output category.

Where the line is drawn is probably not the biggest concern: showing that, indeed, the design outputs meet the design input requirements is most important.

Thanks. I am coming much to the same conclusion. Although it can be confusing because often people/articles make it sound very black or white. In reality where the line get drawn seems to vary.

Followup question.....If software requirement specifications and hardware requirements specifications etc get lumped in with design outputs and we have a design review at the outputs stage to identify that all design outputs have been documented, then I would assume that we need to review those engineering specification documents are complete as well as the outputs from those documents (i.e. Software Design Description, the software, PCB schematics, etc)? Is this correct?

Thanks

 

[Marcelo]

An easy way to understand (but not always to apply):

Design input requirements are what the device has to do (the what).

Design output requirements are the answer to what, the technical solutions (the how) of how the device do what the inputs required.

 

[Mark Meer]

The way I tend to think about it is as follows:

Design outputs are all those things that you'd have to transfer to another (hypothetical) manufacturer in order for them to replicate the device.

They would NOT need the original requirement specifications (with the exception of any translated into production acceptance criteria), but they WOULD need the design drawings.

Hence, the engineering requirements would be considered design inputs, whereas all the stuff required to actually make the thing that meets those requirements (the drawings, bill-of-materials, assembly work-instructions,....) are the design outputs.

(as already stated more succinctly by Marcelo in his previous post )

 

[qualprod]

General requirements specifications are design inputs, drawings , specifications, bill of materials, isometric are outputs

 

[sagai]

It might be of my hazy memory, I cannot recall however any project when the specifications, requirements were available at the time of they would have been needed for the design activities. For Concept paper, yes, that is mostly available with a vague content of the things to be developed.
More or less 100% of the cases the specifications, requirements mature over the time with the design till it is ready for production/release (or when designers and managers had enough of doing that design ).
Further, it could also be that specification, requirements crafted after the design had been released.

So, for specification and requirements I tend not to classify those as inputs.

Cheers

 

[Mark Meer]

...requirements mature over the time...
...So, for specification and requirements I tend not to classify those as inputs.

I'm not sure I follow your logic.

True, there can be some dynamic interplay between requirements and outputs throughout the design and development process, and overtime. ...but could you not say the same thing for just about everything in the process (customer requirements, risk files, market data...)?

This being the case, I'm curious: what would you consider design inputs, if requirement specifications are ruled out on the basis that they change?