Use cases

Abstract

We all know how difficult it is to achieve project success without complete product requirements. Yet gathering complete requirements without exhausting the project schedule and budget remains elusive for many project managers. When new technology is added to the mix, the challenges are even greater. This paper addresses the complexities of gathering ambiguous requirements, showing how use cases can help solve this problem. It also answers questions frequently asked by project managers about one requirements-gathering technique called use cases.

Introduction

Project managers and business analysts have traditionally struggled not only with how to define unambiguous requirements, but also with how to keep requirements from changing after those initial requirements have been defined. One way to alleviate this problem is to provide a structure that facilitates the requirements discussions between customers and technical staff and results in work products that are useful not only to designers and developers, but also to the business customers. Use cases provide this structure and accommodate changes as more is known throughout the project life cycle.

As useful as this structure is, it is surrounded by mystique and misconceptions. This paper describes a practical approach to use cases and provides hints on how project managers can incorporate them to improve technical and business communications, help manage the project scope, and corral the business requirements process.

This paper addresses these issues by answering these ten frequently asked questions about use cases:

1. What is a use case?
2. Why should project managers care about use cases?
3. What are the key components of use cases?
4. What is the difference between a use case model and a use case diagram?
5. Is the use case the most effective process modeling tool?
6. How do I find use cases?
7. I've heard a lot about UML (Unified Modeling Language) and the Unified Process. How do they relate to use cases?
8. How will use cases help me manage my projects?
9. If we create use cases, do we still need to complete a requirements list?
10. Do use cases capture all requirements?

What is a use case?

There are many textbook definitions of the term ‘use case.’ Many of these definitions are theoretical, and describe the use case in terms that are hard for the business to understand. For example, Geri Schneider defines a use case as “behavior of the system that produces a measurable result of value to an actor” (Schneider, G., 2001, p. 14). Frank Armour describes a use case as “a sequence of actions required of the system…a functional stripe through the system and is shown as a horizontal ellipse…” (Armour et. al,. 2000, p. 3). Ivar Jacobson defines a use case as “description of a set of sequences of actions and variants that a system performs that yield an observable result of value to an actor.” (Jacobson, et. al., 1999, p.41).Martin Fowler defines a use case as “a set of scenarios tied together by a common business goal” (Fowler, M., 2000).

Simply put, a use case is a description of all the ways an end-user wants to “use” a system. These “uses” are like requests of the system, and use cases describe what that system does in response to such requests. In other words, use cases describe the conversation between a system and its user(s), known as actors. Although the system is usually automated (such as an Order system), use cases also apply to equipment, devices, or business processes.

Let's use the example of a microwave. There are many ways we, the actors or end-users, want to make use of the microwave, including heating up leftovers, boiling water for tea, defrosting frozen food, cooking a meal. Each one of these is a ‘use’ of the microwave and can be described in a use case. If we want to boil water for tea, we tell the microwave what we want done (our request to boil water). The microwave boils the water and notifies us when it's done.

Let's take another example, that of an automated order system. Some of the uses of that system may be to choose an item, or check the availability of the item. Other uses include creating orders, copying or moving them, and deleting them. Use cases would describe each of these system functions.

… And why should project managers care?

Use cases provide a structure for gathering customer requirements and setting the project scope. They are also extremely useful for having the end users ‘test’ the system as it's being designed, which leads to quicker development and a more useable system. While use case modeling does not provide a complete solution to gathering requirements, it does facilitate the development of user interfaces (screens), screen edits and messages, and acceptance test scenarios. Business analysts have traditionally struggled not only with how to translate what the end user wanted the system to do into a technical design, but also with how to have that same end user verify that the translation was correct well before the system was built. The pseudo code typically written by software developers was too technical to be verified by most end users. Use cases help solve this dilemma by providing a translation that end users can understand and change before too much time has been invested in the project. Bottom line-- more can get done with less. In addition, use cases help:

• Business clients articulate their needs.
• Business and IT communicate with each other.
• Requirements-based testing and user acceptance test scenarios.
• Structured handling of exceptions.
• Definition of edits and messages.
• More complete and quicker requirements definition.

