I agree that the left hand side of the Vee has to be seen as a two way street. As we develop the code we gain experience and insights which enable us to elaborate and refine our requirements. The requirements then act both to guide the development of the system and also to document the lessons that have been learned during development. The output of early requirements elaboration phases are then draft, rather than final, requirements sets.
The key, for me, is the tooling that we have around maintaining requirements and the traces between them and the code. I think that it should be possible to navigate traces and update (low level) requirements and test specifications without leaving the text editor. If it takes 5 minutes to open DOORS and to find the relevant requirement, then you aren't likely to keep it as up to date as you should. The same is true if the requirements are stored on a spreadsheet in a document management system.
Some ALM/IDE tools may enable you to manage things in a better way. From what I have seen, mbeddr is a really interesting experiment along these lines. I also suspect that Visual Studio and Eclipse have some pretty powerful features in this regard.
In my side project (and purely for my own 'entertainment') I am experimenting with ways of embedding low level requirements into comments in the code (the build extracts them and can update DOORS or some other tool), as well as a generic trace system that allows different classes of traceable item to be defined and indexed. The build can enforce requirements coverage in the same way that it enforces test coverage, and because the text and metadata of requirements is easily accessible to the build, we can use NLP tools to enforce the use of restricted natural language or DSLs in the requirements text. The ultimate goal being to use machine learning to learn the correlation between requirements changes and code changes so that a change in one can help generate advice and guidance on what needs to change in the other.