Use Cases in a Nutshell

Why develop use cases?

Use case development begins in the early inception phase of a project. Initially, you only gather their names (e.g., "Draw map of poles") and a sentence or two for a description and put them in a list. These are used to determine the system scope. You revisit each use case and add just a bit more detail to it - a paragraph or two of text sufficient to get a high level understanding of the use case (these are called High-level use cases, and each is a separate document). At the end of inception, you choose a group of related use cases for development in the elaboration phase. Use cases go through several iterations of development in elaboration.

How do you develop a use case?

Use cases are analyzed and designed in meetings with the design team (at least one other person) and a subject matter expert. They will be developed in several phases, each of which will require a separate meeting. The users participate in developing use cases - they understand what they do, and you don't. For a given use case or group of related use cases, identify the people that perform that particular job or task and invite one or two to participate in a meeting between you and one or two other members of the design team.

Actors

An actor is a role adopted by someone or something that interacts with the system. It can be a person or another software system. Actors are always external to the system; that is, an actor is something that interacts with your system but that you have no control over. Actors typically initiate some interaction with your system. However, external systems may be an exception. For example, you might have a use case that asks the tax billing system for a list of owners for a parcel. A given user may play the role of several actors. Use cases are a series of interactions between an actor and the system to accomplish some task. As such, they are the fundamental element of your design effort. Full analysis of a use case will lead to a definition of the data the actor needs to do the task, the interface the actor works with and the process followed to accomplish the task. Here are some questions that can help you identify potential actors:

• Who manages your system?
• Who uses the data in your system?
• Who maintains the data in your system?
• Who needs to be notified when data changes?
• What other systems might use your system?
• Does anything happen automatically?

Actor tasks and use cases

As you define an actor, consider the types of tasks she would perform with the GIS. These become candidate use cases. Also, some of your project requirements may become use cases. You document actors and use cases in several ways. Your initial meetings with management will identify many of them, and you'll probably start with simple lists. For a complex project, you should put them in database tables because project details are easier to manage with a database.

Use case diagrams

This UML artifact is a system diagram that shows the relationships between the use cases and the actors that use them. Use case diagrams are important tools that help you to visualize the overall system architecture, to specify and document the behavior of system elements (actors and use cases) and to organize and model the behavior of your system.

Writing use cases

Use cases are considered part of the UML, but there is no standard for use case structure or content. You are free to develop any format you like. The key point is to clearly capture the business process in a textual, narrative form. The primary goal from a data modeling perspective is to ensure that all the important concepts (potential classes in the geodatabase) required by the use case get mentioned.

The basic structure of all levels of use case is the same - you include "header" information that names the use case, states its level, summarizes it, identifies the actors and the pre- and post-conditions. The major structural difference is in how the description is written. For business and design level use cases, you replace the description with more detailed "scenarios" that describe the typical path through the use case (the primary scenario), any alternate paths (the secondary scenarios) and how errors are handled (the exception scenarios).

Levels of use cases

Use cases are written at several levels of details. Each level is a refinement of the one before, until you have captured the essential actor I system interactions. A use case normally goes through several iterations before it is finalized. The levels are:

• High level use case (written in the late inception phase). The high level use case is simply a summary description of the task, written as unstructured text a paragraph or two in length. Its purpose is to provide just enough detail to give you a feel for its complexity and to help you group related use cases for development in the Elaboration phase.
• Business level use case (written in the early elaboration phase). The business level use case captures the business process (the "user view") as a time-ordered sequence of steps. It does not show the human/computer interactions - you write it as though the actors do all the work. It identifies the process (for application development) and domain objects (for data modeling). It is written in a meeting with the design team and a subject matter expert and may take hours or a day or two to write clearly and with sufficient detail for data modeling. Conceptual models are often simultaneously developed.
• Design level use case (written in the late elaboration phase). The design level use case captures the interaction between the actors and the system - you determine which steps in the use case are the responsibility of the system. The description is written as a dialog between the actors and the system. Writing a design-level use case is actually the beginning of application design, and may proceed through several iterations of refinement until it introduces interface controls.
• Product use case (created in the elaboration phase). These aren't really use cases at all. They are simply detailed specifications used to generate products.

Scenarios

Business level and design level use cases generally have scenarios. The types of scenarios are:

• Primary scenario. Documents the most common path through the use case. Required for all use cases.
• Secondary scenario(s). Documents alternate paths through a use case.
• Exception scenario(s). Documents possible errors and recovery mechanisms.