Requirements Engineering 101: Why, When, and How to Write Requirements

September 2, 2026· 9 min read

Most engineering disasters are not caused by bad code. They are caused by a team building the wrong thing — and only discovering it after months of work. Requirements engineering is the discipline of writing down what a system must do, before anyone starts building it, so that the most expensive mistake is caught where it is cheapest to fix.

This guide is the map. It explains why requirements matter, when you should write them, and how to write ones that survive contact with a real team.

What a requirement actually is

A requirement is a single, testable statement about what a system must do. "The system shall send an email confirmation within 5 seconds of a purchase" is a requirement. "The system should be good" is not — there is no way to test "good".

Requirements live at the boundary between the people who need a system and the people who build it. They are the contract between them, and like any contract, their value comes from being specific, agreed, and written down.

Why written requirements matter

The cost of fixing a mistake rises sharply the later you find it. A wrong requirement caught during writing costs minutes to fix. The same mistake caught after release can cost hundreds of times more — it may have spawned design, code, tests, documentation, and a support team, all built on the wrong assumption.

They make disagreements explicit before they become expensive rework.
They give every engineer the same definition of "done".
They are the baseline for testing — no requirement, nothing to verify against.
They protect you when scope changes: a written, agreed spec is the only defense against "but I thought you wanted…"
In regulated domains they are not optional — they are the audit trail that keeps you compliant.

The cheapest place to catch the most expensive mistake is in the requirements. Every hour spent there saves many hours later.

When to write them

Not everything needs a formal specification. A throwaway prototype does not. A product that must be maintained, certified, or handed to another team does.

You will maintain it for years, or someone else will.
More than one team or person is building against it.
It touches safety, security, or a regulated domain.
The cost of getting it wrong is high (hardware, firmware, or a public launch).
You need to prove — to a customer or an auditor — what was agreed.

How to write a good requirement

Good requirements share a handful of qualities, codified in standards like ISO/IEC/IEEE 29148. Each requirement should be necessary, unambiguous, atomic, feasible, and verifiable. A useful starting point is the EARS notation (Easy Approach to Requirements Syntax), which gives you a repeatable template.

Atomic: one requirement per statement — "the system shall X" carries exactly one X.
Unambiguous: a reader cannot interpret it two ways.
Verifiable: you can point to a test that would prove it true or false.
Use "shall" for requirements, "should" for goals, "may" for options — and never blur them.
Avoid vague adjectives like "fast", "friendly", "robust", or "as needed" — replace them with numbers.

The German distinction: Lastenheft and Pflichtenheft

German engineering separates two documents that are often collapsed into one elsewhere. The Lastenheft (requirements specification) describes WHAT the customer needs, in the customer's own language. The Pflichtenheft (design specification) describes HOW the supplier will meet it, written by the supplier.

Keeping the two separate prevents the most common scope dispute: the customer says "I only asked for X", the supplier says "X implies Y". A clean Lastenheft is the reference point both sides signed.

A worked example

Here is the same idea written badly, then well. The difference is the difference between a testable contract and a wish.

Bad: "The system shall be fast and user-friendly."

Good: "The system shall display the requirements list within 500 ms for a document containing up to 500 requirements, measured in a current desktop browser on an 8 GB machine."

The second one can be tested. The first one starts an argument. That is the entire craft of requirements engineering in one line.

If you cannot describe the test that would fail it, you have not finished writing the requirement.