Requirements in Embedded & Firmware Projects: Freeze the Spec Early
Embedded projects punish late requirements harder than any other kind of software. In a web app, a changed requirement means a redeploy. In an embedded system, it can mean a respin of the board, a firmware recall, or a field-service visit to units that are already installed — often in places nobody wants to revisit.
That is why the core discipline of embedded engineering is not clever code. It is freezing the specification early, and treating the interface contracts between hardware, firmware, and cloud as the load-bearing walls of the project.
Why embedded is different
- Hardware has lead times — a board change costs weeks or months, not minutes.
- Many devices cannot be updated over the air — what you flash at the factory is what runs for years.
- Memory and CPU are constrained — you cannot paper over a wrong requirement with a larger runtime.
- The system touches the physical world — and safety, heat, and voltage do not forgive ambiguity.
- Certification (CE, UL, functional safety) is built against a frozen spec — changing it restarts the process.
Freeze the spec early
The moment to catch a wrong requirement is before the schematic is drawn. A requirement changed during firmware development is expensive. A requirement changed after the board is fabricated is an order of magnitude worse. A requirement discovered after the units are in the field is a disaster.
So the discipline is: agree on the spec, baseline it, and make every change after that go through an explicit, recorded change process — not an informal chat.
The interface specs are the contract
The seams between teams are where embedded projects bleed. The hardware team, the firmware team, and the cloud team each build against a shared interface — and if that interface is not written down, each side invents its own version of it. (Remember Mars Climate Orbiter: one team used pound-force seconds, the other expected newton-seconds.)
The interfaces you must pin down, in writing, before anyone builds:
- The register map — every register, its address, data type, scaling factor, endianness, and units. Standards like SunSpec exist precisely because "which register means what" cannot be left to memory.
- The communication protocol — Modbus function codes, or the MQTT topic structure, payload schema, QoS, and retention policy.
- The data model — field names, types, and units shared between firmware and cloud, so a value is never reinterpreted in transit.
- Versioning — a schema or protocol version negotiated at startup, so a field unit and its cloud agree on what a message means.
The three-way split
Hardware, firmware, and cloud are three teams with three different clocks. Hardware thinks in revisions and respins; firmware in builds and flashes; cloud in deployments. The only thing that keeps them aligned is the frozen interface specification between them.
When the interface is written down and versioned, each team can change its own side independently — firmware refactors without breaking the cloud, hardware swaps a sensor without breaking the firmware. When it is not, every change becomes a three-way negotiation.
A concrete example
Consider a power conversion unit that must report its state to an energy management system. A vague requirement — "the unit shall report its measurements" — is a project-killer in waiting.
A real requirement pins down the contract: "The unit shall expose state of charge, DC voltage, and DC current via Modbus over TCP. State of charge shall be at register 40001 as an unsigned 16-bit integer scaled by 0.1 (unit: %), DC voltage at register 40002 as unsigned 16-bit scaled by 0.1 (unit: V), DC current at register 40003 as signed 16-bit scaled by 0.1 (unit: A). Values shall be big-endian. The unit shall also publish the same fields as a JSON message to MQTT topic /devices/{id}/telemetry every 10 seconds."
The difference is the difference between a device that integrates in a day and one that needs a support call and a firmware patch.