I have come across many BAs who have no/little experiences with use cases.  I think you have to see use cases in the context of the product lifecycle.  It's only really been in the last couple of years that they have hit the middle of the bell curve.

That plus the exponential growth of projects and the demands to staff them mean that your analysts can come from very diverse backgrounds, and not all of them have come through 'traditional' training and coaching.

As an aside - I am a senior BA (and PM) and rarely deal with use cases, let alone write them.  My main modelling tool tool is a (bastardised) context diagram and occaisionally unstructured flow charts and decision trees.  I do work above the details of system requirements though - my focus is more about integrating the business with technology than what's going in the box.

In fact when it comes to modelling - this PDF from ChangeThis.com aligns with my heretical views on modelling.

ajmarkos wrote David: The company that I was talking about teaches a requirements specification course that revolves around first creating a Context diagram, and then a bunch of Use Cases.    This is not my course, as a matter of fact, I feel that such an approach is based on the following unrealistic assumptions: 1.)  That someone, anyone, can, up front can develop a context diagram.  This is not going to happen with larger scale efforts. --> Why not? I use such diagrams in up-front scoping exercises. They are more like DFDs than a Use Case Diagram... 2.)  That anyone can develop an integrated set of requirements  for a large scale system using a tool that has no formal integration mechanism - use cases. --> You mean only use cases? If so, I agree, you need an Information Model at least, with supporting business rules, and with all these artifacts cross-referenced.