Are Use Cases a Substitute for Requirements?

This article explores use cases and their relationship to requirements.

• What are use cases and what is their best application on a project?
• What is a requirement?
• Why do people want to substitute use cases for requirements?
• Can use cases be effectively substituted for requirements?

Use cases in software development are becoming very popular. One question I get repeatedly as I teach our seminars on Gathering, Documenting and Testing User Requirements is "Can use cases be substituted for user requirements?"

A Little Background

First, let's look at what use cases are and examine a little about their origin. It's important to get a good definition of terms, so for the term "use case," I went to one of the best sources I could think of, a paper written by Dean Leffingwell of Rational Software. Leffingwell defines a use case in the following terms:

"Technically, a use case describes a sequence of actions, performed by a system, that yields a result of value to the user."¹

In the Unified Modeling Language, one of the models is a use case model, which shows various actors (users) and their relationship with processes described by use cases.

In most books and articles on use cases, the use case focuses on a sequence of actions from a particular actor's perspective. An expanded view of use cases may also include pre-requisites, expected results, exceptional conditions and alternate courses of action.

The great application of use cases is that they provide an effective format to communicate to developers how a user will perform a particular function in the context of the application.

A sample use case is included at the end of this article.

Contrast the idea of a use case with that of a Software Requirements Specification (SRS). A requirement can be defined as:

• a software capability needed by the user to solve a problem that will achieve an objective, or
• a software capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification or other formally imposed documentation. 

I like the way that Dr. Timothy Korson states it, "Good software engineering is NOT use case driven! Requirements are important. Use cases are a good way to structure requirements, but if you care at all about component based development, reuse, robust distributed architectures, cost, schedule, etc., than you cannot afford to let any single viewpoint drive your project."

He goes on to say, "Good software engineering is driven by a number of concerns that are weighted differently by different organizations and different projects within an organization. These concerns include: technical design considerations, user requirements, reuse, modifiability, performance, standardization concerns, schedule pragmatics, and other business drivers.  Each project should be driven by a custom weighted vector of considerations. In each case, however, I think it is accurate to say that a project should be as much driven by domain concept modeling as it is driven by use case development."

The IEEE standard 830 is used to provide a full-featured standard for documenting requirements. The IEEE standard is very complete and has been used in a wide variety of applications. In addition to functionality, a standard may also address interfaces, performance, usability and testability. Use cases do not address these aspects of an application.

Where's the Beef?

My observation is that software developers, and to some degree users as well, have historically tried to avoid documenting requirements. After all, they are difficult to gather and document, plus they tend to change throughout a project.

However, no matter which technology or methodology is in vogue, we always get back to the issue of dealing with the description of the solution so we will know what to build, when the solution has been successfully delivered, and how to test the solution.

Use cases have given hope to people seeking to describe what is to be built without writing requirements. In some ways, people have tried to employ use cases as a middle ground approach that is not as detailed and structured as a requirement, yet more than no documentation at all. However, the traditional use of use cases is to describe a user's process, not the product.

This leads me to ask how far can use cases be extended before they are no longer use cases, but a hybrid requirement? In addition, is a hybrid document necessary? Why not just write a requirement document to describe features and use cases to describe standardization concerns, schedule pragmatics, and other business drivers.

Creative Uses for Use Cases

People have been able to creatively apply use cases for some very natural extended purposes, such as test scripts and test cases, as well as user documentation. Anything that requires the documentation of a process can benefit from use cases as input.

Summary

I don't believe that use cases are effective substitutes for requirements, or are the drivers of software development. Use cases are very helpful for conveying how someone will use an application, and this documentation can extend to helping testers design tests, as well as other purposes beyond building the application.

However, use cases fall short of being an effective vehicle for describing complex business rules, performance requirements and other non-process aspects of an application. As much as people may want to find a way to develop software without documented requirements, I just don't see it happening soon.

There should be a balance of well defined requirements and use cases that provide the usage context for an application.

These two effective documents, plus other models and techniques, such as prototyping, can provide a clear picture of what is to be built and how to test it.

1. Leffingwell, Dean. Features, Use Cases, Requirements, Oh my! 

2. Dorfmann, Merlin, and Richard H. Thayer. Standards, Guidelines, and Examples of System and Software Requirements Engineering. Los Alamitos, CA: IEEE Computer Society Press, 1990.

3. Korson, Timothy. Constructing Useful Use Cases - Page 33 Volume 5, Issue 8 August 2002