Product Specification Sheet

About this template

A specification is a document two teams have to read the same way

Design writes it, quality assurance tests against it, and a supplier is paid on it. The form is arranged so that a value cannot be written without the conditions under which it holds. The label above the title reads Product specification, the gray line under it reads “Complete it in order, from Scope and terms through Revision history”, and the approval row ships as Prepared (design), Reviewed (quality assurance), Approved (head of development). The page runs label, title, gray lead, a four-cell information table, three numbered sections, Key metrics, and Confirmation and approval.

Filling order

1. Fill the four information cells: Product · Model, Spec version, Effective date and Prepared · Reviewed. They ship as Sensor Module SM-240, SPEC-2.1, 2026-05-01 and Design Team / Quality Assurance Team. The version and the effective date are the pair that matters – a specification with no effective date cannot settle an argument about which revision applied to a shipment.
2. 1. Scope and terms first. Everything below is meaningless until it is clear what the document covers.
3. 2. Functional and performance specifications next, one value per line with its unit and tolerance.
4. 3. Test and inspection criteria last, so each criterion points back at a value written in section 2.
5. Fill the Key metrics table and print the approval row empty for signature.

How the three sections read

• Scope and terms. Models covered and what is excluded, referenced standards and test standard numbers, and definitions for the terms that get confused. The exclusion line is the one that saves the argument later; naming the models the specification does not cover is worth more than naming the ones it does.
• Functional and performance specifications. “Every value carries a unit and a tolerance.” Give the rated value with its minimum and maximum limits, state the measurement conditions – voltage, load, time – and give the operating temperature and humidity conditions. A number with no measurement condition is not a specification; two labs will read it differently and both will be right.
• Test and inspection criteria. Pass criteria and sample size for each test, a clear split between 100% inspection and sampling inspection, and the handling of non-conformities together with the conditions for a retest. Write the retest rule before you need it. Agreed under pressure, it always favors whoever is in a hurry.

The four metric cells

Key metrics is a two-row, four-column table with values on top: DC 12V / Rated voltage, ±2% / Measurement error, -20~60℃ / Operating temp., 36 months / Warranty. These are a summary, not the specification itself – each has to appear again in section 2 with its measurement conditions attached. The warranty cell is the one to check against the contract rather than against the design, since the number that governs is the one in the agreement. Word does no arithmetic and no unit checking, so changing a value in the body leaves this table untouched.

Revision history

The gray lead runs through to revision history, and the version cell at the top is where that history is anchored. Bump the version whenever a value, a tolerance or a test condition changes, keep the previous revision rather than overwriting it, and record what changed and why in one line. A supplier holding SPEC-2.0 needs to know which values moved in 2.1, not that a new file exists. Where a change affects parts already produced, say in the same line whether it applies from the effective date onward or retrospectively – that sentence is the one purchasing and quality will both quote.

Before it is issued

• Values with units but no tolerance. The form asks for both on every line.
• Citing a standard by name without its number, which leaves the edition open.
• Leaving the sample model and version in the header while the values below are already your own.
• Writing a pass criterion that has no sample size, so the same test result can pass or fail depending on who ran it.
• Changing a value without moving the version, which leaves two documents with the same name and different numbers.