What is a requirements baseline?

Requirements baseline, explained#

Requirements change, and they should. Customers learn, markets move, and a team discovers what is hard. The problem is not change but invisible change: a requirement quietly reworded, a must-have deleted, a feature added nobody approved. Months later, nobody can say what was actually agreed.

A baseline fixes a reference point. At sign-off, the agreed requirements are copied and frozen with a number, a date and who approved them. The live requirements keep evolving, but the baseline does not, so anyone can compare the two and see exactly what was added, edited or removed since. In formal practice this is a configuration management idea: after the baseline, changes go through change control, and a new baseline can be taken once a set of changes is approved.

A useful baseline includes each requirement's identifier, wording, priority and acceptance criteria, meaning how you would know it works. Without acceptance criteria an audit has nothing to check against. Stable identifiers matter too: if REQ-014 is renumbered, every task and report that pointed at it now points at the wrong thing.

Baselines are common in regulated and contract work, where what was promised has legal weight, but they help any team that has ever argued about scope. They also make agencies' lives easier: the client approved baseline 2, and baseline 3 is what changed after.

For example, an agency and a client approve fourteen requirements and freeze them as baseline 1. Three weeks later, the client asks for SSO. The team adds it as REQ-015 and later freezes baseline 2 with a note explaining the addition, so the change in scope, and the reason, is on record.