Requirements baseline: what it is, with an example

Published 18 October 2026

A requirements baseline is the set of requirements, each at a named version, that was formally agreed at one point in time — and that every later change is measured against. It answers the question every project eventually asks: what exactly did we agree? Without one, “the requirements” means whatever the document says today.

I’ve tried email trails. I’ve tried shared Notion docs. Neither of them create a genuine “this version is now closed” moment.

— a web developer who mostly does client work, r/projectmanagement, June 2026

Requirements baseline definition

The standard definition of a baseline, from the software life-cycle standard ISO/IEEE 12207:

A specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures.

— quoted in the SEBoK glossary

Three things follow. A baseline is agreed — reviewed and approved, not just saved. It is a basis: later work and later changes are compared with it. And it changes only through a decision — a change request, not an edit. The same page quotes a note from IEEE’s vocabulary: “Baselines, plus approved changes from those baselines, constitute the current configuration identification”: what is true now is the baseline plus the changes approved since.

What a requirements baseline contains

• Its name or number, and the date it was agreed.
• Every requirement in it, with its version — not “the requirements document”, but which requirements, at which versions.
• The acceptance criteria of those requirements.
• What is out of scope.
• Who approved it, and when.
• The change process that applies from now on.

Requirements baseline example

REQUIREMENTS BASELINE RB-3

Project:     Customer portal
Agreed on:   3 March 2026
Approved by: [client lead], [sponsor]
Replaces:    RB-2 (agreed 28 January 2026)

REQUIREMENTS IN THIS BASELINE
  BR-03   Shorten the time invoices stay unpaid  v1.0
  FR-014  Pay an open invoice by card            v1.2
  FR-015  Email a receipt after payment          v1.1
  FR-021  Export invoices to CSV                 v1.0
  (acceptance criteria as at these versions)

OUT OF SCOPE
  Direct debit. Invoices in other currencies.

CHANGES SINCE RB-2
  CR-5    FR-021 added: export invoices to CSV

From now on, any change to these requirements is a change
request, approved before work starts. The next approved
set of changes becomes RB-4.

Baseline vs version vs release

A version can change many times a day. A baseline changes only by being replaced with the next one. How to keep the history of each requirement’s versions is in how to track changes to requirements.

Scope baseline in project management

The PMBOK Guide’s scope baseline is wider than a requirements baseline: the approved scope statement, the work breakdown structure (WBS) and the WBS dictionary, changed only through formal change control. The requirements baseline is the part of it that says what the product must do. On a software project the two have to agree: when the requirements change, check the scope baseline too.

How to keep a requirements baseline

1. Freeze it. A copy that cannot be edited — an exported PDF, a tagged commit, a locked page — named after the baseline.
2. Name what is in it, requirement by requirement, with versions.
3. Record who approved it and when. The requirements sign-off template has the wording. Put it where anyone can find it. The person who started a thread asking “What is your sign off process?” wanted one “because sometimes the business acts as if they have no idea that this was signed off or something” (r/businessanalysis, 2025).
4. Change it only through change requests — see change request vs pull request and requirements change management.
5. Record the impact of every change against the baseline. It is an old wish: “track changes/additions to requirements after they have been signed off … and record the impact (resource, deadlines etc)” (r/businessanalysis, 2020).
6. Keep old baselines readable. When RB-4 replaces RB-3, RB-3 still shows what was agreed then.
7. Tie the work to it. Tickets and tests name the baseline they were built against — the traceability matrix records the version each row refers to.

Re-baselining

Re-baselining means agreeing a new baseline after approved changes, so the plan and the requirements match again. Do it at a natural point — the end of a phase, a batch of approved change requests — not after every small change. And do it openly: a new baseline that silently absorbs unapproved work hides the scope creep it was supposed to measure.

When the baseline and the work part ways without a decision, that is spec drift.

Where Specroot fits

This is the problem Specroot works on: a baseline that is a real, frozen set of agreed requirements, with who approved it, and with every later change measured against it. Specroot for agencies and consultancies.