What is requirements engineering? A small-team guide

What is requirements engineering?

Requirements engineering is the discipline of producing requirements that are worth managing: finding out what the software must do, analysing and modelling it, writing it down in a form someone can disagree with, and reviewing it before anyone builds against it. It is the front half of the lifecycle. The back half — keeping those statements traced, verified, and current once building starts — is requirements management, and the two are frequently confused because they share vocabulary and, on a small team, share people.

The distinction is worth holding onto, because the failure modes are different. Bad requirements management gives you good sentences nobody can find. Bad requirements engineering gives you a beautifully traced matrix of sentences that were never true in the first place.

Most of what has been written about requirements engineering comes from aerospace and defence, where a specification is a contract and a missed requirement is a recall. That literature is not wrong, but it arrives with vocabulary — decomposition, flow down, baselines, derived requirements — that reads as ceremony to a five-person web team. Almost all of it translates. This guide translates it.

Summary

• What is a requirement? A falsifiable statement of needed behaviour — precise enough that observing the running system could prove it wrong.
• Requirements engineering spans elicitation and gathering, requirements analysis, modeling, specification, and review. It produces validated requirements.
• Requirements management takes over from there: tracing, verification, and change control over time.
• Requirements quality is three properties: precise, testable, owned. Everything else is style.
• The systems-engineering terms — decomposition, derived requirements, flow down, baseline — describe things small teams already do informally, badly.
• Requirements engineering tools matter mostly at the tracing end. The rest of the lifecycle is thinking and writing.

What is a requirement, exactly?

Start with the smallest unit, because every later stage inherits its quality. A requirement is a statement of needed behaviour that some observation of the finished system could falsify. If no possible observation could show the sentence to be false, it is not a requirement yet.

That is the working definition of requirements this guide uses, and it is deliberately narrower than the everyday sense of the word. "The app should be fast" is a preference. "A search returns results within 500ms for a workspace of 10,000 documents" is a requirement, because a stopwatch settles it.

Here is the pair side by side:

The right-hand column costs more to write. That cost is the point. Each sentence names an actor, an observable behaviour, and a boundary, which is what makes it linkable to a route, an entity, or an endpoint later.

What requirements quality actually means

Requirements quality is measured on three properties, and a sentence that fails any of them will cause trouble downstream.

Precise enough to be wrong. Falsifiability again. This is the property that survives contact with disagreement — two people can argue about a precise requirement and reach a conclusion, but they can only take turns nodding at a vague one.

Testable. Someone can name how they would check it. Not necessarily an automated test; a written acceptance criterion or a manual checklist counts. If nobody can describe the check, the requirement is not finished.

Owned. One named person can accept, reword, or reject it. Unowned requirements accumulate, because dropping one requires authority nobody has.

Notice that none of the three is about format. Templates and "shall" phrasing are conventions, not quality. A team writing plain sentences that pass all three tests is doing better requirements engineering than a team filling in a template with wishes.

The stages of requirements engineering

Requirement engineering — the term appears in the singular about as often as the plural, and means the same thing — is usually described as four or five stages. They are not a waterfall. On a real project you will loop between them several times per feature. But each stage answers a distinct question, and skipping one fails in a distinct way.

1. Elicitation, or gathering. So, what is requirements gathering? It is the act of finding out what the software must do from the people who will judge whether it did — through user interviews, support tickets, competitor gaps, sales conversations, and compliance obligations. It is discovery, not transcription: stakeholders describe solutions, and the job of gathering is to keep asking until the need underneath appears. The pillar guide calls this stage requirements collection, and the two words are interchangeable — gathering is the more common phrasing in software, collection in the systems-engineering literature. Identifying requirements from a support queue is often the highest-yield version, because a ticket is a need someone already bothered to write down.

2. Requirements analysis. Take the raw material and resolve it. Analysis is where duplicates merge, conflicts surface, priorities get argued, and scope gets an edge. Two stakeholders who both want "better reporting" usually want different things, and analysis is the stage that discovers this before either of them sees a build.

3. Modeling. Draw the parts that prose describes badly — the data, the flows, the screens. More on this below, because it is the stage small software teams most consistently underuse.

4. Specification, or definition. Write the final statements. Defining requirements is the act of turning an analysed need into the falsifiable sentence from the section above, and assigning it an owner. This is also where the business, functional, and technical layers separate — a business goal is recorded as the reason, and only the functional layer becomes a traceable requirement.

5. Validation and review. Check that the specified requirements are the right ones, and that each is individually sound. Validation asks whether the set describes the product the stakeholders actually want. Review asks whether each sentence meets the quality bar.

Requirements development vs. requirements management

The systems-engineering world calls stages one through five requirements development. Software teams more often say requirements engineering for the same span. Either way, the output is a set of validated statements someone owns.

Requirements management picks up from there and runs for the rest of the project: tracing each requirement to the design elements that deliver it, verifying those claims, and controlling change as the list evolves. The five-stage management process covers that ground in depth, and a requirements management plan is where a team writes down how it intends to run it.

One sentence holds the relationship: engineering produces and validates the requirements; management keeps them true over time.

The two overlap in practice. Change control feeds edits back through analysis and review, so a mature project is doing both at once. But the distinction tells you which problem you have. If your matrix is well-linked and the product still misses, the problem is upstream. If everyone agrees the requirements are right and nobody can say which route delivers them, the problem is downstream.

Systems-engineering vocabulary, translated

These four terms carry most of the intimidation, and all four describe something a web team already does.

Requirements decomposition is breaking a high-level need into statements small enough to implement and check. "Users can collaborate on a project" decomposes into an invite requirement, a permissions requirement, a live-presence requirement, and a revocation requirement. Decomposition is finished when each child is falsifiable on its own and the parent is fully covered by its children. The common error is stopping one level too early, which leaves a requirement that no single surface can claim.

