Six months into the build, your requirements documents no longer describe the system. What do you do about it?

Not every document deserves to be current

The reflex is to plan an update, and the reflex is expensive and usually wrong. Documents drift because keeping them in step costs real time and nobody was funding it, so proposing to catch up commits you to the same unfunded cost for the rest of the project unless something else changes.

The prior question is what each artefact is for. A document exists because somebody makes a decision using it, and if you cannot name that person and that decision then the document has no purpose and its accuracy is irrelevant. So go through the set and ask, for each one, who reads it, what they decide with it, and what goes wrong if it is six months out of date. The answers vary far more than people expect.

Artefact	Read by, for what	Does drift create exposure
Business case and objectives	Sponsor, to decide whether to continue funding	Yes, and it is the one nobody updates
Process model of the to-be design	Trainers, operations, support, to write procedures	Yes, at go-live, catastrophically
Detailed functional specification	Nobody, once the stories were written from it	Usually not, and pretending otherwise wastes weeks
Acceptance criteria on delivered stories	Testers and auditors, to establish what was agreed	Yes, and these must be immutable rather than current
Data dictionary and field mappings	Developers, migration team, reporting	Yes, and this is where errors are most expensive
Interface contracts with other systems	The teams at the other end	Yes, and they will not tell you it is wrong, they will just break

Presenting that judgement, per document, is the answer. A candidate who says they would bring all the documentation up to date has told the interviewer they have never had to fund it.

Current, immutable, or retired

Three destinations, and choosing deliberately is the whole method.

Some documents must be current, because somebody will act on them tomorrow. Data dictionaries, interface contracts and the to-be process model fall here. For these, updating is not optional and the real question is where they live: a document that has to be manually synchronised with a system will drift again, so wherever the information can be generated from the thing itself, generate it.

Some must be immutable, because their value is that they record what was agreed at a point in time. Acceptance criteria on a delivered story, a signed change request, a decision record. Updating these destroys them. If a rule has changed four times, the correct artefact is four dated records and not one document showing the current answer, and this distinction is what an auditor is actually asking about when they ask for the specification.

The rest should be retired, and retiring means saying so on the face of the document. Mark it superseded, date it, and name what replaced it. An unmarked stale document is worse than a deleted one, because someone will find it, believe it, and build a training course from it. Deleting outright is cleaner but frequently blocked by governance, in which case a header saying "superseded on 29 July; the current process model is X" costs one minute and removes the risk.

Find where the truth actually lives

Every project has a de facto record of truth and it is rarely the document that claims the title. It might be the test pack, because that is the thing that has to pass. It might be the code and configuration. It might be a spreadsheet a business user maintains. Establish which it is, because the practical answer to drift is often to make the de facto record the official one rather than to update the document that lost the race.

This has a consequence worth stating: if the test pack is the truth, it has to become readable by business stakeholders, which means the criteria in it need to be written in business language rather than technical steps. That is a real piece of work and it is a far better use of a fortnight than retyping a functional specification nobody opens.

Cost the maintenance out loud

Make the trade-off visible with numbers whose inputs are on the page. Suppose the specification runs to 140 pages and the team delivers a change to some rule in it roughly eight times a sprint. If each update takes 20 minutes to locate, edit, review and republish, that is 160 minutes a sprint, a little under three hours. Over ten remaining sprints that is about 27 hours, roughly three and a half days of analyst time. The question to put to the sponsor is straightforward: is a current 140-page specification worth three and a half days of analysis between now and go-live, given that the trainers work from the process model and the testers work from the acceptance criteria?

Sometimes the answer is yes, because a regulator requires it or a fixed-price contract references it, and then it is funded rather than absorbed. More often the answer is no, and the document gets marked superseded. Either outcome is fine. What is not fine is the third outcome, where you keep half-updating it and it stays authoritative in name while being wrong in substance.

A document that is confidently wrong

Drift is not symmetric in its consequences. A missing document produces someone asking a question, which is a small, visible, cheap event. A wrong document produces someone acting with confidence, which is a large, invisible, expensive event that surfaces later and somewhere else.

The clearest example is the interface contract. A partner team reads your specification, builds to a field that was renamed in March, and nobody discovers it until integration testing in the last fortnight. Nobody asked, because there was a document, and the document was the reason not to ask.

Which is why marking a document superseded is genuinely more valuable than updating it, if you only have time for one. And it is why the version-control question matters more than the content question: if three copies of the specification exist in three places, the accurate one is not the one that wins, the most conveniently located one is. Consolidating to a single location with a visible last-reviewed date does more for correctness than any amount of editing.

Six months of drift is also a process finding, not just a housekeeping one. It says the team changes requirements in conversation and records them afterwards or not at all, and no amount of catching up alters that. The durable fix is to change what carries the requirement — put the rule in the acceptance criteria where it cannot be skipped, keep the data dictionary next to the schema, and stop maintaining anything nobody reads.

Ask what each document is read for before you update any of them. Marking a stale artefact superseded is worth more than editing it, because a document that is confidently wrong is read by people who would otherwise have asked.