What is a Living Requirements Document?
Treefrog Consulting · 2026-11-10
The problem with requirements documents
Written requirements are read by nobody, interpreted by everybody, and discovered to be wrong at go-live. People cannot tell you what they need by describing it; they can tell you instantly when they click on something and it is not right. Every experienced engineer knows this, and every traditional project ignores it.
What a Living Requirements Document is
A working prototype of the system, with your data in it, built in days rather than months, and put in the hands of the people who will use it. They click through it, leave comments, and the comments become the requirements. Within a week the prototype has been revised twice and reflects what the team actually needs rather than what someone wrote down. It is called living because it keeps changing until it is right, and because it does not die when the build starts: it becomes the build.
How it feeds the build
At Treefrog the prototype your users shaped is the prototype we build from. Screens, rules and data model are already agreed with the people who will use them, so engineering starts on day one with no interpretation gap. The AI parts of the system are proven against real data as a proof of concept alongside it. Nothing is thrown away between stages; the prototype becomes the production system.
How it feeds a buy decision
If, having seen the prototype, you decide to buy rather than build, the Living Requirements Document becomes the vendor scorecard. Every product is judged against features your users have validated by clicking on them, not against a demo. The nine things they said they cannot live without are a checklist, and a product that fails three of them is out, however good the sales call.
Where it came from
Treefrog has delivered requirements this way on (re)insurance, ILS and investment-fund systems for years, because the alternative — a sixty-page document and a surprise at go-live — had failed too many times. AI-accelerated engineering made the prototype cheap enough to build in days, which is what turned a good practice into the first step of every engagement.
Frequently asked
How long does a Living Requirements Document take?
A first clickable version is typically in users' hands within two to five days of the workshop, and revised twice within the following week.
Is it throwaway?
No. The prototype your users shape is what we build from, so nothing is lost between requirements and build.
Can we use it to choose a vendor instead of building?
Yes. It becomes the scorecard: every vendor is judged against the features your users validated in the prototype.
Does it use real data?
Where possible, yes. Real data is what surfaces the edge cases that written requirements miss.
The sooner we talk, the further ahead you finish.
Thirty minutes with a senior engineer. You leave with a scoped first build and a clear read on build vs buy, whether or not you hire us.