Originally introduced as a diagram for use in object-oriented UML, use cases are now being used regardless of the approach to systems development. It can be used as part of the SDLC or in agile modeling. The word use is pronounced as a noun (yoos) rather than a verb (yooz). A use case model describes what a system does without describing how the system does it; that is, it is a logical model of the system. (Logical or conceptual models will be further discussed in Chapter 7.) The use case model reflects the view of the system from the perspective of a user outside of the system (i.e., the system requirements).
An analyst develops use cases in a cooperative effort with the business experts who help define the requirements of the system. The use case model provides an effective means of communication between the business team and the development team. A use case model partitions the way the system works into behaviors, services, and responses (the use cases) that are significant to the users of the system.
From the perspective of an actor (or user), a use case should produce something that is of value. Therefore, the analyst must determine what is important to the user, and remember to include it in the use case diagram. For example, is entering a password something of value to the user? It may be included if the user has a concern about security or if it is critical to the success of the project.
Use Case Symbols
A use case diagram contains the actor and use case symbols, along with connecting lines. Actors are similar to external entities; they exist outside of the system. The term actor refers to a particular role of a user of the system. For example, an actor may be an employee, but also may be a customer at the company store. Even though it is the same person in the real world, it is represented as two different symbols on a use case diagram, because the person interacts with the system in different roles. The actor exists outside of the system and interacts with the system in a specific way. An actor can be a human, another system, or a device such as a keyboard or Web connection. Actors can initiate an instance of a use case. An actor may interact with one or more use cases, and a use case may involve one or more actors.
Actors may be divided into two groups. Primary actors supply data or receive information from the system. Some users directly interact with the system (system actors), but primary actors may also be businesspeople who do not directly interact with the system but have a stake in it. Primary actors are important because they are the people who use the system and can provide details on what the use case should do. They can also provide a list of goals and priorities. Supporting actors (also called secondary actors) help to keep the system running or provide other services. These are the people who run the help desk, the analysts, programmers, and so on.
Sometimes it is useful to create an actor profile that lists the actors, their background, and their skills in a simple table format. This may be useful to understand how the actor interacts with the system. An example is an Order Processing Specialist. The profile would be, “A routine user of the software, familiar with minor features, order exceptions, and order customization.” It is also useful to list the actors and their goals and priorities. Each goal may become a use case.
A use case provides developers with a view of what the users want. It is free of technical or implementation details. We can think of a use case as a sequence of transactions in a system. The use case model is based on the interactions and relationships of individual use cases.
A use case always describes three things: an actor that initiates an event; the event that triggers a use case; and the use case that performs the actions triggered by the event. In a use case, an actor using the system initiates an event that begins a related series of interactions in the system. Use cases are used to document a single transaction or event. An event is an input to the system that happens at a specific time and place and causes the system to do something.
It is better to create fewer use cases rather than more. Often queries and reports are not included; 20 use cases (and no more than 40 or 50) are sufficient for a large system. Use cases may also be nested, if needed. Some use cases use the verb manage to group use cases for adding, deleting, and changing into another, lower-level, use case diagram. You can include a use case on several diagrams, but the actual use case is defined only once in the repository. A use case is named with a verb and a noun.
- Use Case Symbols
- Use Case Relationships / Developing System Scope
- Developing Use Case Diagrams / Developing Use Case Scenarios
- Use Case Levels / Creating Use Case Descriptions / Why Use Case Diagrams Are Helpful
Contents
- Organizations as Systems
- Virtual Organizations and Virtual Teams
- Taking a Systems Perspective
- Enterprise Systems: Viewing the Organization as a System
- Systems and the Context-Level Data Flow Diagram
- Systems and the Entity-Relationship Model
- Use Case Modeling / Use Case Symbols
- Use Case Relationships
- Developing Use Case Diagrams & Use Case Scenarios
- Use Case Levels (Use case Modeling)
- Levels of Management
- Organizational Culture
