The real genius is to propose a simplified solution, by discarding some assumptions. This is the best and only way to shrink the schedule
I think it's less simplification and more precision and completeness. Obviously if you have simpler requirements they more complete and precise, but the requirement might not actually be simplifiable. In which case what you want is better specification.
"They write the right stuff" about the shuttle software group is basically a story about doing that: https://www.fastcompany.com/28121/they-write-right-stuff
In fact, what you are doing is tying the developer's hands and making it less possible for them to nimbly work around unforeseen obstacles or repurpose existing solutions without raising a "process exception" to reopen the spec or sizing of a work item.
Be clear about the goals but let the developer(s) who have their hands in the code make the decisions about how to implement it. That means you can't really roadmap a big project down to the minute, but those roadmaps were always lies so there is literally nothing lost except for some fantasy Gantt charts.
Requirements and roadmaps are very different in my opinion. Requirements say what the product needs to do, scaling and/or response time targets, systems or needs to integrate with, etc. Roadmaps are either a high level plan for where the project goes in the future or a list of seemingly arbitrary deadlines.
Both have their place, but in my experience the right balance has been precise and complete specs with a high level, flexible roadmap.
If the requirements were actually precise and concrete, you could commit them to git and that would be the end of it.
The fact that they aren't is a sign of information deficit and this must be understood by all parties if we should have any chance of a productive outcome.
The problems with precise specs is that they miss all the dozens of edge cases and gotchas that don't crop up until you actually try to code them. Then you need smart, imaginative devs to ignore the specs and write something that people can actually use.
I've worked with devs who write _only_ to the spec and never diverge at all, regardless of outcome, in order to check off boxes and make their managers happy. Their work sucks.
(this might not apply if you are writing code for moonships)