Use cases are becoming more mainstream as a method for capturing requirements, as evidenced by the endorsement of big companies and methodologists such as Booch, Rumbaugh, and Coad. One benefit of use cases is that each one encapsulates a set of requirements. This encapsulation lets you easily manage and track the use cases individually and provides a better alternative to prose requirements.

There is more to effectively using use cases than just capturing them and putting them into diagrams. As you implement use cases, you need to validate them, determine their size, and establish a plan for implementation. Then, you need to incorporate the use cases into your system design and turn them into code and documentation. Throughout this process, you must also be aware of the status of each use case. This article will discuss ways to do all these things.

Validating Requirements with Use Cases

Once you've captured a use case, you need to confirm whether it accurately describes the system and is truly needed by the system's users. Sometimes, in the course of development, you realize some of the requirements you've created are unnecessary or peripheral to the main purpose of the system. You must identify these as soon as possible, so you can work on the functionality that is the most valuable to the customer. But how do you determine which use cases are most important to your users? You use a method called Quality Function Deployment (QFD).

QFD helps you weigh use cases to determine which ones are important and which are discardable. To use QFD, users representing each group in the actor catalog are given a list of the abstract use cases and $100 in virtual cash to spend on the ones they think are the most important. The amounts are then tallied to determine which features are the most desired.

Table 1 shows the QFD of use cases for a remote banking program. Each actor type has an individual perception of what functions are important for the banking program. To get the best picture of what's important to the largest group of users, you weight the user types. For example, for the banking program in Table 1, home users are the largest group, so their QFD scores are doubled.

When using QFD, it's important to keep one caveat in mind: make sure you include on the list all the obvious features the users will expect in the system, because it's very likely these features will not come up while you're gathering use cases. For example, in the banking program, users would obviously require a "transfer funds" use case. However, because they expect this feature to exist, they might not consider it important and not allocate funds for it. It's important to allow for this and include the basic functions of the system into the QFD.

Sizing

Because use cases describe functionality from the user's point of view, they can be directly converted to function points. Assigning function points to use cases helps us understand how large a use case is and the associated effort needed to produce it.

We can use this knowledge in iterative development to divide the iterations into roughly equal sizes and determine earned value. Some companies use earned value to recognize revenue. You can do this by dividing the estimated cost of a program by the number of function points, which yields a cost per function point. Each use case then becomes part of the executable. Multiply the number of function points associated with each use case by the cost per function point. The result is the amount of revenue recognized. You can use this same technique for project tracking by using the number of function points delivered to determine the progress on the project.

Iterative Development

Determining the implementation order of requirements involves several conflicting factors: the needs of the customer, the needs of the development team, and the needs of management. The customers would like to see the parts of the program they want implemented first. The development team needs to work on the most complex parts of the program first, so it can move from high complexity to low complexity. Management would like to work on the parts with the highest risk, so they can move from high risk to low risk.

So, how do you balance all three concerns? The customer's needs are known through QFD. If you deliver the iterations based on the QFD scores, you ensure customer satisfaction. But to also satisfy the needs of the development team and management, it's best to rank each use case for complexity and risk as well. Here's one way to do this: Rank complexity on a scale from one to five, with one being very simple, four being very complex, and five unknown. Rank risk similarly, with one being marginal, four being high risk, and five unknown. Once you've rated all the use cases, multiply complexity, risk, and the QFD percentage to get a weighted value that takes into account customer satisfaction, complexity, and risk.

Table 2 shows that although the customer would like to see "get detailed charges" first, it makes more sense to work on "purchasing securities" first. There are two caveats to using this technique. First, some use cases are dependent on the existence of others. You may need to work on a lower-rated use case first to implement the targeted one. Second, as mentioned previously, some essential requirements, such as "transfer funds," may not be ranked high.

Design

Use cases can help you create your system design and also serve as the foundation of design reviews. Use cases can be readily converted to object, interaction, and event diagrams and used as a basis for CRC cards. In a design review, use cases force designers to show how each use case is enabled by the design and which things in the design are not part of any use case. This ensures all requirements are implemented and no unnecessary work is done.

Testing and Documentation

Use cases are the backbone of testing and documentation. If the use cases are clearly stated and testable, they form the basic system test plan. They are also well suited for acceptance testing, in which users test all use cases on the system and approve the system's performance of each one. Because use cases represent the user's perspective, they can form the initial user manual, online documentation, or help file. Some divisions of Microsoft use a similar technique; they write the user manual first and it becomes the specification for the program.

Use Case Tracking

To make sure you deliver what the customer has asked for, you need to know the status of each use case. Knowing where each use case is within the software life cycle is valuable for managing the project and determining status. You can accomplish this goal by assigning each use case a Work Breakdown Structure (WBS) in the project plan. Then, as you track the project, you also track each use case. This also yields a method for determining WBS's.

As your project progresses, you need to manage and control your use cases. A repository makes this possible. At my company, we keep the data in a groupware database product such as Lotus Notes and include the following information on each use case:

• A short descriptive name of the use case in the form of an action verb and noun, such as "export to spreadsheet"
• A detailed description of the action the use case performs
• The preconditions: other activities that must take place before this use case executes
• The post conditions: the actions that will happen to the use case after it executes
• The exceptions: what happens if the use case fails
• The pattern name from Coad, Gamma, and so on
• The Work Breakdown Structure (WBS)
• The number of function points required
• The location of the design files for the use case
• The location of code files for the use case
• The modifications made to the system, the date the modifications were made, and the name of the person who made them.

Use cases are a valuable tool for capturing and managing requirements. You can use them in all facets of the software development life cycle. As you move throughout the different phases of your next project, think of how use cases could be involved and how you would manage them. If you manage and track use cases well, you'll be able to use them to their fullest.

Sidebar: Pointers

The sophisticated approach to requirements and use-cases described in this article integrates a number of important software development techniques. For more background on these topics, consult the following articles from Software Development magazine:

Mainstream Use of Use Cases:
"The Mouse That Roared," by Roland Racko, Object Lessons, March 1995

Converting Use Cases to Function Points:
"Function Point Counting," by Dave Garmus, September 1993
"Function Point Counting Rules for GUIs," by David Longstreet, February 1996

Using Function Points with CRC Cards:
"CRC Cards for Analysis," by Nancy Wilkinson, October 1995

Use Cases as the Basis for a Basic System Test Plan:
"From Use Case to Database," by Larry O'Brien, February 1996

Keeping Requirements Data in Groupware Database Products:
"From Use Case to Database," by Larry O'Brien, February 1996

Microsoft and Use Cases:
"And Now, the Microsoft Process," by Warren Keuffel, Tools of the Trade, August 1995

Software Development Patterns:
"The Timeless Way of Building Software," by George Shepherd, May 1995