A use case is a written description of how a system behaves in response to interaction with an actor. It should produce a measurable result (output) which is of some value to the actor. Therefore if we write use cases, we have a means by which we can record what the system will do from the actor's perspective.
This helps us define what a user will see when they interact with the system, or in the case of a non-human actor, will assist the description of what messages need to be exchanged between a system and an actor.
Because use cases deal with what an actor sees, we should not concern ourselves with hidden operations. Use cases should be simple to read.
Each use case should also describe a sequence of events from start to finish, that are completed in a relatively short time. Should a use case require a lot of time to complete, or require input from other actors, then it is probably written at too high a level and should be separated into smaller use cases.
On the face of it, use case descriptions sound a lot like processes - and of course they do describe the steps required to complete a particular procedure. However, beware of use cases that are merely processes copied from an organisation's procedures manual. They probably don't reflect how the business really operates, and they almost certainly will not describe the behaviour of the system from the actor's point of view.
UML includes some notation that allows use case diagrams to be constructed. Such diagrams make the process of defining system boundaries much easier, by representing actors and use cases together on one sheet of paper. Whilst these are important as communication tools, they are useless unless the use case descriptions have been written first.