BDD- Behavior Driven Development
You define the working requirements of the software as automated tests.
Another term I enjoy using is executable specification that cannot be out of date if it passes
They initially fail as there is no code. The metric value starts at zero out of (say) five, so it is at 0%.
You write the code and they pass. The metric goes up.
If you have 5 initial requirements and 2 are done then the metric says you might be 40% done.
Although in reality the last task might be 80% of the work, etc. This is because making accurate predictions is quite easy. Except for those about events in the future.
Unfortunately unless you are doping waterfall or mini-waterfall, in Agile environments this should be happening constantly not in a waterfall way. In other words new requirements (stories) are coming in constantly.
You could try measuring your backlog but most backlogs just have the same shape - steep curve initially that flattens over time as the backlog just becomes an artifact and parking place of avoided work and technical debt and not a true source as the main feed into application development. This can be avoided by deliberate actions (I've done that) but that is a maturity many shops do not achieve. It takes a team effort and full ownership of the development process by the people doing the work.