Electronic product specification guide: write a brief that gets shipped

Why a strong specification makes the difference

An electronic product specification is the founding document of any hardware development project. It formalises the expectations of the product owner, structures the dialogue with the electronic design house, and serves as the contractual reference throughout development. Contrary to a common belief, this is not paperwork: it is the single artefact every downstream decision hangs on.

An incomplete or ambiguous specification is the leading cause of failure in outsourced electronic projects. At AESTECHNO, we have observed that projects with a well-structured specification reach their objectives faster, with fewer iterations and far fewer surprises. Conversely, a vague document generates costly back-and-forth, miscommunication, and sometimes products that simply do not match expectations.

In 2026, with the growing complexity of connected products and tightened regulatory requirements (Radio Equipment Directive (RED), Cyber Resilience Act (CRA), cybersecurity), a rigorous specification is no longer optional. This guide walks you through writing a document that lets your design house understand your needs precisely and propose a fitting solution.

Key takeaways

What is an electronic product specification?

An electronic product specification consists of describing exhaustively, in a technical and functional document, the expected characteristics of an electronic product (performance, conditions of use, regulatory requirements, deliverables). It serves as the contractual reference between the product owner and the design house, defining the objectives, constraints and validation criteria of the project. According to ISO in ISO/IEC/IEEE 29148, an electronic product specification aligned with the state of the art must satisfy the properties of uniqueness, traceability, testability and non-ambiguity for every requirement.

An effective specification fulfils several essential functions:

• Communication: it translates your business needs into technical requirements that engineers can act on
• Scoping: it bounds the project perimeter and prevents objective drift
• Reference: it provides the basis for validating deliverables and arbitrating disagreements
• Estimation: it lets the supplier evaluate workload precisely

The 8 essential sections of a specification

A complete electronic product specification covers eight key domains, from project context to expected deliverables. Each section provides essential information that lets the design house propose a suitable technical solution, price the project and anticipate risks.

Section	Goal	Key items
Context and objectives	Frame the project	Market, volumes, schedule, budget
Functional description	Define the need	Use cases, MoSCoW prioritisation
Technical specifications	Quantify performance	Voltages, throughput, autonomy, accuracy
Environmental constraints	Define operating conditions	Temperature, IP rating, vibration, EMC
Mechanical constraints	Define integration	Dimensions, connectors, thermal
Regulatory requirements	Ensure compliance	CE/RED, sector standards, cybersecurity
Production constraints	Ensure manufacturability	Volumes, sourcing, testability
Expected deliverables	Define outputs	Documentation, source files, IP

1. Project context and objectives

This section sets the general framework and lets the design house understand the "why" before the "how". It must include:

• Company presentation and core business
• Market context: positioning, competition, intended differentiation
• Business objectives: forecast volumes, target markets, target unit cost constraints
• Target schedule: key milestones, intended go-to-market date
• History: previous versions, existing prototypes, field reports

This framing lets the supplier propose solutions adapted to your commercial reality, not just the technically optimal ones.

2. Functional description

The functional description answers the question: "What must the product do?". It must be written from the user's perspective, without presupposing technical solutions.

• Main use cases: concrete usage scenarios
• Primary functions: what the product absolutely must do
• Secondary functions: desirable but non-critical features
• User interfaces: buttons, screens, LEDs, audio feedback
• Operating modes: standby, active, configuration, update

We recommend the MoSCoW method to prioritise features: Must have (essential), Should have (important), Could have (desirable), Won't have (out of scope). If your product embeds firmware, also detail the firmware requirements: communication protocols, OTA updates, diagnostic modes.

3. Technical specifications

This section drills into expected performance. It must be quantified as much as possible, with minimum, nominal and maximum values. At AESTECHNO, we systematically recommend specifying the measurement conditions for each parameter, because the same value can mean very different things depending on context. In our practice, on a recent industrial sensor project, we have observed that a "3 year" autonomy figure stated without a mission profile or average temperature had to be revised after the first climatic chamber tests. Junction temperature varied from 25 degC (lab) to 55 degC (customer site), which significantly changes quiescent consumption and therefore real-world autonomy.

• Electrical performance: voltages, currents, power, efficiency
• Communication performance: throughput, range, latency, protocols
• Compute performance: processing capacity, memory, storage
• Autonomy: battery operating time, charge cycles (see our guide on embedded power management to optimise this parameter)
• Measurement accuracy: for sensors, acceptable tolerances

