At the highest level, there are two catagories of requirements gathering:

1.) Following the flow of data and let that discovery process prod the analyst through rigorous discovery of functional requirements. (Identifyication of data flows is the lithmus test of completedness for functional analysis. If the analyst does not ID the data flows, it is impossible to tell what is missing.) Example: Data Flow Diagrams. BPMN diagrams also allow for capturing of data flows, however, they discount the importance of them.

2.) Write up requirements as they happen to pop into your mind. No lithmus test of completedness is used. Examples: Use Cases, User Stores.

Both approaches can be used on an agile project. (Yes, data flow diagrams are just as appropriate with small iterations as in a pure waterfall approach.) Granted, realistically, the business subject matter experts will probably only use user stories (because of their simplicity). And having the business people proactively document requirements is the way to go. But, especially on a larger scale project, unless a lithmus test of completedness is utilized at some point, big problems will occur - agile or not.

Tony