A common problem that can happen with use cases is that by focusing on the interaction between a user and the system, you can neglect situations in which a change to a business process may be the best way to deal with the problem.
Often you hear people talk about system use cases and business use cases. The terms are not precise, but the general usage is that a system use case is an interaction with the software, whereas a business use case discusses how a business responds to a customer or an event.
I don't like to get too bogged down in this issue. In the early stages of elaboration, I lean more toward business use cases, but I find system use cases more useful for planning. I find it useful to think about business use cases, particularly to consider other ways to meet an actor's goal.
In my work, I focus on business use cases first, and then I come up with system use cases to satisfy them. By the end of the elaboration period, I expect to have at least one set of system use cases for each business use case I have identifiedat minimum, for the business use cases I intend to support in the first delivery.