For each specification, state the measurement conditions. A "24 hour" autonomy does not mean the same thing in standby as under intensive use.

4. Environmental constraints

The operating environment heavily constrains design choices. An industrial product and a consumer product do not share the same requirements. According to IEC in the IEC 60068 series, climatic and mechanical tests are standardised by stress type, and according to ETSI in its guidelines, RF environments require a documented coexistence analysis.

• Temperature: operating and storage range (reference IEC 60068-2-1 cold, IEC 60068-2-2 dry heat)
• Humidity: water exposure, condensation, required Ingress Protection (IP) per IEC 60529
• Vibration and shock: applicable standards (IEC 60068-2-64 random vibration, IEC 60068-2-27 shock, MIL-STD-810 military)
• Electromagnetic environment: expected disturbances, coexistence (EN 55032, EN 55035)
• Chemical constraints: UV exposure, corrosive products, salt spray (IEC 60068-2-11)

For more on EMC topics, see our article on electromagnetic compatibility.

5. Mechanical and integration constraints

The electronic board fits inside a complete product. Mechanical constraints must be defined precisely to avoid surprises during assembly.

• Maximum dimensions: available footprint for the board
• Shape: geometric constraints, keep-out zones
• Connectivity: connector types, positions, orientations
• Mounting: fixing points, thermal constraints
• Thermal dissipation: thermal budget, cooling solutions

If the enclosure is already defined, supply the 3D CAD files. If the design house must design the complete product, state the aesthetic and ergonomic constraints. For complex boards, see our article on PCB design fundamentals, which details routing and stack-up constraints.

6. Regulatory and normative requirements

Regulatory requirements are not optional. A non-compliant product cannot be legally placed on the European market. According to the European Commission, CE marking is mandatory for any radio product placed on the EU market, and according to ETSI in the harmonised standards published in the Official Journal, RED conformity relies on standardised tests (EN 300 328, EN 300 220).

• CE marking: applicable directives (RED 2014/53/EU, LVD, EMC, RoHS)
• Radio certifications: RED in Europe, FCC Part 15 in the US per the Federal Communications Commission, other markets
• Sector standards: medical (IEC 62304, IEC 60601-1), automotive (ISO 26262), railway (EN 50155)
• Cybersecurity: RED article 3.3 requirements, ETSI EN 303 645, Cyber Resilience Act (CRA) and NIS2 directive per ENISA, Software Bill of Materials (SBOM) inventory in CycloneDX or SPDX format, Common Vulnerabilities and Exposures (CVE) handling policy and Coordinated Vulnerability Disclosure (CVD) procedure (see our coverage of IoT cybersecurity)
• Environmental: WEEE, batteries, restricted substances (RoHS 3)

Our guide on CE/RED certification for IoT products details the steps and requirements for connected products.

7. Production constraints

A brilliant design that cannot be mass-produced has no value. Production constraints must be integrated from the design stage.

• Forecast volumes: annual quantities, ramp-up
• Production location: France, Europe, Asia
• Sourcing constraints: imposed or forbidden components (anticipate shortage risks at this stage)
• Testability: production test requirements
• Traceability: serial numbers, version control

For a deeper dive, see our article on Design for Manufacturing (DFM).

8. Expected deliverables

Define precisely what you expect as deliverables at each phase of the project:

• Documentation: schematics, bills of materials, fabrication drawings
• Source files: PCB project, firmware source code
• Prototypes: quantities, finishing levels
• Reports: validation tests, conformity measurements
• Industrial transfer: production package, training

Also clarify intellectual property: who owns the designs, the source code, the manufacturing files? To anticipate the unexpected, include a risk analysis at this stage.

The most common mistakes to avoid

A poorly written specification is the main source of schedule slips, cost overruns and disputes in electronic design projects. Identifying these mistakes upstream lets you correct them before they become real problems mid-development.

In our practice, the most frequent mistakes we see at our clients are usually tied to weak initial scoping rather than to lack of technical skill. Contrary to intuition, projects that derail mid-way do not do so because of an unforeseen technical difficulty: they fail because the initial specification left grey zones nobody had ruled on. We have tested this hypothesis on several customer projects we picked up mid-stream: in 8 cases out of 10 (informal sample), the root cause of the blockage was documentary, not technical.

