Computerguided Systems Embedded · High-tech electronics
Home/ Why requirements analysis
The argument

The work that makes development predictable.

In embedded systems and high-tech electronics, the cost of a misunderstood requirement grows from hours to months as a project progresses. Here is why we believe disciplined requirements analysis is worth the time it takes.

The problem with "just start building"

It feels productive. It carries a hidden assumption.

In an Agile-first approach, the instinct is to get developers working as fast as possible. This feels productive. But in embedded systems and high-tech electronics development, it carries a hidden (and often very costly) assumption: that everyone (customer, engineers, management) actually agrees on what the product needs to do.

In practice, they almost never do.

Requirements analysis exists to surface that misalignment before it becomes expensive. The cost of changing a misunderstood requirement grows dramatically as development progresses. Catching it in a requirements document costs hours. Catching it after hardware has been designed and manufactured can cost months and tens of thousands of euros.

COST OF CHANGE → Requirements Design Prototype Production In-field hours days weeks months €€€€

Where you catch a misunderstood requirement determines what it costs to fix.

Three core principles

The disciplines that prevent late-stage surprises.

Each principle answers a specific failure mode that we see again and again in embedded development projects.

01

Separate what from how

A Product Requirements Specification answers what the product must do from the perspective of users and stakeholders, without prescribing how it will be built. The System Requirements Specification translates those needs into technical requirements.

When a customer says "it needs to use Bluetooth", that's often an assumption wrapped around the real need: "the user needs to configure the device wirelessly from a smartphone." Keeping those distinct opens the door to better, and often more innovative, solutions.

02

Every requirement must be verifiable

A requirement that cannot be tested is not a requirement; it is a wish. Every statement of what the product must do needs a clear, objective answer to: how will we know this is satisfied?

This forces precision. Vague requirements like "the system shall be responsive" are immediately exposed as unverifiable, pushing the team to define concrete criteria like "the system shall respond to user input within 200 milliseconds." It also surfaces test infrastructure needs (chambers, accredited labs) early enough to plan and budget.

03

Confront risk early

The requirements analysis phase deliberately seeks out uncertainty rather than deferring it. Every functional module is classified as trivial, balanced, or exploratory. Exploratory modules (those relying on unproven technology or pushing known limits) may trigger targeted prototyping before committing to a design direction.

This is the opposite of the Agile assumption that uncertainty resolves itself through iteration. In hardware, a failed assumption late in the project can mean a complete respin, a regulatory re-certification, or a fundamental architectural change.

Compared to Agile

Hardware doesn't enjoy short feedback loops.

Agile works well when the cost of change is low and feedback loops are short, typically in pure software environments where you can deploy a fix overnight. Embedded systems development does not enjoy those conditions.

Hardware has long lead times and tooling costs. Regulatory certification cannot be iterated. A firmware architecture that is misaligned with the hardware it runs on cannot be "refactored" in a sprint. When a prototype is built to the wrong specification, the loss is real and often unrecoverable within the original budget and timeline.

The requirements analysis phase is not a waterfall bottleneck. It is a structured risk reduction exercise that produces a shared, agreed-upon understanding of the product before significant capital is committed.

The practical payoff

What you actually walk away with.

Done well, the requirements analysis phase delivers several concrete outcomes that directly reduce project risk and cost:

The phase is modular: each stage produces a deliverable the customer can review and approve before the next begins. This gives you genuine go / no-go decision points and ensures investment is made incrementally, with growing confidence at each step.

Time spent on requirements analysis is not time lost to development. It is the work that makes development predictable.

Take the argument with you

The visual version, on 15 pages.

A blueprint-style summary of everything on this page, and the methodology that follows from it. Useful for sharing the argument with stakeholders who'd rather see it than read it.

Computerguided Systems
Requirements Analysis
for Embedded Products
PDF · 15 pages · 3 MB

Requirements Analysis for Embedded Products

The cost-of-change argument, the three core principles, the four-phase framework, and a visual walk-through of each phase, from PRS to development plan.

Download the blueprint ↓

Have a CRS or product concept?

Each phase of our process can be purchased independently. Start with a Product Requirements Analysis and decide at the end whether to continue, take the results in-house, or engage another partner.

Explore the phased approach → Read the documentation