Documents hardware engineers should write and prepare

Assuming that you are developing some manner of electronics product, which will contain a PCB, some mechanics and maybe software, then these are the various forms of documentation that need to be provided, from the electrical engineer's perspective:

• Product specification (mandatory). Written by the project manager and/or engineers, for the benefit of engineers (a technical document). When done correctly, this should be a live document to revisit and update. It should also be the foundation from which all product testing is based upon.

  May be as detailed or as brief as required, depending on the product. In case of safety-related products, you would also do a risk assessment early on to determine what safety functions there are and these need to be listed in the specification.

• Time schedule and budget (optional). Written by the project manager, if there is one. Otherwise engineers are often expected to write this. Often you write a document with a time frame and deadlines. If there's a development cost budget, this needs to be made clear early on by the manager, as it may affect tool choices etc. Engineers also need to know an estimate of manufacturing cost/unit.

• Schematics and Bill of Materials (BoM) (mandatory). Component selections should be based on the specification. Electrical engineers are responsible for most/all of it. If there are dedicated software engineers, they are often responsible for picking MCU + programming tool chain and MCU pinout. As an engineer, you must be able to have a rationale for why every single component was picked.

  The schematic must be available in pdf and ideally made in the preferred EDA, so that it is connected to the layout. There must be a part number for all component 1st source and ideally also 2nd source.

  References to RoHS compliance and similar might have to be part of the BoM.

  There may be a complete product BoM including mechanical parts and then the PCBA is usually listed as single component/subsystem in that one.

• PCB layout + manufacturing files (mandatory). Made by the electrical engineer(s) in an EDA. A board outline pdf with component placement should be available to everyone.

  For PCB manufacturing, PC files must be generated from the EDA regarding the PCB "stack-up" layers, drill holes/vias, mechanical outlines, silk screen etc etc ("gerber files" is a an industry standard for all of this). For assembly, "pick & place" files in case of SMD are also required.

• Design documentation (mandatory/optional). Ought to be mandatory but this comes in diverse forms, if at all. Some documentation regarding how the product was designed, how it works, what supply and inputs/outputs it can handle etc. How detailed it is might depend on the complexity of the product. There are different audiences for such documentation: development/test engineers, test houses/authorities and production staff.

  • For development/test engineers (including yourself in the future) it can get deeply technical and as detailed as required. For test houses, they need a product overview about how the product works, what it does and what's the intended environment. Both internal and external product tests would be based on this, as well as the specification. How tests are to be carried out and the results of the tests should be documented, but by whom depends on the organization.

  • Authorities expect a technical file, which is essentially all of the mentioned documents here together.

  • The production needs to know assembly instructions, programming and calibration instructions etc.

• Product conformance documentation (mandatory). This would be test reports from a test house, or your in-house equivalents if allowed/applicable. Depending on where in the world the product is used, you will need a FCC/CE etc declaration of conformity mentioning which parts of product directives and/or standards it conforms to.

• User manual (optional). This may be written by engineers or by other staff, but at least the engineers are expected to provide raw technical input to it. If the previously mentioned designed documents are detailed/suitable enough, they may act as that input.

Coming from the space industry, I'd be tempted to throw a huge list but my personal picks for most projects regardless of the industry would be:

• Derived requirements, where you translate what you need to do into how the product is going to do it in practice - think about how each requirement will be verified by inspection, analysis, or test.
• Architectural diagram (can be your schematic top sheet if it's a hierarchical diagram)
• Interface control document, or call it however you want but define all your electrical and potential software interfaces as if you were the one using this product without prior knowledge of it. User manual would be ideal but we're sticking to must-haves here.
• Design justification document, or design notebook or anything where all the justifications and calculations of your design are made. The worst case analysis can be part of it.
• Statement of compliance, or anything that says which requirements are met, partially met, or not met in your own derived requirements, and why. This closes the loop. If your derived reqs have been made correctly and you met them all, you know you meet the user requirements. This document can serve as a non-user-friendly datasheet since partial compliances and non compliances should say what is actually achieved.

As for the release files:

• Gerber and NC drill
• Bill of material, preferably in a format which can be imported by your PCB house for automatic assembly
• Pick and place file if applicable
• Interactive PDF of your schematic so that not everyone has to open the project every time
• Snapshot of your project (or tag in Git for example) to get back to it as it was produced if necessary

You may need an assembly procedure depending on how intricate your electronics product is, but in most cases for prototyping/development you could merge this with the design notebook that's structured to say how things should be done and leaves a place to say how it went.

A step file may be required if someone else makes the enclosure.

If you're asking this with customer delivery in mind, you may be interested in the term End Item Data Package which is the bundle that you would be looking for.

There are many others of course but I consider these essential. Then it's up to quality assurance, project managers, team leaders etc to define these processes company/department-wide or on a project basis, or by default to yourself to determine add-hoc what's needed.