Kimbo:

I prefer an "interview the data" (i.e., follow the flow of data, such as  PO info), focusing on the unchanging business essentials, and proceeding in as top down a fashion as possible.  Ideally, this would be to first create a Context Diagram; but, as it is basically impossible to find people who can readily give me adequate info at this of abstraction, I start with lower level DFD's (that are still higher in abstraction than like BPMN diagrams.).   I later summarize upwards to create a Context Diagram to verify scope.

In doing the above, proper partitioning is needed for effective decomposition.  And effective decomposition is needed to handle complexity.

Important:  The real challenge in requirements analysis is not to just gather standalone requirements.  It is to discover the essential interrelationships (i.e., the data flows) between the requirements.  Only data flow diagrams enforce such analysis. If the BA wants an upfront large group brainstorming session to discover initial standalone requirements, that is OK.  Just be keenly aware that, ultimately,  it is all about understanding the interrelationships - not just stand alone requirements.

 I sometimes elicite requirements and their interrelationships working  with one or a few users, sometimes with a larger audience.   Workshops have their limitations.  For example:  Especially for the first couple of iterations, the diagrams are a bloody mess.  (It is real important to feel comfortable with such - alot of BA's are not - they need order as soon as possible.)   I do not walk through a bloody big picture in front of a larger group.  It is too hard to maintain control.   

Typically, by maintaining control, I mean ensuring that the conversation does not get technical - thereby taking the focus off of the business essentials.  It also means controlling to ensure that the discussions do not get too detailed. It is easy to, as Yourdon used to say "drown in an ocean of detail."  (Tech and detail requirements are addressed at the appropriate time - in later phases of analysis.)

In documenting detailed process/functional requirements, I transition from DFD's to sequence based techniques (BPMN like techniques).

Key things are  to maintain a high level of initiative to "keep the door open" with the end users to do multiple iterations, and to be pragmatic as to whether a group elicitation session or a smaller session is appropriate.   Typically, the way to go for the situation at hand seems fairly evident.  

Tony

Kimbo:

Yes I have created DFD's on a whiteboard in front of an audience: but I need to be really quick to be effective.   Look at the Yourdon DFD technique.  Ever wonder why the technique uses circles and curved lines?   Answer:  This is for quick rapid prototyping - circles and curved lines are the quickest to draw.  Also, I just focus on main flows, not, as you mention, alternative  and error paths.  Qucikly draw (only) the essentials , erase for mistakes, quckly redraw - rapid iterations.  If I miss stuff, no problem, I approach individuals later.  The key is that creating a diagram that focuses on the essential (i.e., the  data flows) - even with errors - is going to get one alot further along than diagramming without a focus on the essentials.

To illustrate my point about systems being non-sequential, look at the BABOK 2.0.    A system can be manual, automated, or combo there of.   And a  requirements spec specifies the behavior of a system.   The BABOK 2.0 is in itself a requirements spec!   It specifies the behavior of a system of one or more BA's performing tasks to create a requirements spec.  It is a requirments spec on the processes to be used to create  requirements specs.

Read what the BABOK 2.0 says about the conventions used in its creation:  There is no defined sequence to the BA tasks; any task/process  can kick-off at any time, provided it has it's required inputs.   This is exactly what I am talking about:  The non-sequential nature of systems (especially true at higher levels of abstraction). 

Key point:  The system that the BABOK models is not all that complex.    The non-sequentiality of systems becomes much bigger issue with larger scale system.   It is not possible to use a sequence-based technique such as BPMN with such.

Now, in order to handle the non-sequential nature of a system of BA's performing tasks, the BABOK utilizes non-integrated input/process/output diagrams.    This is very problematic as none of the diagrams tie together well.  It is impossible to systematically understand what the BABOK is saying.   The should have used INTEGRATED input/process/output diagrams (i.e., data flow diagrams.)

At the detail level, I use a sequence based technique to document tasks/processes.  Such is necessary to capture logical rules.  I decompose my DFDs down to a point where processes can be described using a sequence based technique that will fit on a single page or so of paper.  Note that each bubble on a data flow diagram can be considered as a mini context diagram.   A DFD can be viewed as a set of mini context diagrams integrated together.   You agree that a BA can start with a context diagram and then switch to a sequence based approach.   In the same way, individual processes on a DFD can be described using a sequence based approach. 

Tony