Ken:

To restate my orginal comment:   "The problem with, first thing, come up with a high-level - but adequate, "roadmap" of requirements: Nobody is smart enough.  If it were not the case, data flow diagrams would still rule the requirements engineering landscape."

But, if a first-thing, top-down approach is modified to be more pragmatic, it is amazing what can be done.   My approach to requirements elicitation on larger scale projects:  Proceed in as top-down a fashion as possible.    Key words:  as possible.    Basically, I start by creating some mid-level-of-abstraction data flow diagrams - not high-level, and not detail level - but somewheres inbetween.  This is an art, but, surprisingly, when you actually look at the system, is usually not all that difficult of a task.  This approach is much more feasible that trying to proceed starting from the high-level, and proceeding at too detail of a level results in the common "paralysis-by-analysis problems.   

What I focus most on is diagramming the  unchanging business essentials - not features.  (At the higher levesl, these business essentials are the goals and objectives.)  I may have some feature-related information to, for example,  help with readability, but it is all displayed within the context of a model that organized as much as possible on what must be done irregardless of any implementation considerations.   Deprioriting features as much as possible  is key.

I do not get carried away with the data flow diagrams.  Example:  Instead of creating a data dictionary, I just create some notes that expand upon the lables that I gave to the data flows.  I have always found that this is all the development staff realy needs to proceed and working this way is key to rapid analysis.

I then perform structured walkthroughs on the diagrams to verify them.   This usually requires at least a couple of iterations, but since they are not detail level, and since they are quickly created on pencil and paper, required time is minialized.

I next summarize these mid-level diagrams upwards into "the big picture".   Now the project has a big picture of that has gone through some rigorous analysis.   Now the rest of project can proceed in an Agile fashion, making changes  as necessary to the big-picuture.

Tony