What are the key components of use cases?

The key components of use cases are the system, actors, and use cases. Closely associated with the above are interfaces, which facilitate the conversation between the actor and the system. We'll look at each of these components separately.

The system. Schneider describes the system as “everything you plan to create” (Schneider & Winters, p. 11). The system is the boundary of the application. For example, the boundaries of a project to develop a new Order system would include the entire application and its system interfaces, and therefore would be considerably broader than if the project were a small enhancement. The system boundary helps set the project scope, as we'll discuss later in the paper.

We have found it most helpful to focus on the system, not the actor. By understanding the system, we can better scope our project, consider project risks, and gather our requirements. Identifying the correct actors is a key criterion for success, but determining the system scope is a foundation for project management, and also helpful in determining the actors.

Actors. Actors are external entities that interact directly with the system. Using our Order system example, when customer service representatives enter the item number into the system, they are actors. When customers enter items on a website, they are actors. If a customer orders by phone and a customer service representative alone enters that order, the customer is not an actor.

Actors can be people, other systems, or time. When the Order system goes to an Inventory system to determine whether or not an item is in stock, the Inventory system is another actor. If month-end processing triggers the Order system to create reports, for example, then time is an actor. Time actors are called temporal actors.

•    People (Roles) Actors

  When people are being considered as actors, it is important to understand that the people are playing roles (such as customer, maintenance worker, troubleshooting technician, installer, and manager), and they should be documented and described by those role names, not their titles. Sometimes people play more than one role, such as the following:

  • ✓ Customer and employee
  • ✓ Technician and manager
  • ✓ Customer, account representative, and salesperson

  It is important to think of actors as role players, or actors in a play, rather than individual persons or job titles. Defining the actors by what interactions they wish to perform with the system will help define and differentiate the actors.

•    System Actors

  Systems can be any automated device with which the system will interface. This includes other computers and interface devices (if they are out of scope of the system being developed). For example, if the system is a Distribution Center system which reads data from scanned cartons, the devices used to scan the cartons would likely be included as actors. However, if the ‘system’ were the scanning devices themselves, then the larger Distribution Center system would be an actor.

  Other Systems can be any automated device with which the system will interface.

  Additional examples

  • ✓ Other computers
  • ✓ Interface devices (if they are out of scope for the system being developed)
  • ✓ Anything other then people or time
•    Time Actors

  Time actors are time-based initiators or triggers of processing activity for the system. Common timers are weekly, daily, and monthly.

  Additional examples:

  • ✓ 5:00 PM every Friday a weekly status report gets created
  • ✓ 12:00 noon every last Tuesday of the month a corporate balance sheet gets created
  • ✓ Every hour on the hour a time check is performed with the corporate timer system to ensure that the system clock is accurate

Use cases: are the processes that occur within the system. Like other processes, they have a process scope. That is, they begin and end. They also transform input into output. Use cases are named with an active verb and a noun, such as Fulfill Order or Return Item. Additional examples:

• Process Withdrawals.
• Balance Accounting & Sales Ledgers.
• Back Up Departmental Case Logs.

These are considered processes that accomplish a task for the actor. Use cases should provide value to the actor. The goal is to discover all the possible use cases for all the actors previously defined, which helps define the scope of the system.

Interfaces. The interface allows the conversation between actor and system to take place. While not technically part of the use case, they are related. Thinking about the interfaces helps uncover additional use cases and vice versa. Thinking about the use case often drives the design of the interface.

Let's use the example of a car. One of the ways we might want to use our car is to have it stop when we want. The use case would describe the ‘conversation’ with the car when we wanted it to stop. That conversation is facilitated through an interface, in this case a brake, which allows us to make our request of the car and for the car to respond to the request to stop. We need to talk our car's language; we cannot simply shout ‘STOP!’ We need to use an interface (the brake) to state the request. Hopefully the car responds by slowing down and coming to a halt. Screens, also known as user interfaces, help end-users communicate with automated systems.

What is the difference between a use case model and a use case diagram?

