Cathy:

The BABOK 2.0 was organized around input/process/output diagrams.   But these integrate very poorly.  When you reorganize the BABOK using INTEGRATED input/process/output diagrams (i.e., data flow diagrams) you can very easliy see that no one is going to be able to use the BABOK come up with a systematic understanding of what  a BA is supposed to do.  They will only get  a bunch of bits and pieces of BA tasks.

As business analysis is mainly about coming up with a comprehensive, integrated understanding of essential buisness process, teaching BA's by referring to a handbook that is very disjointed is obviously  problematic.  And as the BABOK has been reviewed and signed off by alot of the "experts", I highly suggest ignoring most of them also.

If you want your BA students to rocket to the head of the pack, the most important thing to do is to teach them how to position BPMN diagrams (and other flow-of-control diagramatical techniques such as activity diagrams), data flow diagrams, and use cases relative to each other.  No - the choice is not to be made by what "feels alright".     Analysis is largely about partitioning, and each of the techniques that I mentioned is based upon a fundamently different approach to partitioning.  Remember Analysis is Partitioning!
 

Tony

 Here are a couple of topics that I think are important;

• Understanding business models and how value is created so that BA/project work can be fit into a useful context and the issues of alignment and value are always addressed
• The importance of leadership, communication and interpersonal skills.  How to manage conflict and how to get buy in from potentially reluctant stakeholders
• Systematic problem solving skills that are domain independent (e.g. work well in a technical or industry context.)  Maybe the 6Sigma or McKinsey stuff would be a good example of this
• The history of BA knowledge and theory so that students understand that the current set of best practices is just a part of the total knowledge and they'll need to continue to evolve their skills
• The importance of defining done e.g. SMART goals, measuring project and system development work in terms of "physical % complete" or in agile parlance "Done-done"
• Balancing strategic and possibly aspirational goals with an honest assessment of organisational capabilities

Also useful

• The ideas of small experiments and incrementalism and how small steps go a long way - eg protypes and iterations
• Loads of real world case studies