One thing from your comment about what defines the level of detail that you go into in writing a use case. There are really three variables at play – what level of detail, when you go into it, and who does it.

What level of detail
Is a function of trust. How much does your customer trust you to “do something great”, and how much do you trust your development team to “do something great”. Those two trust-factors determine how much specificity your customer requires in the spec, and how much restriction you place on the developers.

When you go into it
When doing estimations, you can use vague and high level use cases to help create order-of-magnitude estimates. You still need to specify more detail down the road.

Who does it
This is where design meets requirement. The more control you give to the developer, the more she is going to define and design the way a use case is enabled by the software. Ultimately, someone decides. The only question is if it is part of a documented “approval” process, or an undocumented “acceptance” process. Either way, if the customer’s expectations are not met, they aren’t met.

Personally, I strongly prefer the informal use case, because of the level of energy that comes from a team when reviewing or defining them. It becomes a self-sustaining fusion reaction of ideas. There is definitely merit to the formal use case too – when customers want more control over how you choose to interpret their needs, it can be a very effective instrument for managing expectations and relationships. As I talk about in the “dance steps” section of the Foundation series post on software processes – the right use case framework is a function of the customer and the team.

- writing a Use Case specification using a formal (more or less structured) or informal style
- what to include in the Use Case, how much details get in (the brevity arguement).
I agree with you that it all comes down to communication, but I prefer less ambigous documents above short documents. It’s generally not a good idea to speed up your project by shortcutting the requirements work: slow down if you are in a hurry!

We’re using Use Cases extensively in our projects and write them iteratively as RUP suggests.
Use Cases pass the stages RUP defines:
- “Identified” (You name the Use Case)
- “Shortly described” (You add a short description, e.g. reference the user goals)
- “Outlined” (You add detail up to an agreed-upon level)
- “Fully described” (All details included that are needed by both the designer, tester and user documentation specialist).

Our fully described Use Cases are much like your “Formal” Use Cases documented using a template with a sound structure (see http://blogs.infosupport.com/harryn/archive/2006/01/04/3341.aspx for a sample).
The level of detail you go into for the “Outlined” Use Cases depends on the goal you have for them. They are mostly used to define the scope of the project and/or make estimates on the development time and cost. If the estimates need to be very accurate, much detail is needed in the outline. If the estimates need to be in man-months, less detail is done.

Not all fully described Use Cases need the same level of detail. E.g. mainenance Use Cases where reference data are maintained can be described very briefly, without the need to go into all the details of alternative flows.

So to recap: we use both formal and informal Use Cases, and add different levels of detail.
During the courses I teach (e.g. the IBM/Rational course Mastering Requirements Management with Use Cases) must students have trouble getting the first lines on paper. Once they got started things get better. To my opinion, you can use this as counter evidence for the statement that informal Use Cases are easy to create.
When I count the numerous requests for templates and samples I get, I’m confident to say that most (beginning) Use Case specifiers prefer a structured template with some guidance above an unstructured one.