The use case should not be just a description of what the system does, or worse, just what the actor does. It is events and data going across the system boundary through whatever system interface is available that should be specified. Otherwise it is possible to decompose internal system functionality down to an inappropriate level or to specify things that happen outside system that are out of scope. Including interactions that occur in the business but do not cross the system boundary may provide scope for the use case but will confuse the developer as to what has to be coded and what does not. Business only interactions belong in the business model, not in the requirements for a computer system.
If it is absolutely essential to specify some piece of internal system functionality as part of this model, then this is allowed provided that the minimum number of words and the highest possible level of abstraction is used.
