Use Cases, Ten Years Later

A use case is a prose description of a system's behavior when interacting with the outside world. I'm guessing that most of you have used or heard of them. Some of you have probably heard heated arguments about how useful (or useless) they really are.

Our understanding of use cases has evolved a great deal over the last decade. The purpose of this article is to show how knowing this evolution informs you about the way people use, abuse, and simply misunderstand them today, and about how to better use them yourself. To illustrate the phases of development, I'll present the article as a discussion in four acts: pre-history (more than ten years ago), the last decade, where we are now, and the near-term future.

Act 1—Pre-History
Ivar Jacobson (pronounced Yah-kob-son) started writing usage scenarios when defining the architecture for Ericsson’s AXE system back in 1967. Those usage scenarios were informal and coarse-grained, meant to give a general idea of the workings of the AXE system. They did not very much resemble the large, formal structures within which people now often write (and which I am guilty of contributing to).

In the mid-1980s, Jacobson spent a great deal of energy reflecting on the ways he had worked over the decades. He coined the Swedish term anvendningsfall, which roughly means "situation of usag" or "usage case." When publishing into English, he decided " use case " did not work in English, and wrote use case. If you don't care for the phrase use case , just be glad you don't have to say " use case " or anvendningsfall each time.

Jacobson's original usage scenarios were intentionally informal. He found out that people did—and still do—resist writing them whenever they become more formal. In fact, when I once asked him about formal models for use cases, Jacobson replied, "Oh, I have a formal model for use cases, all right. The only problem is that no one wants to use it."

Leaving use cases completely informal introduces other difficulties, however. People ask: "What are these 'use case' things, really?" "How do I know if I am doing them right?" "How do I know when I am done?" and "How do I link large numbers of them?"

I ran across Jacobson's original 1987 article in 1992, while creating an object-oriented methodology for the IBM Consulting Group. I recognized, as many people did, that these descriptions of system-wide behavior naturally complement the component-oriented internal descriptions that came out of object-oriented designs. So I, like so many others, started to unravel the riddle, "What is a use case?" I also got trapped in being too formal or too informal, with too few examples to find a comfortable path in the middle. Jacobson kept publishing books and articles about use cases, but somehow the confusion persisted.

Act 2—The Last Decade
Between 1992 and 1997, most people who wrote about use cases avoided saying what one of these things was. They proclaimed how useful they were to projects nonetheless. Even though it seemed no one could say what one was, or name the difference between a use case and a scenario, the basic, attractive idea remained: Write a short, textual description of how a system interacts with its surroundings while performing a function of value to one of its users, and capture how the system should behave when various things go wrong.

That idea was useful then, and still is, no matter how formally or informally the text might be written.

Among the various schools of thought that grew during that time, people suggested and