Jan Kettenis has written a long and eloquent post defending Use Cases as a method of describing Business Requirements: About Business Processes, Use Cases and SOA (1). "What I sometimes hear (and I don't exaggerate) is that a service delivers some reusable piece of functionality that cannot be pinpointed to a specific use case, so use case are useless." Jan clearly thinks this is wrong, and constructs a moderately complex example to illustrate how use cases can be useful.
I do agree that use cases can be useful - but my own view is that they are mainly useful for describing a solution (however abstract) rather than a pure requirement. In Jan's example, use cases help to specify the behaviour of an entity called Parking Services. (According to Jan, this entity is an organization rather than a system, but I don't think it makes a difference to my argument.)
But how do you decide that there should be a single entity called Parking Services in the first place? It is a design decision (business design, not software design) to cluster this behaviour together rather than distribute it across multiple entities. Because I want my description of the requirements to leave such design decisions open, I prefer to describe the requirements purely in terms of some set of outcomes for some set of stakeholders. I think there are usually many different solutions to requirements like these, and each solution can be described in terms of some collaboration between a number of entities behaving in certain ways.
Thus I accept that use cases have a place in the requirements and design process, but I think it is often a good idea to defer the production of use cases until the solution space has been adequately explored.
I think Jan actually concedes this point. "Normally a use case will not be created in one blow at this level of detail. It is more likely to be created in a few iterations of which the first one might suffice to document only the stakeholders, goal and main success scenario together with some business rules."
There is another problem with a use-case-driven approach to business requirements, and that relates to reuse/repurposing. If I start my service design from a set of use cases for the "Parking Services" entity, then there is no reason to expect these services to be of any use in any other context. Yes, a service is supposed to deliver a "reusable piece of functionality" - and so we probably don't want to restrict the use of a given service to a single use case. (Is this what Jan means by "pinpointed"?)
When I analyse business requirements, I want to think about flexibility: that means thinking about supporting not a single interaction but a range of possible interactions. For example, what are all the ways that a doctor can interact with a drug company, what are all the channels (direct and indirect) that a doctor might use to get information about a drug company's products, and how can we build rich services that support as many of these interactions as possible?
Jan ends his post by highlighting one of the most valuable consequences of documenting use cases - exposing questions and issues about the business process, which arise from the rigour of use case analysis. Rgorous analysis is always praiseworthy, but sometimes it requires just as much discipline to avoid preempting design decisions.