I’ve seen a number of projects that follow a path something like this — gather requirements (there are a bunch of steps in here), do some pruning, flesh out requirements, do some more pruning, mark the requirements importance in some fashion (such as low/medium/high), get the document approved, and say “GO!”. Once the GO is received, the requirements flow into the engineering process and begin their journey of becoming real software.
In an Agile process oriented world, the requirements would be put into a backlog and should mostly line up with the importance categories, though the actual ordering within those categories could be rather arbitrary. The Product Owner(s) would need to put things in the right order which may give them a short-term time-consuming task, but rearranging the order of the backlog in response to change is what they do anyway, so once it is mostly right the time needed to tune the backlog should be small.
One of the attributes of a Product Backlog is that the items toward the top are more “finished” than items lower down. That is, the acceptance criteria have received more attention, the effort estimates are finer, and the items are pretty much ready to enter a sprint. It’s just not worth doing that same level of effort for items lower in the backlog since things could (and often do) change before those items make it towards the top. This gets back to the “just enough” theme you’ll see over and over in Agile — do just enough to move onto the next steps so you don’t waste time and effort when you handle the changes that inevitably arise.
So, how great would it be if the requirements started off life in a backlog-like fashion? As the requirements are forming up, putting them in a backlog and in a rough order informs you as to where to spend the most effort in fleshing items out to the appropriate level of detail. UX and architects know where to focus efforts as they consider what will be built, and paying attention to what gets delivered in what order guides the roadmap. Ideally, the backlog would need very little work between the form-it-up stage and the first development sprint — shovel ready! You can still use the same documents as before, in most cases, but the requirements section would be in the form of user stories with acceptance criteria, and so on. You might have to show a couple of flavors of the backlog items (e.g., by order, and by feature), but that could be done by using fields in the tool you use for backlog management. If you are using a requirements management system different from your backlog tool, then the linkage between the two would have to be worked out as well. The main idea here is to have only one authoritative source — the backlog.
