Craig:

When I took the Yourdon course on data flow diagramming, the instructor emphasized that ninty-eight percent (98%) of the required work in a software project is coming up with a comprehensive, integrated understanding of the "as-is" .   Such as always been my experience for larger scale efforts.   Therefore, I say a model of what a BA should do should consist of one really, really big function box labled something like "caputure the as is", and a set of much smaller boxes for scope, requirements spec, design, develop, implement, etc.

Without proper emphasis, the typically situation is the most important task gets very shortchanged.   I have seen this time and again.    The urge to implement is just too strong.

Tony

A related question:  Have any readers come across Business Analysts - even very senior level - who have never actually created and verified a set of use cases?  

I recently lead  a couple of larger scale across-system integration efforts at a very big company.  In doing such, I had as an input the requirements specs for all the systems that were within the scope of my efforts.   This represented the work of probably a couple dozen BAs.   With just one exception: No use cases - just text based requirements docs, with maybe a vaugue functional model (you know, with clouds, lightening bolts, unlabled arrows, and graphics of PC's and Mainframes).    This was dispite the fact the company teaches an on-going and continually well attended course on requirements elicitation that focused on using use cases

Unfortunately, many in IT,  BA's and developers alike, need to be grounded in the implementation details.   To venture into the higher levels of abstraction is too risky for most.

Tony