Anita:

In terms of requirements elicitation, the number one prority question to be built into a quick reference guide is:  How much complexity are we dealing with?   It determines what basic requirements elicitation approach is warrented.    He is the dirty little secret (for most people):   What works for smallish projects (lets say 5 to 7 processes that can each be documented on about a 81/2" X 11"  page logicial flow chart) will not work for larger scale projects.   In terms of system behavioral related requirements, use cases, user stories, and BPMN (and the BPM like) are for systems in the small.  You will not here this said anywheres else; even the BABOK is mixed up here.  Note:  Business systems are complex; I have been around for awhile and I can not remember working on a smallish business system.

For a variety of reasons, only data flow diagrams work for bigger picture business systems analysis.  With them, after one drisll down to the smallish level, he/she would then switch over to a sequence based technique like BPMN.

Regarding Agile, that is the way to go to same alot of time and money.  However, the majority of (probably the vast majority) of Agile projects only incorporate analysis in the small efforts, i.e., there is no attempt to do any up front modeling.  Be aware, even Scott Ambler espouses the need for an up front model - provided that it is done in an Agile fashion. 

Tony