Derived requirements are requirements implied by a design decision rather than asked for by a stakeholder. Nobody requested a webhook idempotency rule. It exists because you chose a payment provider that retries deliveries. Derived requirements are real requirements, they need the same quality bar, and they are the ones most often left unwritten — because there was no stakeholder to write them down for. Recording them is what makes an architecture decision reviewable later.

Requirements flow down is the allocation of a parent requirement to the subsystems that will satisfy it. In aerospace this means a vehicle-level requirement flowing to propulsion and avionics. For a web team, the same requirement flowdown — the term is spelled both ways — runs from a product goal to statements at the route, component, entity, and API level. "A client can pay without an account" flows down to a public route with no auth guard, a payment entity with no owner foreign key, and an endpoint that authenticates by token rather than session. Each of those is a statement someone can check independently.

A requirement baseline is the agreed snapshot that change is measured against. Without one, "the requirements changed" is an unfalsifiable claim, because there is no recorded prior state. Small teams do not need a formal baselining ceremony, but they do need a version they can point at when a build cycle starts, so that scope creep is visible as a diff rather than as a feeling.

A requirements review is reading the set adversarially before building. Not a rubber stamp — an explicit pass looking for statements that fail the quality bar, decomposition that stopped early, and derived requirements that were never written down. Thirty minutes before a cycle catches things that cost days during it.

Requirements modeling: when a diagram beats prose

Requirements modeling means expressing a requirement as a structure rather than a sentence, because some requirements are about relationships, and prose describes relationships badly.

Three model types cover almost all of it for a software team:

• Data models. "An invoice belongs to a client and has many line items" is a requirement about structure. A sentence version needs three careful clauses; an entity diagram makes it obvious and makes the missing cardinality visible. Nodlume's ER designer is a place to write this kind of requirement.
• Route trees. Which screens exist, which are public, which sit behind a guard. This is a requirement about navigation and access, and a tree shows the gap where a prose list hides it.
• Wireframes. What a screen must contain. A wireframe is a requirement about a surface, and reviewers catch missing states — empty, error, loading — far faster looking at a layout than reading a paragraph.

The reason to treat these as requirement models rather than as design artifacts is that it changes who reviews them and when. A data model drawn during requirements engineering is a statement to be validated with stakeholders. The same diagram drawn during build is a decision already made.

This is the whole premise of a design-native tool. In Nodlume the canvases are the requirements models, and they are also what the generated file tree is built from, so the model does not get abandoned once code starts. The features you defined and the surfaces you modelled meet in the traceability matrix — the subject of tracing features to implementation.

Requirements engineering tools

Honest answer first: most of requirements engineering is thinking and writing, and no tool does either. Elicitation is conversations. Analysis is argument. Definition is drafting sentences. A team with a shared document and the discipline to write falsifiable statements is doing the hard part correctly.

Tooling starts to earn its cost at the boundary between engineering and management — at modeling, tracing, and change. Those are the stages with real bookkeeping, and bookkeeping is what software is for.

That gives three practical categories of requirements engineering tools:

• Writing surfaces — a doc, a wiki, a spreadsheet. Fine for elicitation and definition, and genuinely sufficient for a small backlog. The failure mode is staleness, not wrongness, which is worse, because a stale requirement still looks authoritative.
• Modeling surfaces — diagram and canvas tools for data models, route trees, and wireframes. Worth using as soon as requirements involve structure, which is almost immediately.
• Tracing surfaces — requirements management software and the lighter requirements tracking tools. This is where enterprise suites live, and where the gap between a five-person team and a regulated programme is largest.

The selection question is not "which tool is best" but "which stage is currently failing." A team that cannot say what it is building needs better elicitation and definition, and buying a traceability suite will not supply either.

Q&A

Question: What is requirements engineering?

Short answer: Requirements engineering is the discipline of producing validated requirements — eliciting needs from stakeholders, analysing and modelling them, specifying them as falsifiable statements, and reviewing them before build. It is the front half of the requirements lifecycle, and its output is the input to requirements management. The term is used interchangeably with requirements development, which is the systems-engineering name for the same span of work.

Question: What is the difference between requirements engineering and requirements management?

Short answer: Engineering produces the requirements; management keeps them true. Requirements engineering covers gathering, analysis, modeling, definition, and review — everything that turns a stakeholder need into a sentence someone owns. Requirements management covers tracing each sentence to the design that delivers it, verifying those claims, and controlling change over the life of the project. Small teams do both, usually with the same people, but the distinction tells you which end is failing when something goes wrong.

Question: What are the stages of requirements engineering?

Short answer: Elicitation or gathering, requirements analysis, modeling, specification or definition, and validation and review. They are not strictly sequential — most projects loop between analysis and definition several times per feature. Each stage answers a different question, and skipping one has a specific consequence: skip elicitation and you build the wrong thing, skip analysis and you build two conflicting things, skip review and you build the right thing from a sentence nobody could check.

Question: What is a derived requirement?

Short answer: A derived requirement is one implied by a design decision rather than requested by a stakeholder. Choosing a payment provider that retries webhook deliveries derives an idempotency requirement; choosing to cache a listing derives an invalidation requirement. They carry the same quality bar as stakeholder requirements and need the same owner, but they are the most commonly unwritten kind, because nobody outside the team asked for them.

Question: What makes a good requirement?

Short answer: Three properties. It is precise enough to be wrong, so that some observation of the running system could falsify it. It is testable, meaning someone can name how they would check it. And it is owned by a person who can accept, reword, or reject it. Format, phrasing conventions, and templates are style; requirements quality is those three properties, and a plain sentence that has all three beats a formal one that does not.