Hardware Requirements Specification: Template + Worked Example

Quick Answer

A hardware requirements specification describes what an electronic device must do, the conditions in which it must work, its interfaces and limits, and the evidence needed to accept it. Start with a product boundary, then give each requirement an ID, a measurable statement, a source, and a verification method. Keep unresolved choices visible instead of allowing them to become accidental design decisions.

SpeedUp uses those power, sensor, interface, and operating-state requirements to develop electronics architecture, structured schematic sheets, and an editable KiCad project for engineering review. This guide provides a copyable template and a worked solar weather-station example. The template applies to an embedded device being designed, rather than the minimum computer specifications needed to run software.

Why Write the Requirements Before the Schematic?

“Build a solar weather station” is enough to start a conversation. It does not tell a designer how long the station must survive without sunlight, whether rainfall must be counted during sleep, or how an indoor gateway gets power. Those omissions can change the power architecture, input circuits, and firmware responsibilities.

Separate three documents even if they share one file: the product brief explains the user’s problem; the hardware requirements specification defines obligations and constraints; the hardware design document records the chosen implementation. A named component is a requirement only when there is a real reason to mandate it. Otherwise, record it as a proposed design choice.

Hardware Requirements Document Template

Copy the fields below into your project document. Start with the decisions that affect the first schematic; expand the detail as the design matures. This is a practical starting template, not a certification document.

For each individual requirement, duplicate this record. Square brackets are fields to replace; do not leave them in an approved specification.

Requirement ID: [HW-001]
Title: [Short name]
Statement: The [device/subsystem] shall [one observable behavior]
           under [operating conditions], within [limit and tolerance].
Source / rationale: [User need, parent requirement, or imposed constraint]
Priority: [Must / target / optional]
Operating state: [Startup / active / sleep / fault / service]
Interfaces and dependencies: [Related requirement IDs and endpoints]
Verification: [Inspection / analysis / demonstration / test]
Pass criterion and conditions: [Setup, input, duration, allowed result]
Allocation: [Hardware block or sheet; firmware/mechanical responsibility]
Open assumptions: [TBD/TBR, owner, decision needed, due milestone]
Status: [Proposed / approved / changed / verified]
Evidence: [Design revision, test record, or other supporting result]

NASA’s requirements-writing checklist supports using distinct, traceable, verifiable statements and making assumptions explicit. The fields and device examples here are our practical adaptation; using them does not establish compliance with a NASA process.

Worked Example: A Solar LoRa Weather Station

The real SpeedUp solar LoRa weather-station project starts with an outdoor sensor node, an indoor ESP32 gateway, point-to-point LoRa, and a Wi-Fi/MQTT destination in Home Assistant. The original brief requests weather measurements and solar/battery operation without external power. It does not specify a sampling period, a radio acceptance test, or a cloudy-day runtime.

Keep three kinds of information separate: source requirements come from that brief; generated design choices appear in the actual project; proposed requirements below are teaching examples added for this guide. None of the proposed numerical values are measured results or approved specifications for the downloadable project.

From Broad Wishes to Reviewable Requirements

The following six proposed records show how to make the brief more specific. HW-001 and HW-003 provide concrete numerical examples; the other records deliberately retain decisions that the project owner must resolve.

A record containing [N] or [X] is still open. Assign an owner and a resolution milestone; do not silently substitute a convenient number. “Approved” means the team accepts the requirement. “Verified” requires evidence that the implemented device meets it.

Map Requirements to Architecture and Schematic Sheets

The existing project contains the six sheets listed below. This mapping is an allocation proposal for the next revision, not a claim that the current circuitry satisfies the example requirements.

The published project identifies an important conflict: its rain/wind input conditioning shares a switched sensor supply. Powering that supply off removes the active pulse front end. HW-003 makes the resulting question explicit: preserve an always-powered acquisition path or develop and validate another counting approach. A lower sleep-current target cannot override the rainfall requirement without a documented tradeoff.

For the broader allocation process, see the embedded-system architecture guide. Keep the requirement ID beside the relevant sheet notes, firmware issue, and test record so a later change has a visible owner.

Common Mistakes in a Hardware Specification

• Writing adjectives instead of limits. Replace “low power,” “accurate,” or “long range” with a defined operating condition and an acceptance criterion. A current target without a state or measurement boundary is incomplete.
• Combining several obligations in one sentence. Separate sensing accuracy, measurement interval, radio delivery, and data retention. They may need different owners and tests.
• Making a component choice look like a user need. If ESP32 is mandatory, record why. If it is only an initial preference, allow alternatives subject to the interface and performance requirements.
• Ignoring transitions and faults. State what happens during startup, low battery, missing sensors, lost radio contact, and service. Decide which data must survive a reset.
• Equating an artifact with acceptance. A BOM, block diagram, or connected schematic does not prove accuracy, battery life, environmental suitability, or radio performance.

Use the Template as a SpeedUp Project Brief

Once the major choices are resolved, condense the document into a brief without dropping requirement IDs or open decisions. The example below is an adaptation starting point; replace every bracketed field before treating it as an agreed design input.

Design an outdoor weather sensor node and an indoor gateway for [installation].
Use point-to-point LoRa between them; the gateway's intended software
destination is Home Assistant over Wi-Fi/MQTT.

Required measurements: [quantities, ranges, accuracy, and intervals].
Power: [approved sources for each unit, battery constraints,
no-solar duration, and active/sleep schedules].
Interfaces: [sensor models or electrical characteristics,
connectors, cable lengths, signal levels, and radio region].

Preserve HW-003: rain pulse acquisition must remain available while
the environmental-sensor supply is off. Include prototype programming
and recovery access per HW-006.

Constraints: [board envelope, required parts with rationale,
installation limits, and cost basis].
Open decisions: [ID, owner, and decision needed].

Develop an electronics architecture, structured schematic sheets,
and an editable KiCad starting point. Keep proposed implementation
choices separate from the requirements. Firmware, PCB layout,
field testing, and production validation are subsequent engineering work.

The SpeedUp AI schematic generator makes the next discussion concrete by turning a brief into editable circuit artifacts. Compare those artifacts against your requirement records and revise the design where there is a mismatch. The document remains the team’s responsibility; it is not an automatically verified contract.

Related Examples for Your Next Brief

• Desktop robot project: another example of a device brief developing into a structured hardware package.
• Battery-powered sensor design checklist: questions to resolve when filling in power and operating-state requirements.

FAQ

What is the difference between a hardware PRD and a hardware requirements specification?

A product requirements document usually describes the user problem, features, priorities, and commercial context. The hardware specification turns the relevant needs into device obligations, interface limits, and acceptance criteria. Small teams can keep both in one document if the distinction stays clear.

How detailed should the specification be before schematic generation?

Define the system boundary, power sources, essential interfaces, operating states, and constraints that would change the architecture. You can explore a first draft with open questions, but mark those questions explicitly and resolve them before approving the affected design.

Should the document specify every resistor and capacitor?

Usually those values belong in the design and BOM. Put an exact component in the requirements only when it is an imposed constraint with a rationale, such as compatibility with an existing assembly. Otherwise specify the behavior or interface the circuit must provide.

Can I use the weather-station requirements unchanged?

No. The numerical timing and pulse-test examples are illustrative. Adapt them to your sensor, installation, operating profile, and verification equipment. The linked project is an editable first draft with documented corrections still required.