A use case is a specific case of usage, tracing a particular task through from start to finish. Rather than concentrating on how the system functions, use cases describe what the system must do from the user's perspective. A use case begins with some stimulus from someone or something outside the system (an actor, which we will discuss in more detail shortly).
Though more detailed than requirements, use cases are still quite informal. A use case should be a natural-language description, not pseudocode, and it should avoid any unnecessary assumptions about implementation. A use case should do the following:
The style and level of detail to use in writing use cases are matters of judgment and experience. The amount of detail you should include depends upon the novelty of the system and your familiarity with the problem domain. The level of detail can also vary from one use case to another: some might describe high-level interactions of real-world elements, while others might describe low-level interactions of actual system objects (when such objects are known). But try to avoid mixing levels of abstraction within a single use case.
Above all, remember that use cases are not formal; they are written in natural language rather than adhering to any rigorous, readily programmable semantics. This can lead to some imprecision or ambiguity, but it has the advantage of making the requirements readily understandable to, and verifiable by, the users of the system.