Mistake 1: confusing solution and need

A specification must express needs, not impose solutions. Writing "use an STM32F4" closes doors that could lead to better answers. Prefer "compute capacity sufficient to run a 1 kHz filtering algorithm".

Mistake 2: underestimating regulatory constraints

Certification is not an administrative formality at the end of the project. It is a technical constraint that deeply impacts design. Ignoring it at the specification stage leads to expensive redesigns.

Mistake 3: omitting edge cases

What happens if the battery is empty? If the network connection is lost? If the user mishandles the device? Behaviours under errors or degraded conditions must be specified.

Mistake 4: neglecting upgradability

An electronic product lives for several years. Plan for future evolutions: added sensors, new features, firmware updates. A well-thought capacity margin avoids redesigning everything later.

Mistake 5: lacking precision on priorities

If everything is a priority, nothing is. Use a clear prioritisation method and own the trade-offs. A product that does 5 things well beats a product that does 15 things badly.

Real cases we have observed in the lab

• Case 1: incomplete EMC clauses. On a recent project, the specification mentioned "CE compliance" without naming the applicable standards (EN 55032 vs EN 55011, class A vs class B). According to Cenelec in its application notes, class B is mandatory for any residential environment, which lowers emission limits by roughly 10 dB compared with industrial class A. The product passed the radiated emissions pre-qualification but failed conducted immunity. Contrary to intuition, writing "CE" is not enough: you must name the standards, classes and target environments. We recommend explicitly listing EN 55032 / EN 55035 / EN 61000-6-x in the specification.
• Case 2: under-specified temperature range. "Industrial use" was read as -20/+70 degC by the writer and +85 degC by the design team. The component and PCB trade-off (standard FR-4 vs High-Tg) had to be reopened. We always recommend a numbered range with an explicit margin.
• Case 3: missing mission profile. A specification mentioning "10-year service life" without a usage profile makes MTBF sizing, electrolytic capacitor selection and battery strategy impossible. An hourly/yearly mission profile is non-negotiable.

Standards and tools to structure a professional specification

Writing an electronic product specification benefits from leaning on proven references. ISO/IEC/IEEE 29148 (Requirements Engineering) defines, according to ISO, the canonical structure of requirements (unique, traceable, testable), and IEEE 830 remains, according to IEEE, the reference for the embedded Software Requirements Specification (SRS). According to Jama and according to Polarion in their traceability white papers, mature teams use JAMA Connect, Polarion ALM or IBM DOORS for requirement-to-test-to-deliverable traceability; for lighter projects, Jira with a requirements plugin, Notion or Confluence are sufficient. In our practice, the choice is not the tool but the discipline of versioning and cross-review.

Contrary to what you read on LinkedIn

Contrary to what you read on LinkedIn, a 40-page specification is not necessarily better than a 15-page one. We have seen sprawling documents diluted by useless copy-paste, and short but surgical specifications produce better outcomes. The quality criterion is not volume but the density of testable requirements: one requirement per line, each measurable, traceable to an acceptance test. At AESTECHNO, we prefer iterating three times on a well-calibrated 20-page brief over absorbing an 80-page block no engineer will read end to end.

Checklist: is your specification complete?

This checklist captures the essential points to verify before sending your specification to a design house. A document that ticks every box maximises your chances of receiving precise, comparable proposals matched to your real need.

Context and objectives

• ☐ Company and project presentation
• ☐ Business objectives and forecast volumes
• ☐ Schedule and key milestones
• ☐ Indicative budget (acceptable range)

Functionality

• ☐ Detailed use cases
• ☐ Prioritised functions (MoSCoW)
• ☐ Defined user interfaces
• ☐ Behaviour under errors

Technical specifications

• ☐ Quantified performance with tolerances
• ☐ Stated measurement conditions
• ☐ Defined communication interfaces
• ☐ Autonomy and energy management

Environment

• ☐ Temperature ranges
• ☐ Required IP rating
• ☐ Vibration and shock
• ☐ EMC constraints

Mechanical

• ☐ Dimensions and shape
• ☐ Connectors and interfaces
• ☐ CAD files if available
• ☐ Thermal constraints

Regulatory

• ☐ Identified target markets
• ☐ Listed applicable directives
• ☐ Required sector standards
• ☐ Cybersecurity requirements

