EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: fedimakni on August 19, 2024, 06:52:38 am
-
Hello,
When designing a product (from idea to design to manufacturing to maintaining the product during life cycle), what are the documents hardware engineer (mainly electronic engineer) should provide in a company?
some examples i know are:
gerber files
BOM
Schematic
Product design specification (but i don't know exactly the detailed structure of the document)
Worst case analysis (also i don't know the document structure)
Assembly steps
Could you provide me if there are other documents and if there are some templates or example document i could base on?
Thank you very much
-
You've mentioned the Design Specification, but there is also the Requirements Specification (in some companies called the Statement of Requirements - SOR).
Requirements Specification = what is wanted, Design Specification = how it will deliver what is wanted.
The Requirements Specification is the main output from the requirements capture stage of your development project, the Design Specification is the main output from the design stage.
And crucially, don't forget the Test Specification. You write this after writing the Requirements Specification and the Design Specification, because your Test Specification describes how you check that the product complies with those two documents. It also describes the "bug hunt", whereby you exercise each feature to flush out malfunctions and mistakes.
On a big product development the Test Specification might be followed up by a Test Strategy, which gives more details on how the tests are designed and executed. Most of the time you can combine them into one document. Sometimes testing is expanded out into Verification, Validation and Test (VV&T), although we are probably getting a bit deep. See the next but one post.
Different companies might use different terminology, but it's the basic principles that are important.
-
What do you mean by "Worst case analysis"?
Depending on what industry you are in, you might also need a Reliability and Resilience Analysis, describing the reliability modelling and design steps taken to deliver the required availability (eg 99.9% up-time). This covers things like diagnostics, redundancy, remote testing, anticipated MTBF (mean time between failures) and MTTR (mean time to repair). It might also include the spares strategy (eg for every hundred of your PCB/unit/widget, how many spares should be held, and where).
-
In my previous posts we've mentioned testing, but in a more formal development cycle we might want to expand that out into Verification, Validation and Test.
Validation checks that the product complies with the Requirements Specification (ie "We've built the right thing"). Verification is checking that it complies with the Design Specification (ie "We've built the thing right").
There is overlap between verification, validation and test, and I think it is easy to go too far on stuff like this. Just keep the concepts in mind when you are writing your Test Specification.
-
Finally (thank goodness!) you might be thinking what I've described is totally over the top for your needs. In many cases I would agree.
But the concepts are still valid, so it is worth spending some time thinking about how you will test the product against what the customer wants and for general bugs. It is worth spending time thinking about how you can make it easier to diagnose failures in service (error codes on a display, for instance).
Even if you don’t write separate documents for all those things, you can incorporate them as headings in one document. You don't need to write much - but trust me when I say that you will benefit from thinking about these things in a structured manner. It is up to you to decide how deep or shallow you need to go. An electronic module in an aircraft is developed and tested very differently from a colourful LED novelty toy.
-
You've mentioned the Design Specification, but there is also the Requirements Specification (in some companies called the Statement of Requirements - SOR).
Requirements Specification = what is wanted, Design Specification = how it will deliver what is wanted.
The Requirements Specification is the main output from the requirements capture stage of your development project, the Design Specification is the main output from the design stage.
And crucially, don't forget the Test Specification. You write this after writing the Requirements Specification and the Design Specification, because your Test Specification describes how you check that the product complies with those two documents. It also describes the "bug hunt", whereby you exercise each feature to flush out malfunctions and mistakes.
On a big product development the Test Specification might be followed up by a Test Strategy, which gives more details on how the tests are designed and executed. Most of the time you can combine them into one document. Sometimes testing is expanded out into Verification, Validation and Test (VV&T), although we are probably getting a bit deep. See the next but one post.
Different companies might use different terminology, but it's the basic principles that are important.
In my experience / background, the Requirements Specification should be produced by the Marketing team (you need something to pin the b*** down!). The Engineering team then produce the Functional Specification, which defines (in detail) what will be produced. The two are reviewed against each other, and then the Engineering team produce the Design Specification, which defines how it will be implemented, before implementation.
-
The EE may also have to decide what EMC/CE testing is needed and when and where to get that done. Lots of documents there, plus certain things have to be included in the customer manuals. In a perfect world you'd like to have a compliance engineer, but most places can't afford that.
-
If it’s hardware that someone is going to write software to drive, you should create a Programmer’s Notes document. This should include the relevant information and exclude the irrelevant information
-
Block diagram: Useful for others in your organization, or your successor, to understand functional blocks in your design -- It can be quite difficult to open up a schematic and figure out the intent of everything, especially when schematic styling differs from your own preferences.
DFMEA: Maybe this is part of your worst case analysis, but depending on the criticality of the application, you may want to analyze what happens when certain subsystems or components fail. If it's a non-critical widget, you probably don't worry about this much. But, even a pointless widget with a lithium-ion battery has some risk associated with it.
Component stress analysis: Similar to the above, depending on the criticality of the application, you may want to go through and ensure all parts are operating within their specified limits. (e.g. voltage rating of a diode or capacitor versus actual applied voltage, power dissipated in a resistor vs. rated, etc.) Some amount of derating should be applied to manufacturer limits. Regardless of criticality of the application, a component stress analysis is good practice, as it forces you to make a methodical assessment, as opposed to just "ballparking" the design and crossing your fingers. MTBF, MTF, and MTTR are related analyses, with MTBF being most popular (I think). Some industries/companies like to know these figures. In my opinion, if you are not doing any other reliability analysis, just do a component stress analysis - make sure you're at least not exceeding the limits of any individual component.
-
Some good stuff there. One thing I would add: don't write unnecessary documents. Especially, there's a lot of stuff around reliability and durability that simply might not be important enough to your customer, or your business. You don't need to do a failure modes and effects analysis (FMEA) unless you are told it is required. Ditto with failure rates, MTBFs, spares strategy, etc.
There's a real danger of "paralysis by analysis", and it is a genuine problem that wastes loads of money.
One question you should ask before writing every document: realistically, is anyone likely to read it? If it's an aircraft part, then it's probably "yes" (not a good example, actually, because aerospace is very tightly nailed down); if it's a cheap gadget, probably not. The documentation should be appropriate and necessary.