When Do You Actually Need a Written Requirements Spec?

September 2, 2026· 8 min read

"Do we need a written requirements spec for this?" is the wrong question. The right one is: at what point does not having one start costing more than writing one?

The honest answer is sometimes never. A throwaway script, a weekend prototype, a one-off internal tool — none of these needs a formal specification. This post gives you a decision rule, so you stop arguing about it and start writing — or stop writing and start building.

The spectrum

Formality should follow risk. Most work falls into one of four bands:

Throwaway prototype or script — no spec. The code is the spec; if it works, it works, and you will throw it away anyway.
MVP or early product — a one-page brief. Goals, the core user flow, and what is explicitly out of scope. Enough to keep a small team aligned.
Long-lived product or multi-team build — a real requirements spec, versioned and traceable. This is the Lastenheft.
Regulated or safety-critical system — a full spec is mandatory, with traceability from requirement to design to test. It is not a nice-to-have; it is the audit trail.

The triggers that flip the switch

If any of these is true, write it down before you build:

More than one person or team is building against it — you need a shared, written definition of "done".
Someone else will maintain it — the next person cannot read your mind.
A customer or an auditor will later ask "what did we agree to?" — you need the signed record.
It touches safety, security, money, or compliance — the cost of a miss is unacceptable.
You cannot afford to build it twice — a spec is the cheapest way to build it once.
It must integrate with other systems — interfaces have to be pinned down before both sides build.

A decision rule you can use

Write it down when the cost of a wrong assumption exceeds the cost of writing. That is the entire rule. If a misunderstood requirement costs you an afternoon of rework, skip the spec. If it costs you a quarter of hardware, a certification cycle, or a public launch, the spec is the cheapest insurance you can buy.

Notice that the rule is about consequences, not about team size or budget. A two-person team building a safety-critical device needs a spec far more than a fifty-person team building an internal dashboard.

The question is never "is a spec good practice?" — it is "what does it cost me if this requirement is wrong, and when will I find out?"

What "written" actually means

A specification is not one 200-page artifact that you either have or do not. It is a scale, and you match the formality to the risk.

A one-page brief for the MVP. A feature list with acceptance criteria for the product. A full Lastenheft/Pflichtenheft pair for the regulated system. The mistake is not writing too little — it is writing too much for the risk, which buries the team in process, or too little, which buries them in rework.

Three cases

A data-migration script — skip it. If the schema is wrong, you notice in minutes and rerun it.
A startup’s web MVP — one page: who it is for, the one thing it must do, what you are deliberately not building yet.
A battery storage system with a power conversion unit — full spec. Safety, hardware, certification, and integration with a monitoring platform all meet here; a wrong requirement is not a re-run, it is a recall.