Define the purpose and function of the use case view.
The use case view contains only one model, the use case model. As the name implies, it focuses on the ways users will use the system. The name itself came from Ivar Jacobson's work on the object-oriented software engineering (OOSE)/Objectory methods.

The goal of the model is to identify the functionality required by users before trying to model a solution. The model uses a diagram, a narrative description of the diagram, and scenarios to model these requirements.

The model identifies the external users of the system and the key features the system must provide to be considered successful. You might compare this perspective to the RFP process for selecting a vendor product. You would identify the features that you are looking for and measure the vendor's offerings against these features. Furthermore, once a choice has been made, the requirements function as the testing criteria for implementations and enhancements.
Each of the leading methodologies recognized the need to model users' needs apart from the software mechanisms used to support them. Hence, it was not a difficult decision to include the use case model in the UML.
The use case diagram itself is very simple, too simple for some folks. One particular challenge with the model is its similarity to functional models. We willl cover the use case model in depth in the next module and help you discern the key differences between these techniques.
In the next lesson, the logical view, the most inclusive of the four views, will be discussed.

Use cases 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 (i.e., 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. For example, Figure 2-6 depicts a use case diagram for a simple watch. The WatchUser actor may either consult the time on their watch (with the ReadTime use case) or set the time (with the SetTime use case). However, only the WatchRepairPerson actor can change the battery of the watch (with the ChangeBattery use case).

The WatchUser actor may either consult the time on her watch (with the ReadTime use case) or set the time (with the SetTime use case). However, only the WatchRepairPerson actor can change the battery of the watch (with the ChangeBattery use case). Actors are represented with stick figures, use cases with ovals, and the boundary of the system with a box enclosing the use cases.