The Spreadsheet Was Never the Plan

A View from the Watchtower · Part One

How requirements engineering got stuck in Word and Excel — and why modern silicon can no longer afford to stay there.

Every chip that has ever taped out began as a sentence. Before the RTL, before the floorplan, before a single gate was placed, someone wrote down what the thing was supposed to do, for whom, and how anyone would know it worked. That sentence — a requirement — is the oldest artifact in engineering. And for most of our industry, it still lives in the least durable place we own: a document.

Where requirements came from

Requirements engineering is older than the chip business. It grew up in aerospace and defense in the 1960s and 70s, where the cost of getting it wrong was measured in lives, and where the V-model formalized a simple, durable idea: everything you specify on the left side of the V must be verified by something on the right. The connective tissue between the two halves was the traceability matrix — every requirement linked to a design element and to the test that proves it.

In principle, beautiful. In practice, it became a spreadsheet. A specification was a Word document. Sign-off was a PDF with a signature block. Traceability was an Excel grid that somebody updated by hand, usually late on a Friday. For decades, that was genuinely enough.

Why it worked — until it didn't

It worked because the systems were small enough for one team to hold in its head. A document is a fine container for a plan that a single group authored and a single group consumed. The trouble is that modern silicon broke all three of those assumptions at once.

The designs are no longer small. A current SoC carries billions of transistors, multiple dies, a stack of third-party IP, firmware, and software — developed concurrently across companies, time zones, and toolchains.

The plan is no longer authored by one group. Marketing writes the market requirements, systems writes the product requirements, hardware writes the micro-architecture, software writes the stack, and safety and security layer their own overlays on top.

And the plan no longer holds still. Requirements change every week, and every change ripples downstream into work that is already underway.

The tax nobody puts in the schedule

This is the part that rarely makes it into a schedule. A document-based requirement can't tell you which test now needs to run again. It can't surface that a power-domain decision three layers down just invalidated a stakeholder need at the top. The traceability exists — on paper — but it's reconstructed at audit time rather than maintained continuously. Jama Software calls this the difference between live traceability and after-the-fact traceability, and the distinction is the whole game.

Jama's own customer data puts a number on it: across organizations they studied, the large majority had maintained traceability in an Excel-based matrix that was disconnected from the actual design and updated entirely by hand. The tax shows up later as rework, missed requirements, late respins, and the audit scramble — and none of it is an EDA tooling failure. The simulator was fine. The synthesis was fine. The failure happened upstream, at the layer where intent is supposed to live.

What "more than a document" actually means

The answer is not a better spreadsheet. It is treating requirements as live, connected data instead of static text: a single source of truth where every requirement is an item, every relationship is a link, and every change is tracked the instant it happens. Jama frames this as the move from document-based to item-based requirements management — and the strategic transition off Word and Excel is now a well-worn path for teams that outgrew the matrix.

That is not a productivity nicety. At modern silicon scale, a living requirements layer is the only way the plan can keep pace with the design.

In the next two posts I look at the platform that built its reputation on exactly this shift, and at what happens to a whole program when requirements stop being a file you sign and start being a spine you build on.

The Jama Series · A View from the Watchtower

Part 1 — The Spreadsheet Was Never the Plan (you are here)
Part 2 — Functional Safety Was the Front Door, Not the House
Part 3 — From Intent to Yield: Why We Partnered with Jama