I have never worked on a project that took that approach.  In my embedded product development experience, the requirements grow as the product iterations are delivered, evaluated and tested.  The results of those evaluations and tests will impact the requirements.  There will be additions, subtractions, and alterations of the requirements.  We will update the requirements documents, paying attention to the configuration and change management issues.

In the automotive world, we can see a steady and incrementing capability and feature content of the product both hardware and software  The product often starts off as an incarnation with few features and little capability or reliability.  The next iteration will have more of the feature content (additional requirements) and perhaps increasingly hardened hardware.  The hardware hardening will have its own growth plan with increased features and capabilities each with a new part number.  The final incarnation of the hardware will be from hard tooling and from the production processes.  The final incarnation of the software will include the prioritized feature content, perhaps all of the features but occasionally, due to time and budget constraints the lower level features may not be available. This iteration of the product will also be tested in many dimensions (for example – environmental, reliability, component and systems integration as well as fall-back modes).

Each iteration on the way to the final instantiation of the product is a review of what was built, specifically, the test and evaluation results. This test and evaluation of the iterations provide the feedback loop driving the design direction based on the discoveries.  The documentation and drawings are updated, and the next iteration of the design and documentation updates.  This goes on until the product is ready to move to launch or the project budget is busted.