The Essential Use Case

CIDM

June 2004


The Essential Use Case


CIDMIconNewsletter Karen Steele, Principal Consultant, Steele/CASE Consulting

The past few years have felt dismal to many professional information developers. Between outsourcing and layoffs, a pall has hung over many, putting the future of our craft in question. Lights, however, do exist at the end of this tunnel. One of the brightest lights is the role of information developers on iterative software development teams that are using a case approach to project definition.

What is a Use Case?

A use case represents a description of system functionality from a particular point of view. Many use cases describe business-related activities, such as Add Item to Inventory. Use cases describe an interaction between a user (dubbed actor) and the system. Cases tell the story of how the actor will complete an activity (interaction) with the system. For example, in an inventory system, the activity might be Add Item to Inventory. In a banking system, it might be Transfer Funds or perhaps Withdraw Funds Using an ATM.

Use cases provide effective ways of understanding and communicating system requirements. According to the definition given by the Rational Unified Process (RUP), a use case is “A set of use-case instances, where each scenario is a sequence of actions a system performs that yields an observable result of value to a particular actor.”

Use cases prove particularly valuable in the development cycle by expressing system functionality and business rules in a way that is easily understood by both the proposed system’s user community and the development team. Additionally, the use case clearly defines the scope of a requirement and describes how that requirement will be met. Testing teams are particularly grateful for the use case as a standard against which to test.

Although some have described use cases as writing the documentation first, before developing the system, it is helpful to have a firm set of requirements and clearly described expectations as the development team begins construction.

For the purpose of this article, we’ll talk in general terms about generic business use cases, although it should be noted that there are many refinements, such as the business use case, the system use case, the essential use case, and so forth.

Perspective from an information developer
A use case can range from the academic to the casual, from a methodical, thorough document before any design begins to the just-in-time support for the Xtreme Programming approach.

For some developers, use cases describe what the system does after the user presses a button. From the perspective of an information developer, system use cases describe the functionality when one system interacts with another system, and business use cases describe a task that the user wants to accomplish when the user interacts with a system. In this case, both the system and the user are referred to as actors.

Many information developers spend as much time talking to users about what they want to accomplish as they do trying to understand the system. Understanding the user’s perspective and describing a user task can be almost second nature. We are, by necessity, process analysts first and communicators second. We must clearly understand both the needs and the solutions before we can effectively communicate with our audience.

Developing use cases—a team approach
A single contributor should never write use cases alone. Use cases are intended to be collaborative efforts among system users, system architects/developers, and all the various stakeholders, such as the customer, system testers, and downstream and upstream systems (either feeding your system or being fed by your system). All of these people and systems should be involved to ensure that their needs are adequately represented in the development and refinement of a use case.

The use-case description should be sufficiently detailed so that all stakeholders understand the system requirements. This level of detail means that the users, customers, system/business analysts, and developers need to agree not only on what the system will do but also on how they will measure whether the system has done the things that it needs to do properly.

Developing use cases—an iterative process
Remember, too, that use cases are meant to be developed iteratively. Developing the initial use case is often referred to as the “Happy Path.” That is to say, the initial use case describes the action as it will take place if everything flows without interruptions.

During the development cycle, you will undoubtedly find the need to develop new business rules and requirements as you explore alternative processing and exception handling. As new business rules and requirements come to light, the use case will be refined to include all current knowledge. The use case should never be “locked” until the system is in production.

Use-case benefits—a business example
The purpose of a business use case is to capture the business processes and requirements that the system under development will support. Use cases must document the business processes sufficiently so that each operation to be supported is identified. Developing a business use case has the following benefits:

  • documents the business process
  • documents the business rules that are driving the action
  • captures the high-level requirements
  • identifies the possible collaborative business areas
  • separates the business processes into functional system areas
  • serves as the requirements documentation for system development, and defines the requirements in a non-implementation/easy-to-read manner
  • serves as the high-level test case against requirements

Use-case levels
Use cases can be written at differing levels of data and scope. Each serves a purpose:

  • Summary—General descriptions and sweeping overviews of system functionality or business processes.
  • Core—Task-related descriptions of users and how they interact with the system; descriptions of a specific business process. Core use cases are usually considered to be at the level of task that is the main work of the user. For example, getting cash out of the ATM machine is a useful task and would be a use case at the core level, but entering your PIN number would not be at this level, because it supports the main work.
  • Supporting—Descriptions of lower-level activities that are used to complete subparts of a core use case.
  • Internal—Descriptions of the behaviors of and interactions among internal system components.

How Is a Use Case Developed?

Use cases are typically developed by using templates that have been adapted to your corporate culture and the needs of your stakeholders. Sample use-case templates are widely available. The wily use-case team will select a template that suits its needs, then further refine it to precisely what is needed.

Use cases can comprise few or many of the various components noted. The key is to develop a template that makes sense for your organization and the systems that you build.

