Before a product can be built, someone has to understand what it is made of. The information lives in a set of documents: specifications that define what the product must do, design files that define how it is put together, and a Bill of Materials (BOM) that lists every part to be bought, placed, and tested. Engineers who can read these documents accurately prevent expensive mistakes. Engineers who cannot read them tend to discover the mistakes in the factory, in test, or in the field.
This article is for software engineers, test engineers, and engineering managers who work close to hardware or manufacturing. It explains how to read a technical specification, how a BOM is structured, what design documentation should answer, and how to check a BOM for common errors with a small Java model.
Reading a technical specification
A specification describes what a product must do and the limits within which it must do it. A good specification separates three kinds of statement:
- Requirements, which say what the product must do. For example, "the sensor shall report temperature with an accuracy of ±0.5 °C between 0 and 60 °C."
- Constraints, which limit the design. For example, "the device shall operate from 9 to 15 V DC" or "the enclosure shall be IP54."
- Verification methods, which say how each requirement will be checked: test, analysis, inspection, or demonstration.
When you read a specification, look for statements that cannot be verified. Words such as "robust," "fast," or "user friendly" are not requirements until they are given a number and a test. Look also for conflicts. A requirement for a wide operating temperature range may conflict with a requirement for a low-cost capacitor family, and that conflict should be raised early, not during qualification.
Pay attention to units, tolerances, and conditions. "5 V" is incomplete. "5 V ±5 % at 25 °C, 500 mA maximum load" is a requirement that a test engineer can use.
What a BOM really contains
A Bill of Materials is the list of parts required to build one unit of a product. In its simplest form, it has one line per part, with a reference designator, a part number, a description, a quantity, and sometimes a supplier. The reference designator, such as R12 or U3, identifies where the part sits on the board.
A useful BOM is more than a list. It is a link between design, procurement, manufacturing, and test:
- Design uses the BOM to confirm which component values and packages were chosen.
- Procurement uses it to order parts, check lifecycle status, and find alternates.
- Manufacturing uses it to program pick-and-place machines and kit materials.
- Test uses it to know which components must be measured and what their limits are.
The same BOM is often used by four teams, and each one notices different errors. That is why BOM quality is a shared responsibility.
Hierarchy and revisions
Most products are built from assemblies within assemblies. A top-level product may include a power board, a sensor module, and an enclosure. Each of those may have its own BOM. Good practice is to keep the hierarchy explicit, so that a change to a sub-assembly is visible at the product level.
Revisions matter just as much. A part number is not enough if the design has changed. Every BOM should be tied to a specific design revision, and every change should record what changed and why. A common and expensive failure is building boards with the new design but the old BOM, or the reverse.
What design documentation should answer
Design documentation explains how the product is built and why. It should answer questions that a BOM cannot:
- Why was this component chosen over the alternatives?
- What are the critical tolerances, and which parts drive them?
- What are the thermal, power, and signal-integrity assumptions?
- Which parts are single-sourced, and what is the plan if they go obsolete?
- What must be true for the product to pass its tests?
Design documentation that answers these questions helps the next engineer understand the trade-offs. Documentation that only restates the schematic is less useful, because the schematic already says what is connected. The rationale is what is missing most often.
Checking a BOM for errors
Many BOM errors are simple and preventable. Typical examples include:
- The same reference designator used twice.
- A part number that is not in the approved parts list.
- A quantity that does not match the number of reference designators.
- A component marked as obsolete or end-of-life.
- A missing value, package, or tolerance.
Checks like these are good candidates for automation. The following Java model reads BOM lines and flags duplicate reference designators, quantities that do not match the designator count, and missing critical attributes. It does not replace engineering judgment, but it catches the mechanical mistakes before a person reviews the design.
import java.util.ArrayList;
import java.util.HashSet;
import java.util.List;
import java.util.Set;
public class BomCheck {
public record BomLine(
String refDesignators, // e.g. "R1,R2,R3"
String partNumber,
String description,
String packageType,
String tolerance,
int quantity,
boolean lifecycleActive) {}
public record Finding(String severity, String message) {}
public static List<Finding> check(List<BomLine> bom) {
List<Finding> findings = new ArrayList<>();
Set<String> seenRefs = new HashSet<>();
for (BomLine line : bom) {
List<String> refs = List.of(line.refDesignators().split("\s*,\s*"));
if (line.quantity() != refs.size()) {
findings.add(new Finding("ERROR", line.partNumber()
+ ": quantity " + line.quantity()
+ " does not match " + refs.size() + " reference designators"));
}
for (String ref : refs) {
if (!seenRefs.add(ref)) {
findings.add(new Finding("ERROR", "reference designator " + ref + " appears more than once"));
}
}
if (line.partNumber() == null || line.partNumber().isBlank()) {
findings.add(new Finding("ERROR", "line for " + line.refDesignators() + " has no part number"));
}
if (!line.lifecycleActive()) {
findings.add(new Finding("WARNING", line.partNumber() + " is not active; plan a replacement"));
}
boolean needsTolerance = line.refDesignators().startsWith("R") || line.refDesignators().startsWith("C");
if (needsTolerance && (line.tolerance() == null || line.tolerance().isBlank())) {
findings.add(new Finding("WARNING", line.partNumber() + " has no tolerance specified"));
}
}
return findings;
}
public static void main(String[] args) {
List<BomLine> bom = List.of(
new BomLine("R1,R2,R3", "RC0603FR-0710KL", "10k resistor", "0603", "1%", 3, true),
new BomLine("C1,C2", "GRM188R71C104KA01", "100n capacitor", "0603", "", 2, true),
new BomLine("R3,R4", "RC0603FR-0722KL", "22k resistor", "0603", "1%", 3, false),
new BomLine("U1", "", "Regulator", "SOT-223", "", 1, true));
for (Finding f : check(bom)) {
System.out.println(f.severity() + ": " + f.message());
}
}
}
Running this model on the sample BOM flags five issues. R3 appears on two lines, so the reference designator is duplicated. The 22k resistor line declares a quantity of 3 but lists only two designators, R3 and R4, so the quantity does not match the placement. The capacitors have no tolerance specified. The 22k resistor is marked as inactive, so procurement needs an alternate. The regulator has no part number at all. Each finding is simple, and together they show why a mechanical check is worth running before a review meeting.
The model cannot tell whether 10k is the right value for the circuit. That judgment belongs to the engineer who read the specification and understands the design.
Reading design documentation as a software engineer
Software engineers often read code faster than schematics, and that skill transfers well. A few habits help:
Trace from requirement to implementation. Pick one requirement and follow it through the design files, the BOM, and the test procedure. Gaps appear quickly when you do this.
Treat tolerances like input validation. A component value is an input to a function, and its tolerance defines the valid range. Ask what happens at the edges.
Ask what would fail first. In software, you ask which dependency breaks under load. In hardware, ask which part degrades first under heat, voltage stress, or time.
Look for implicit assumptions. Documents often assume a supply voltage, an ambient temperature, or a connector type that is not written down. Writing them down is a valuable contribution.
Practical guidance for engineering leaders
When your team designs or supports a hardware product, ask:
- Does every requirement have a verification method and a test that can fail?
- Is each BOM tied to a specific design revision, with a record of changes?
- Are single-source and end-of-life parts identified, with a plan for each?
- Does design documentation explain the trade-offs, not only the connections?
- Are BOM checks automated before review, so people spend their time on design judgment?
If several answers are no, the risk is not in the design alone. It is in how the design is communicated to the people who will build and test it.
Key takeaways
Interpreting technical specifications, BOMs, and design documentation is the skill that connects an idea to a product that can be built and tested. Read specifications for verifiable requirements and conflicts. Treat the BOM as a shared contract between design, procurement, manufacturing, and test, and keep it tied to a revision. Capture the rationale behind design decisions, and automate the mechanical checks so that human review focuses on judgment. For software engineers, the same habits that make good code reviews, traceability and explicit assumptions, apply directly to hardware.
Top comments (1)
tr.ee/dev-to