Design Inputs Document Content

[Qualbert]

Hello,

I've spent the last two days reading this nice forum but I could not find an answer to my questions:

1)
Should the requirements/specs/tests/etc, be put in the design input document or should there be a separate document for that?

If we have separates requirements document, specification document, verification document and validation document, what remains in the Design input document ?

2)
a) Let say I have a requirement that say "the device display should be readable by color blind people"

b) Then I do a research to find which color combinations are OK and I chose those colors.

c) I have then a specification which would be "The device display should use color pantone XXX for the background and pantone YYY for the foreground display"

a) is the requirement, c) is the specification but what about the work done in b), where does it goes in term of documentation?


Thanks in advance for your answers,

Regards

 

[somashekar]

Hello,

I've spent the last two days reading this nice forum but I could not find an answer to my questions:

1)
Should the requirements/specs/tests/etc, be put in the design input document or should there be a separate document for that?

If we have separates requirements document, specification document, verification document and validation document, what remains in the Design input document ?

2)
a) Let say I have a requirement that say "the device display should be readable by color blind people"

b) Then I do a research to find which color combinations are OK and I chose those colors.

c) I have then a specification which would be "The device display should use color pantone XXX for the background and pantone YYY for the foreground display"

a) is the requirement, c) is the specification but what about the work done in b), where does it goes in term of documentation?


Thanks in advance for your answers,

Regards

Very Interesting ... and a good opening post Qualbert, Welcome to the Cove ~~~

"the device display should be readable by color blind people"

This is a very simple and clear design input.
Further ... The device display should be readable in the dark., can be an other input.
And such other that determines what is desired considering the primary purpose and secondary purposes together with statutory / regulatory requirements, safety requirements.
Ex. The device must have a provision of a lanyard., can be an other design input based on secondary purpose.

Next:
All that goes into your scrap book, your spread sheet, your sticky notes, your favorites in the PC and all that remains processed and active in the grey matter of your brain is the research. Who is asking you research documentation ? Share your knowledge and all that is said above for having done your research, for you are competent to be doing the design and development and research is built in it.
Good luck ~~~

 

[Qualbert]

Hello somashekar,

Thank you for your prompt answer!

Now what if the requirement is "The software should be usable on 80% of the computers in the world"

I will have to find statistics from several sources to know the repartition of the screen resolution worldwide, I will have also to find informations about OS, Ram, Processors etc... This will take a lot of time and it will require that I gather informations from a lot of sources around the web to achieve to the following specifications:

"The software should display on at least a 1024x768 screen"
"The software should have a memory footprint lower than 50Megas"
Etc...

You mean that the statistics, the sources and everything I find during my research above should not be officially documented anywhere else than in my lab notebook?

And what about my other question of my initial post, are the user requirements and the specifications part of the Design Input? If yes how should look this Design Input file? Should it just point to the Requirement document and the specification document?

Best regards,

Qualbert

 

[somashekar]

When the design input is as hazy as this, the design output would be more hazy. If this is an internal design input, question it as to what 80% means, as no one ever knows what version and processor population constitutes the total working computers the world over. Even as you progress with your design stages, your input begins to change. What you find as 80% today will not hold water as your design progresses.
If it is an external input, ask more details what they mean by 80%, such that the below:

"The software should display on at least a 1024x768 screen"
"The software should have a memory footprint lower than 50Megas"

becomes the design input.
Like : It must work on windows 93 or higher version. The graphic card must be xyz123 or better ...and so on. This brings clarity.
Hazy input, design doomed >>>

You mean that the statistics, the sources and everything I find during my research above should not be officially documented anywhere else than in my lab notebook?

What you mean by officially documented ?
When a design output is reviewed (which in your terms is officialy documented), in the design review process, the reasons and calculations and considerations etc that you have applied in your research is brought out by you and the first output (call it as draft 1) is either going to be fine tuned to draft 2, or output proceeds to design verification >> validation steps.
Permit me to say that the research papers, calculations sheets, iterations, notes that you write as you figure out something, computer model rundowns, etc., are not required to be any controlled documents.

 

[Qualbert]

OK I get it on this point, thank you. But I still don't understand exactly what I should add in the desin input document:

Actually at our company we have the following documents attached with our product:

Requirements (which is the list of all requirements)
Specifications (which is the list of all specs that are coming from the requirements)
Verification (which verfies every specification)
Validation (which validates the use of the device by an end user)
Risk analysis

We don't have a Design Input document so my question is what should I put in the Design Input document? In my mind the design input is just the combination of the requirement document and the specfication document. Am I missing something?

Best regards

 

[somashekar]

Requirements (which is the list of all requirements)

You have it here ~~~
What is all requirement ?
As much as you have been able to consider based on the primary purpose and secondary purposes of the product, the target region, target population, target cost, marketing inputs, competator products features, statutory and regulatory requirements, ...
More questioning and more realistic brainstorming along with learnings from previous design collects together to make a good design input.

Take it as a set of several bulletted points if you wish to see how design input looks like .....

Do not worry if this is not all that comprehensive. Do a best effort and kickstart the design process. A few of design input changes begins to happen at an early stage of design progress. Amend the design inputs and the plan as and when necessary.
Bear in mind that the product cost is an important design input that must be considered with all design changes.

 

[Qualbert]

You have it here ~~~
primary purpose and secondary purposes of the product, the target region, target population, target cost, marketing inputs, competator products features, statutory and regulatory requirements, ...
More questioning and more realistic brainstorming along with learnings from previous design collects together to make a good design input.

For me all of this above end up being requirements (User requirements, functional requirements, system requirements, company requirements, etc...) so I don't really see a difference between a requirement list + a specification list and the desing input document.

So if I want to create the so called "Design Input" document, I need to compile my requirements and my specifications?

 

[somashekar]

For me all of this above end up being requirements (User requirements, functional requirements, system requirements, company requirements, etc...) so I don't really see a difference between a requirement list + a specification list and the desing input document.

So if I want to create the so called "Design Input" document, I need to compile my requirements and my specifications?

Input, Requirement, Specification (Confusion)
Input = Requirement, Output = Specification (Clarity)
Review, Verify, Validate to ensure specifications meet requirements (output meets input)

Input >> Research >> Output (draft) >> Review >> Verify > Validate >> Output (Final release) -- All considered in a Design and development plan >> Design changes.

 

[Qualbert]

Ok thank you, it is getting much clearer for me now!

One last question, what do you mean by specifications? In what I've understood the requirements are the "what" and the specifications the "how" so for me the specifications is what I will give to the engineer that will do the work (like coding the software or drawing the mechanical parts, etc.).

In what I understood these specifications would be input and the source code, the mechanical drawings, etc. would be output, am I wrong?

 

[somashekar]

Wait a minute ...
There is nothing like last question. You can ask as much and people here would respond as much, so that you get views and opinions from diversed field.
Now

so for me the specifications is what I will give to the engineer

NO. Inputs are what you give to the engineer that will do the work to give you specifications, which once translated into product or service meets the input.
You: Hey, I want the shoe to meet all sizes.
Engineer : Ok, Adults, Kids ?
You : Adults
Engineer : Ok, Men or Women ?
You : Men.
Engineer : Ok, Country ?
You : UK
Engineer : Here take the UK shoe sizes 6,7,8,9,10. Under specific order we can make size 11 also.
You : Your requirements have been met by a specification