A use case model consists of a use case diagram and narrative text detailing the use cases. The diagram is a picture of the system, actors, and use cases. It contains the system boundary, called a boundary box, the actors, and the use cases. Most diagrams are drawn using Unified Modeling Language (UML), see Exhibit 1.

Exhibit 1: Example of a Use Case Diagram

The narrative text describing the use case is called a flow of events. UML does not address this textual description. Key components of the flow of event include:

• Pre-and post conditions, which set the scope of the use case. A pre-condition states the beginning state, or what has to happen before the use case can begin. The post-condition states the ending state, or what has occurred as a result of the use case. As with any process, the boundaries of where it begins and ends are usually unclear. For example, where does Fulfill Order end? How do we know we're done fulfilling an order? Is it when the item ships? Is it picked in a distribution Center? Is it created in the system? Process users typically have varying assumptions and understanding about process boundaries. Pre- and postconditions set these boundaries.
• Primary process steps. Sometimes called the primary path, normal course of events, main flow, happy path, sunny day path, or routine process, this is the lists the steps that occur most of the time. It's the routine processing.
• Alternate steps. Sometimes called the alternate path or sub-flow, these are steps that can lead to the completion of the process, but are less common than the primary process steps. Another term used to describe alternate steps is scenario. For example, a main flow might be for a customer service rep to enter a customer order through an internal system, while an alternate flow would be a web order.
• Exception steps. Sometimes called the secondary flow of events or exception flow, these are the conditions that could occur to prevent the system from getting to its post-condition(s). Using our order system example, if the credit is denied, the system cannot process the ordfer.

Is the use case the most effective process modeling tool?

While the ‘system’ can be defined as a business process, we don't think it's practical to do so. We have found that other process models, such as process maps, swim lanes, and activity diagrams are more effective. Use cases that model business processes can become text procedures. However, a graphical picture of the business process helps spot anomalies with the current process and more easily leads to ways to improve it. Textual procedures do not lend themselves as well to this type of analysis.

How do I find use cases?

We encourage documenting business processes using one of the business process models noted above and look for the touch points with current or future automated systems. Those touch points are candidate use cases. Let's use the Order system again as an example. Let's say that in the current process the customer service representative enters requested item information into the system. The point where that entry occurs is a candidate use case. The use case would describe what the order taker expects the system to do and what the system does to process the order.

I've heard a lot about UML (Unified Modeling Language) and the Unified Process. How do they relate to use cases?

UML. Introduced in 1997 (Ambler, S., 2003), UML provides notation guidelines for developing diagrams usually associated with object technology. Its main benefit is to help team members better communicate with each other. When diagrams follow the same conventions, business analysts, designers, developers, and testers can all interpret requirements in the same way, decreasing the risk that the requirements as stated by the business expert will be misinterpreted. As noted earlier, there are UML guidelines for use case diagrams, but not for the narrative text. It is not necessary to use UML when creating a use case diagram, but it is helpful.

Unified Process. This set of processes provides a framework for developing systems in general and objects in particular. It provides a development life cycle with standardized project phases, which include Inception, Elaboration, Construction, and Transition (see Jacobson et. al.). However, it is not necessary to use the unified process when creating use cases and all development life cycles can incorporate use cases.

How will use cases help me manage my projects?

Scope. The use case diagram is a particularly effective tool to help identify and manage project scope. Although only one of the many aspects of project management, scope management is often considered the most difficult. The use case diagram helps identify scope in these ways:

• Sets the boundary for the project. The boundary box indicates the scope of the system. Everything within the box is included in the system; anything outside of the box is excluded. This diagram is a wonderful graphical representation of system scope.
• Shows the processes under consideration. Each use case is a process that delivers value to the end user. Each has a business objective or goal that is going to be accomplished.
• The flow of events confirms the scope. It provides the detail involved with each use case process and describes how big each process is.
• All the use cases need to link to the business and project vision and objectives. Any use case that does not provide this alignment, can be easily seen and removed.
• Showing system actors helps provide a picture of the interfaces that need to be modified. This picture aids in showing not only what's contained in the application, but also how many system interfaces need to be included in the project. It provides an effective communications tool and visual that may be helpful in explaining and estimating the effort that may be transparent to business customers.

