Optimization, in the business world, is usually a misused term. In math, engineering and computer science, when you ask someone to "optimize" something, the first question they will respond with is, "Optimize, in terms of what?" In business, we often forget to ask that question. There are many aspects of managing requirements, along which you can make the requirements "better" -- which is what optimization is about. The aspect that relates most to development-process decisions is not having the requirements be correct, but rather managing the communication of changes in the definition of "correct" for those requirements. Other elements, like completeness, consistency, etc., are also still important -- but the aspect you need to optimize for when focusing on the development process is the communication of changes in your understanding of the requirements.
Requirements live outside the organization -- your customers "own" your requirements, or rather, the market, collectively and implicitly, defines what the requirements actually are. As a product manager (or business analyst or requirements manager or product owner), you neither own nor define the requirements -- just as Benjamin Franklin did not "define" electricity by flying a kite during a storm -- you can only discover the requirements and make decisions about which ones you choose to address. These requirements are always changing, and your understanding of the requirements is always changing. The result is that your requirements documentation is always changing.
As you update your documentation of requirements, and share that documentation with the development (and quality and marketing, etc.) team, you will be faced with minimizing the cost of two key factors -- first, how much time the receiving teams spend absorbing the changes, and second, how out-of-date the documentation becomes. You can reduce the cost of "changing requirements" (from the perspective of whoever is reading your documentation) by sending out updates less frequently.
To minimize this cost, you simply don't send out updates. This is how a Waterfall process works. You take a snapshot of your understanding of requirements at a moment in time, and that is what the team builds, even if it takes a year or more. Waterfall processes are designed to prevent the "requirements churn" of updating the team with new information - change management boards, "horse trading" and scope-management are examples of this. Only the most significant changes in understanding are allowed to make it into the project, and the process is designed to make it painful to incorporate these changes, so that the project team is not interrupted by spurious change requests.
One of the drivers of incremental development processes is a response to this myopic cost-avoidance strategy, which biases massively to reducing the costs of change and effectively ignores the costs of building the "wrong" thing that might be incurred because the documents are out of date. Agile development utilizes incremental development in its cadence. Instead of locking the doors against change for the duration of the process, the team's operational approach opens those doors at the end of every iteration. This approach minimizes the maximum amount that requirements documentation can be out of date.
Embracing and encouraging updates in that documentation every week or two, from a practical perspective, reduces the costs of out-of-date documentation as far as they can be reduced. Unlike Waterfall processes, however, the proponents of Agile development did not ignore the costs of change. They developed a process approach that is effectively immunized against the costs of change. Discrete tasks, with atomic, measurable value are delivered by the teams within each iteration. The "most important" (and implicitly, least-likely-to-change) items are built first. The team's expectation is that anything "in the pipeline" beyond the current iteration is subject to change. Within the iteration, the team -- barring emergencies -- does not accept changes, protecting them from emotionally-disruptive churn and change.
The best approach that I have found so far is to maintain evergreen, "living" documentation as a product manager. The user stories and acceptance criteria (or use cases and requirements) that are delivered to the development team have been defined to support specific goals (user and corporate), in order to embody a particular strategy for entering a market. That strategy balances understanding of market needs, investment constraints, competitive environment and overall corporate goals for approaching the market in a particular way.
The backlog of stories is an evergreen "document," from which a snapshot is taken by the development team at the start of every iteration. The product owner should be continuously grooming that backlog with changing content, relative prioritization and clarification/communication style to meet the needs of the team. These updates reflect both a tuning of the way the communication works to be most effective and updates to the content to reflect changes in how the goals are changing and how the decisions about how to achieve those goals are changing. When the requirements are documented within a monolithic document like a business requirements document (BRD), that document should also be continuously updated, with labeled versions being delivered. This is different than thinking of the BRD as "done" -- a classic "throw it over the wall" problem.
From a requirements management point of view, the documentation of all of the drivers of why the backlog/BRD makes sense, should be maintained as a living document as well. Your understanding of these drivers will be changing regularly. You should update your documentation of your understanding of these things as rapidly as is practical. Ideally, a reader of your documentation can easily jump from "this is the goal" to "here is how it is being/has been addressed" within the product backlog or requirements document. However, much more frequently, your internal team will be asking the question in the opposite direction, "Why are we being asked to do X?" The most important tracing you can have is from each user story and acceptance criteria (or use case and requirement) to the goal that it supports and the rationale for why it is important.
The next fun topic -- what do you imagine would happen if your development team looks at the BRD that was written a year ago, tries to follow the link for "Why are we building X" and discovers (when reading the evergreen document) that it is no longer relevant. How should that team behave now?