What people tell us when they're sceptical.

Isn't this just waterfall in disguise?

No, and here is the distinction that matters: waterfall demands that an entire specification be completed and frozen before any development begins. Our phased approach instead delivers a single, reviewable artefact at the end of each short phase, and explicitly invites a decision after each one. You can stop after Phase 1. You can take the PRS in-house. You can hire a different partner for the rest. The whole structure is built around the idea that the customer should commit to a small piece of work, see what it produces, and then decide whether to commit to the next piece.

What it has in common with waterfall is the order: requirements precede design, design precedes implementation. In hardware, that order is not a stylistic choice. A PCB cannot be refactored in a sprint, and a regulatory certification cannot be iterated. The order is a consequence of physical and economic reality, not of methodology.

We work Agile. Doesn't structured requirements analysis slow us down?

Agile advocates for iterative development, not for skipping the work of understanding the problem. Even Scrum expects a well-understood, prioritised product backlog. The PRS and SRS provide exactly that: a verifiable set of requirements that lets sprints deliver value instead of churning on misaligned assumptions.

The deeper issue is what "slow" means. Defects found at the requirements stage cost roughly one unit to fix. The same defect found during design costs five to ten times that. During implementation, ten to fifty times. Post-release, a hundred to a thousand times. Skipping requirements analysis does not save time. It borrows time at punishing interest rates.

Where the Agile critique does have merit: the volume of upfront documentation should match the project's risk and ambiguity. For a well-understood feature in a familiar product line, a heavy PRS would be overkill. The methodology scales down as readily as it scales up.

Why two separate phases (PRA and SRA)? Isn't that just doing the same work twice?

It looks like duplication, but the two phases answer different questions. The PRA produces requirements that describe what the product must do, deliberately staying solution-neutral. The SRA translates those into how the system will technically achieve it. This separation is not bureaucratic overhead, it is a firewall against a very common failure mode: jumping to implementation before the problem is properly understood.

When teams skip the PRA and go straight to system requirements, three things tend to happen. Engineers think in solutions, so requirements emerge like "the system shall use a specific microcontroller" when the actual need was "the system shall process sensor data within 10ms", closing off alternatives before exploring them. Traceability to business value is lost, which becomes painful the first time someone needs to argue for or against a feature on cost grounds. And use case scenarios, which catch failure modes from the user's perspective, never get written, because technical decomposition tends to focus on making things work rather than on how users might misuse the product.

Where the critique has merit: for small, well-understood products with experienced teams and clear customer input, a combined phase can work. The deciding question is how much ambiguity exists in what is being built. If the answer is "very little", streamline. If there is meaningful uncertainty (novel functionality, new customers, regulatory complexity) the PRA discipline pays for itself many times over.

How do you get engineers to actually read and use the documents?

This is a real concern, and engineers' resistance often comes from legitimate experience. They've seen requirements documents that were bureaucratic busywork, outdated before the ink dried, or written by people disconnected from implementation realities. Acknowledging that is the starting point.

A few approaches that tend to work:

Involve them in writing it. Requirements written to engineers feel like constraints. Requirements written with engineers feel like agreements. When engineers participate in scenario authoring, concept analysis, and the DFMEA, the documentation is a byproduct of their engineering work, not paperwork imposed on top of it.

Frame it as risk reduction, not bureaucracy. "Fill out this requirements template" produces resistance. "Let's figure out now what would make us redesign this in three months" produces engagement. The DFMEA is often the easiest entry point: engineers enjoy finding failure modes and edge cases, and that work happens to produce documentation.

Keep it lean. For a trivial concept, a few sentences suffice. The heavy analysis is reserved for the exploratory parts where it actually matters. Forty pages of boilerplate for a simple feature trains everyone to tune the documents out.

Show that it gets used. If test plans reference the requirements, design reviews check against the SRS, and the docs get updated when scope changes, engineers will treat them seriously. Documents that gather dust train people not to write them carefully.

Our project is too small to justify this much process.

Possibly true, and we'll say so if it is. The phased approach is designed for products where a misunderstood requirement can cost weeks or hundreds of thousands of euros to fix. If your product is a minor variant of something you've shipped before, with stable requirements, a familiar customer, and no regulatory novelty, a full four-phase engagement is probably overkill.

