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