Use-case components
The list of use-case components continues to grow at an alarming rate in the literature surrounding this discipline. The following list gives just a few of the main components and provides a brief description of each:

  • Trigger—the event that kicks off the use case.Example: Customer places an order.
  • Precondition—the state that must exist for the use case to start.Example: The customer is logged on, and the system is engaged.
  • Post condition—a statement that describes the end-state of a successfully completed use case. (When this state exists, you know that the use case is completed.)Example: The item is added to the master inventory, and a message that the task is complete is sent to the user.
  • Flow—the section of a use-case description that describes the full or partial path through the activity of the use case. A use case always has one basic flow and may have one or more alternative flows or subflows.
  • Basic flow—the use-case flow that describes the most likely course of events that the system will take when the use case is performed.Example: Steps for placing an order.
  • Alternative flow—a use-case flow that describes some alternative or exceptional behavior-something that causes the system to deviate from the basic flow of events.Example: When the system rejects an order, this is the path that the system follows.
  • Subflow—a use case flow that describes system behavior when a lower level of task is described.Example: When order delivery will be split between two or more locations, this is the path.

Use-case forms
Flows may be expressed in different ways, including the following ones:

  • Narrative form—free-form text in paragraph format. The narrative form describes both the intent of the user in performing the use case and the high-level actions of the user during the use case.
  • Conversational form—a dialog between the actor and the system that emphasizes interactions and shows cause and effect. The conversational form can show optional and repeated actions. One or more substeps can describe each action.
  • Scenario form—one particular path through a use case, written from the actor’s point of view. The scenario form describes a sequence of events or a list of steps to accomplish. Each step represents a simple statement, and a step may be optional.

Each form possesses its own set of strengths and weaknesses. The narrative form is good for a high-level summary of the action and is generally a good way to start. One of the drawbacks to the narrative form is the temptation to stay at too high a level.

The conversational form is good for seeing how actors and systems interact and for showing parallel or optional activity. This form is easy to write at a too-detailed level (pseudo code) and does not allow for multiple actors.

My favorite form is the scenario form because it captures step-by-step activity, as well as describes the actor and the types of information or tasks that actor would complete in rendering a clear path through the use case. Its major drawback is that it does not accommodate parallelism as easily as the conversational form does.

Best Practice: Explore the various forms and select the one that best fits the needs of the system that your team is building.

Use-case relationships
Many use cases relate to other use cases or call the activity of another use case. Some extend the activity of an existing “parent” use case.

Related use cases can show the big picture of an application by defining which actors participate in which use cases and by visually defining relationships among various use cases. Relationship descriptors like uses, depends, and extends are added when the diagram is a summary of use-case activity for your project.

Unified Modeling Language (UML) defines these relationships among use cases:

  • Dependency—One use case affects the behavior of another use case.Example: Ordering an Item depends on Logging In.
  • Includes—One use case incorporates the behavior of another at a specific point.Example: Adding an Item includes Validating a Vendor.
  • Extends—One use case extends the behavior of another at a specified point.Example: Maintaining an Item and Deleting an Item both extend the Maintaining Item Inventory use case.
  • Generalize—One use case inherits the behavior of another; it can be used interchangeably with its “parent” use case.Example: Checking Inventory and Validating a Vendor generalize the Ordering an Item use case.

Use-case diagrams
The use cases do not always include use-case diagrams, although the diagrams provide an excellent way to help a team visualize the interaction between an actor and the system. When used, summary use case diagrams commonly prove helpful in detailing a high-level picture of users and the use cases in which they participate.

In a complex system, several use-case diagrams can be drawn to show different views of how the system is used. Generally, UML notation graphically represents use cases as ellipses and actors as stick figures (see Figure 1). The line drawn between an actor and a use case indicates that the actor is initiating the use case. Use cases can call upon other use cases, indicated by the includes relationship, or vary the behavior of a use case, indicated by the extends relationship. A dashed line shows the dependency relationship. An open arrow that points to a use case that is being generalized shows generalization (not shown in Figure 1), which is the same as the inheritance relationship between classes.

Use case diagram gray17

You can draw more than one use case diagram, and use cases can be shown on multiple diagrams. Some possibilities include a diagram showing core use cases and their initiating actors, a diagram that emphasizes the interactions and dependencies between two actors, a high-level diagram that identifies summary use cases, a detailed diagram that shows how certain core use cases are fulfilled by including supporting use cases, and a diagram that identifies key variations with use cases that extend other use cases.

When is the Use Case Complete?

The use case is complete when everyone agrees that the description has enough detailed information. The use case is complete when the customer agrees that it describes the user tasks completely, when the developer agrees that there is enough information to code the use case, and when the interface designer has the information needed to develop the interface.

The extent of the description will vary, based on a number of factors:

  • Familiarity of the team with the problem domain. A team that is unfamiliar with the problem domain will require more detailed descriptions as they gain and refine their knowledge of that domain.
  • Complexity of the problem domain. More complex problems will require more detailed solution descriptions.
  • Size of the project team. Larger teams will generally require more detail as the team develops a cohesive vision.

Summary

We all know how challenging it is to build successful software applications. We must clearly understand and specify the requirements that the application must satisfy. Writing use cases has become an increasingly popular approach for identifying and defining requirements for software applications of all types.

While writing use cases is often associated with and used extensively in projects that use object-oriented development approaches, it can be successfully applied in projects of any type, regardless of the underlying implementation technology or development approach.

For the information developer who often must document products on their way out the door, an opportunity to help define the product in terms of its users at the front end can be an exciting and satisfying experience. CIDMIconNewsletter

About the Author

Karen b-w20