What we'd suggest instead, depending on which risks dominate: a Phase 1 alone (a clean PRS to anchor the project), a targeted DFMEA on the riskiest subsystems, or a focused architecture review. The methodology is modular precisely so that a small project can buy a small piece of it.

The opposite mistake is more common, though. Projects that feel small often turn out to have hidden complexity: a customer assumption nobody documented, an environmental requirement that triggers expensive testing, a regulatory regime that adds three months of certification. A short conversation usually tells us which category a project is really in.

It's too expensive. We just need a quote, not a four-phase engagement.

You can buy a single phase. Most of our engagements start as a Phase 1 alone, which is short, well-scoped, and produces a deliverable you can review and decide on. After that you can continue with us, take the PRS in-house, or hand it to a different partner. There is no all-or-nothing contract.

The deeper version of this objection is sometimes that requirements analysis itself feels like an expense without a tangible deliverable. The deliverable, in our case, is a document that turns an ambiguous concept into something development teams can actually quote against. Quoting a project against an unclear CRS produces one of two outcomes: a quote padded with contingency to cover unknowns (you pay for the ambiguity), or a quote that underestimates effort and triggers change orders later (you also pay for the ambiguity, plus interest). The PRS removes that ambiguity, which is what makes the downstream estimate defensible.

What if our requirements change during the project? Doesn't this freeze us in?

Requirements change. The PRS is baselined, but it is not immutable. What baselining does is make the change visible: when a requirement is updated, you can see what changed, why, and what downstream artefacts (architecture, test plan, estimate) it affects. That is the opposite of freezing the project. It is the discipline that lets you change direction without losing track of what you decided last week.

A common pattern: a customer's understanding of their own product genuinely evolves during Phase 1, as the PRA work surfaces assumptions they had not articulated. We treat that as a success, not a failure. The PRS captures the evolved understanding, and Phase 2 starts from there. The alternative (proceeding to implementation with the original, unexamined understanding) is what produces the late-stage scope explosions everyone fears.

We already have a Customer Requirements Specification. Why pay you to redo it?

We don't redo it. The Phase 1 work takes your existing CRS as input and produces a Product Requirements Specification from it. The two documents have different jobs. A CRS is what your customer (or your product management team) believes the product should do. A PRS is the structured, verifiable, testable version of that, with use cases, scenarios, and acceptance criteria that downstream engineering teams can actually quote and build against.

What we typically find in this work is not that the CRS is wrong, but that it has implicit assumptions that everyone agrees with but nobody has written down. Those implicit assumptions are exactly the things that cost money later. Surfacing them, writing them down, and getting explicit agreement from the customer is the work.

If your CRS is already extremely thorough, the Phase 1 effort is correspondingly smaller. We'll tell you that in the scoping conversation, not after invoicing for a full phase.

Can we engage you mid-project, or only at the start?

Both. The phased approach is structured around starting fresh, but the individual deliverables are useful at any stage of a project. A few common mid-project engagements:

A focused DFMEA on a subsystem where you're seeing unexpected reliability issues, or where you need a defensible risk analysis for a regulatory submission. This is Phase 2 work, applied to a specific area rather than the whole system.

A retroactive PRS or SRS for a product that grew organically and now needs to be re-quoted, transferred to a different team, or certified. The work is harder than starting from scratch, but it is sometimes the only way to make a product maintainable over its remaining lifetime.

An independent architecture review for a project where the customer or an internal stakeholder wants a second opinion on a design direction before committing further capital.

The honest version is: starting at the beginning is more efficient. But the methodology is built out of discrete deliverables, and those deliverables have value whenever they are produced.

How do we know the deliverables will actually be used, not become shelfware?

Two things make a document useful: it is referenced by the work that follows it, and it is updated when the underlying decisions change. The phased approach is built around both.

Each deliverable feeds the next phase concretely. The PRS scenarios become the input to the SRS. The SRS becomes the input to the Test Plan, line by traceable line. The DFMEA mitigations turn into new system requirements or new test activities. The BoM becomes the input to the supply chain analysis in Phase 3. A document that is being read and referenced by the next stage of work is not a document that gathers dust.

The risk of shelfware is much higher when documents are produced as deliverables on their own, with no downstream consumer. That happens when a customer commissions a PRS and then never starts the development project, or when a document is written to satisfy an audit rather than to guide engineering. In those cases the document is, indeed, shelfware. We will tell you up front when we think that's the trajectory.