Sounds like you are looking for something close to the way we manage projects at work. We start with a Software Requirements Specification which is mostly a non-technical list of features that may be included in the project and is signed off on by the team manager after consultation with the stake holders. It is the stake holders who provide the requirements in the first instance. The key to the SRS is that it lists three categories of requirement:

1. Essential: Items that must be completed and will push out the completion date if need be.
2. Conditional: Items that can be dropped to meet the completion date.
3. Optional: Items that can be included if the project is running ahead of time.

The key here is that project should be scheduled so that the essential items will almost certainly be completed on time and allowance should be made for the conditional items in the schedule.

The difficult part of course is the scheduling, but it is something that you get better at with experience. In our experience at takes between one and two years before you get fairly good at scheduling. We've been doing this for about five years now and my manager reckons that our schedules now are generally right within about 10%! That doesn't mean that every item in a project schedule is right within 10%, but that over the course of the project we hit the time within 10% of the scheduled time.

We do do the scrum thing. We do have a project supervisor for each project who is the person responsible for overseeing the project. We do not a allow additions or alterations to the SRS without reassessing the project's schedule. The SRS is a great tool for waving in the face of the stake holders and saying "This is what you signed up for. If you change your mind we will alter the schedule to suit.". It turns out to be a powerful document that we don't need to use in that way very often.

After we have sign off on the SRS the project team leader prepares a specification document which is technical and provides the detail required to guide the implementation of the project. This document is for the team only and tends to be rather mutable. If the specification document turns up issues that weren't foreseen in the SRS, we go back to the stake holders and sort the issue out up front.