Production

• ☐ Volumes and ramp-up
• ☐ Manufacturing location
• ☐ Sourcing constraints
• ☐ Testability requirements

Deliverables

• ☐ Expected documentation
• ☐ Clarified intellectual property
• ☐ Defined validation criteria
• ☐ Acceptance conditions

How to use your specification

A well-written specification does not stop at describing a product: it structures the relationship between product owner and design house throughout the project, from initial consultation to final acceptance.

During consultation

Our experience on outsourced projects shows that consultation quality depends directly on specification quality. On a recent multi-supplier consultation, we have observed that quotes between design houses spread by a factor of 3 for the same nominal scope, simply because each had interpreted the grey zones of the specification differently. Send the same document to every design house consulted to enable a fair comparison. The questions each supplier asks reveal their level of understanding and experience.

To pick the right partner, see our guide on how to choose an electronic design house.

During the project

The specification serves as the reference for validating technical choices and arbitrating evolutions. Any modification must be documented in a change request, with impact analysis on schedule and budget.

At acceptance

The validation criteria defined in the specification form the basis of acceptance. A product compliant with the specification is an acceptable product, even if it does not match unstated expectations.

From specification to finished product

The specification is the first step of a complete process leading from initial need to industrialised product. Anticipating the design, prototyping and industrialisation phases at the specification-writing stage avoids costly back-tracking.

At AESTECHNO, we have observed that projects with a well-structured specification run on average with fewer design iterations and shorter certification timelines. The quality of the starting document directly conditions the smoothness of the entire development.

Our article on moving from prototype to series details the development phases and watch points at each stage.

For projects where you hesitate between in-house and outsourced development, our Make or Buy analysis helps you make the right call.

Finally, to shorten time-to-market, see our strategies to accelerate time-to-market.

Bottom line

An electronic product specification is the contract that decides whether your project ships on schedule or slips. It is not bureaucracy: it is the place where business objectives, regulatory constraints and engineering trade-offs meet a single time, before money is committed. At AESTECHNO, we have observed that 8 out of 10 derailments we are called in to recover trace back to a documentary gap, not a technical one. Write the specification with the rigour of an acceptance test plan, version it through clear gates, and treat every requirement as a future test case. The document is short on its first version; it earns its pages through testable, traceable, named requirements, not through filler.

FAQ: electronic product specification

Below are the answers to the questions we most often receive from product owners and project managers when they write their electronic product specification.

What is the ideal length of a specification?

An effective specification typically runs 15 to 40 pages depending on project complexity. What matters is not length but completeness: every necessary piece of information must be present, with no useless padding. A document that is too short often misses critical detail, while a document that is too long buries the essentials in clutter.

Do you need technical skills to write a specification?

Not necessarily. The context, functionality and business objective sections can be written by a product manager or decision-maker. For the technical sections (specifications, environment, regulatory), expert support is recommended. A good design house can help you structure your document during a pre-project phase. Note that the specification is also a central document during technical due diligence for hardware investors: its quality is a direct signal of the project team's maturity.

How should you manage changes to the specification during the project?

Changes are normal but must be controlled. Each modification must trigger a formal change request, with impact analysis (schedule, cost, risks). Maintain a version history and make sure every party works on the same version of the document.

What if I don't know some of the technical specifications?

Clearly mark the points to be defined jointly with the design house. It is better to write "autonomy to be defined based on real-world use" than to invent an unrealistic figure. A good supplier will help you refine those specifications during the preliminary study phase.

Does the specification have contractual value?

Yes, the specification is generally annexed to the contract and serves as the reference defining the scope of work. That is why drafting must be careful: any ambiguity can lead to divergent interpretations and disputes. Have the document reviewed by a lawyer for high-stakes projects.

How can I tell if my specification is detailed enough?

A good test: send it to two different design houses. If their technical proposals are radically different, or if their questions reveal major misunderstandings, your document is probably missing precision. Grey zones surface during the exchange with potential suppliers.

Related articles

• Electronic design house: our design methodology
• CE/RED certification for IoT products: complete guide
• Design for Manufacturing (DFM): designing for production
• Electronic component shortages: anticipating supply risks
• Electromagnetic compatibility: EMC fundamentals
• Industrial IoT cybersecurity
• Cyber Resilience Act (CRA): IoT compliance