As a business analyst there are plenty of techniques to use for post-requirement-elicitation clarification: use cases, prototyping (software applications such as iRise, UPerform, etc - or excel/visio), swim-lane as-is/to-be process flow diagrams, wireframes, etc. How do you know when it is appropriate to use which technique? Is it based on the type of project? Is it based on cost and/or schedule limitations of that project? If the business wants the best result, the more techniques and straight forward documentation used the better, although that is never the case based on lack of budget. What is your go to technique, and what are the pros and cons of each?

While I agree with Tony that Data Flow Diagrams are a powerful discovery tool, I think that many other tools are just as helpful.

First, I would say that "whatever feels right" to use isn't all bad.  An experienced analyst should be able to assess the project circumstances and determine which deliverables will be needed to ensure the projects success.  No one process and set of artifacts fits all circumstances.  Sure, you can use them all everytime, but that would be a substantial waste of resources in some circumstances.

In the end, regardless of the project type, size, scope, etc...you need to be able to answer all of the same questions.

1) Do you understand the Customers Need and how this system should support those needs?  This goes beyond requirements.  Do you understand the rationale for each requirment?

2) Do you understand each business groups requirements? Sometimes different groups have competing requirements.  When a decision is made can you document why the decision was made so that looking back people understand why each requirement was satisifed the way that it was.

3) Are discussion happening using the same terminology?

4) Do you understand the data that is being used by the process that the user is trying to complete.

ETC...

Regarding artifacts and deliverable, almosts all projects require some form of:

• Requirements list with traceablity to the customer needs and down to the other solution documents.
  
• Business Entity Model or Fact Model
  
• Process Flow (UML or BPMN) to document AS-IS and TO-BE states.
  
• Functional descriptions of how the systems UIs should behave.
  

Tony,

Don't get me wrong, I'm all for following a prescribed plan, hence the use of tested methodolgies.  My only point is that you can't simply follow a checklist of deliverables to create and hope that all will end well. 

It's imperative that the analyst understands that benefits of each technique/deliverable and assesses whether the cost of creating such a deliverable for the specific project outways the risk of not having it.

In short, analyst actually have to do analysis.  They have to take their brains out of neutral and put them in gear.