UML Use Case Diagram

Use Case Diagrams are used during requirements elicitation and analysis to represent the functionality of the system. Use cases focus on the behavior of the system from an external point of view. A use case describes a function provided by the system that yields a visible result for an actor. An actor describes any entity that interacts with the system (e.g., a user, another system, the system’s physical environment). The identification of actors and use cases results in the definition of the boundary of the system, that is, in differentiating the tasks accomplished by the system and the tasks accomplished by its environment. The actors are outside the boundary of the system, whereas the use cases are inside the boundary of the system.
A use case illustrates a unit of functionality provided by the system. The main purpose of the use-case diagram is to help development teams visualize the functional requirements of a system, including the relationship of "actors" (human beings who will interact with the system) to essential processes, as well as the relationships among different use cases. Use-case diagrams generally show groups of use cases either all use cases for the complete system, or a breakout of a particular group of use cases with related functionality. To show a use case on a use case diagram, you draw an oval in the middle of the diagram and put the name of the use case in the center of, or below, the oval. To draw an actor (indicating a system user) on a use-case diagram, you draw a stick person to the left or right of your diagram (and just in case you're wondering, some people draw prettier stick people than others). Use simple lines to depict relationships between actors and use cases, as shown in Figure uml.03.

Figure uml.03 Use Case Diagram
Use Case Diagram is typically used to communicate the high-level functions of the system and the system's scope. Apart from the use case diagram you must describe each use-case with the following format:

Use Case: Name of the Use Case.
Actors: Users or external agents that interact with the system.
Purpose: The intention of the use case or its purpose in the system.
Summary: A high-level summary of the processes.
Type: Primary (common), secondary (rare or not so common), optional.
Cross References: Related use cases and functions related to the system.
Description: A detailed description of the use case.

There are other formats which may be used but I would suggest this one as it is usually the easiest to understand and implement.

www.CodeNirvana.in