The use case diagram helps control scope in these ways:

• Once use cases have been confirmed, new use cases that arise can be better managed. Changes can be matched to the vision and original diagram to see whether or not they belong. New requests can be translated into new use cases and placed in the diagram.
• If new actors surface, it is an indication that more work is required. Again, the visual serves as a way to communicate with business experts about the impact of their requests on the project.
• If new use cases cause any linkage to change, additional work will be needed as well.

HR management. The use case diagram also aids in identifying actors who, for human actors, are stakeholders in the project. The process of connecting actors to use cases on the diagram can be another tool to uncover hidden stakeholders and to better the communications among stakeholders, who may question their need to participate on the project.

Risk management. It is helpful to examine risks and deal with the highest risk project factors first. In the beginning of the project, use cases as denoted in the use case diagram can help the project team identify and analyze such risk factors as the use of new technology, third-party software and the associated vendor risks, and multiple actors (the more actors, the greater the risk, whether those actors represent stakeholders or system interfaces). As the project progresses, use cases can be used to help identify risks that have surfaced since the inception of the project.

If we create use cases do we still need to complete a requirements list?

Many of our customers have proprietary use case templates which include the associated business rule or requirement. They face the issue of whether or not to create a separate requirements list. Some have chosen to be aligned with IEEE,(Institute of Electrical and Electronics Engineers, who publish requirements and testing templates and standards), which does include a separate list in the requirements specification. Others have put the requirements/rules right into or at the end of the use case narrative description and not used a separate requirements list. Still others have done a combination of both.

We encourage a separate requirements list for traceability. The requirements list becomes the foundation for the traceability matrix, which is the premier tool for ensuring that every requirement is fulfilling a business need, and that approved requirements are actually delivered at the end of the project.

Do use cases capture all requirements?

Use cases can be manipulated to capture all requirements, but there are some types of requirements that lend themselves better to other models. One of the most commonly asked questions is why use other models in requirements definition. Here's our response:

• Use case models show processes, so if the project is primarily one that manipulates data (such as a data warehouse or reporting application), then other tools are more effective.
• Business Process maps. In addition to the benefits of process maps stated earlier, they also provide user interface (screen) navigation, which ideally follows the business processes (hopefully improved or reengineered). These maps can also drive out hidden business rules, e.g., we cannot delete an item when the on-order quantity is greater than zero.
• Data models provide the information required by stakeholders. It also helps show what appears on each screen, for both data entry screens, as well as reports. They also provide many of the business rules, e.g., whether or not customers are required to have accounts.
• Prototyping, which is derived from the data, process, and use case models, allows for early feedback and helps drive out additional requirements during requirements analysis. These prototypes do not need to be completely designed or even built with automation. Some of the most effective prototypes are done on paper, using stickies to drive out the alternate and exceptions paths as described in the use cases.

It's no wonder, then, that one of the most common complaints we hear from project managers and business analysts is that they have done a thorough job of use case modeling and yet requirements still surface throughout and after the project!

One proven approach for quick and complete requirements-gathering is what we call “concurrent business modeling.” TM This approach is different from concurrent component engineering, or concurrency, commonly used in developing objects and e-solutions. Concurrent business modeling focuses on obtaining business requirements, not on building software. It suggests that by modeling business data, business processes, system processes through use case modeling, and prototyping, requirements will quickly surface. In addition, each type of modeling effort supports and enhances the other modeling efforts and encourages analysts to ask their customers the kinds of pertinent questions that drive out hidden requirements.

In sum,
At first, developing use cases feels a little awkward and unnatural. It's difficult for people to think like ‘the system.” Nevertheless, most analysts and project managers see an immediate benefit in developing use cases and after one or two efforts, the awkwardness disappears. Then, a strange thing starts to happen. clients, analysts, project managers, and technical staff start talking the same language, emphasizing the importance of unambiguous requirements, and projects are completed more quickly and with less cost.

For a copy of any of the documents mentioned in this article, send an email to the authors. They can be reached at [email protected] or [email protected].