Use cases, ten years later
From AC
(Published in STQE magazine, Mar/Apr 2002)
From their evolution, learn what to expect and how to better work with them
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 (Jacobson first described them to the public in 1987; my first description of them, "Structuring use cases with goals" appeared in 1995). 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.
Contents |
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 usage" or "usage case." When publishing into English, he decided "usage 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 "usage 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, as 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 is. They proclaimed how useful they are to projects nonetheless. Even though it seemed no one could say what one was, or name the difference between a use case and 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, still is useful, 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 recommended almost all combinations and permutations of answers to the basic questions:
- Is a use case a requirement or just a story?
- Is a scenario just another name for a use case?
- Is a use case a formal, semi-formal, or informal structure?
- Is there a linking structure for use cases, or do they just come in piles?
For some people, a use case was just another name for a scenario, a short description of someone using the system (Martin Fowler often quipped, "I think use case must be the Swedish for scenario"). According to this school of thought, a use case has no internal structure and collections of use cases just sit in piles. People writing use cases in this way obtained good value for the effort they spent, and many of them still recommend writing such informal use cases.
Other people, particularly researchers and CASE (Computer Aided Software Engineering) tool designers, regarded these informal work products as incomplete, needing a mathematical basis and support in a CASE tool. They generated languages, notations, and tools to make use cases "rigorous". This school of thought hasn’t faired so well. People want a fairly informal medium in which to express their early thoughts for a system. They simply won't use the formal tools. They don't feel the extra labor pays off during the life of a project.
Another problem the formalists encounter is handling all the variations a system must handle. One person asked me, "For a candy machine, how do I specify that a person can put in three quarters, or fifteen nickels? Or a quarter followed by ten nickels, or ten nickels followed by a quarter? Or any of the other dozens of ways in which a person can insert coin?"
My reply was, and is, "Just write that the person puts in money."
After getting trapped in both too much and too little formalism at various times, I selected a middle road: semi-formal text sitting in a semi-formal structure. Using these semi-formal structures, we can both
- Assert that use cases really are requirements and need a basic structure, and also
- Allow people to write whatever they want when they need to.
The surprise is that the second target is more important than the first.
Here is the semi-formal structure I arrived at that allows people to deal with the two conflicting targets.
Structuring Use Cases with Goals
It is easy to see that a use case is a textual description of actors' actions. The big question in the early 1990s was, what hangs those particular actions together?
Listening very closely to Ivar Jacobson's explanations and looking at his examples, I found two hints. The first and greatest hint is that a use case describes an actor trying to achieve a goal by using the system. That is, if we designate one of the actors as a primary actor, all the actions are related to that actor achieving some goal of interest to him, her or itself.
Linking use cases to actors' goals is so very significant because it shifts the writer's attention away from the function lists that most programmers worry about and puts it back on the users: What the users really want to accomplish with the software are their goals when using the software. If the software supports those goals, the software will yield the greatest business value.
The second hint is that goals sometimes fail. Whether winning a contract, getting cash from an ATM, putting an ATM card into the card reader or even just moving to the next field while filling out an online form, any goal can fail. Thinking and writing about failure handling within the requirements document saves the design team a lot of money over the course of the project.
Therefore, a use case is structured into two sections: the sequence of actions when everything goes well, followed by various small sequences describing what happens when the various goals and subgoals fail.
Even with those hints, there was one unexpected consequence of working with goal. Goals come in different sizes.
At one moment my goal might be to win a major business contract. A more immediate goal (targeting a smaller time span) is take the client to lunch. A still more immediate goal (with a still smaller time span) is to get some cash for that lunch. This gives me the still more immediate goal to withdraw cash from my ATM. At still the same moment, but with a very narrow focus in time, my goal is to put my ATM card into the ATM card reader so that I can start the transaction.
All of these goals are in play at the same time. Achieving (or failing to achieve) any one of them can be described with a use case. The important insight is to recognize that if we don't mark the use case with the relative size of goal it is capturing, we confuse the reader. The many people writing use cases will work on various, different goal levels. If they name the goal level early in the use case text, it alerts the reader to what the writer was thinking about, and saves a great deal of miscommunication.
With respect to the behavior of an ATM, winning a contract is a very high-level, or "up in the clouds" kind of goal. Getting money from the ATM is a very natural sized goal. Getting the card into the ATM is a very "down in the mud" kind of goal. Each is a very real goal in its own right and may deserve its own use case; marking the level of the goal notifies the use case reader as to what sort of discussion to expect.
When writing a use case, we combine the idea of goal levels with that of goal completion / failure. We write every action step in a use case as a smaller goal that succeeds. We write, "Customer inserts card into ATM," both refering to the lower-level goal of inserting the card, and presupposing its success. Further down in the use case, in an Alternatives or Extensions section, we then write what happens when that action step fails ("Card sticks in slot: ATM machine shuts down and notifies repair company").
Including Stakeholders and Interests
The Actors and Goals model was satisfactory for a long time, but eventually came up short in one particular place. Why do we write things in the use case that are not externally visible behaviors? Why do we record that the bank checks the customer's balance before issuing money, or that it logs the transaction at the end?
The answer we gave for years was, "Well, this is a requirements document—if you don't write those down, then you don't have good requirements." Although that answer worked, it wasn’t very satisfactory.
At some point I noticed that the computer's actions enforce a contract between stakeholders, and that every action it takes is either to protect one of the stakeholder's interests, or to further one of the stakeholder's interests.
The primary actor is only one of the stakeholders. The organization that owns the system is another, a government regulatory agency might be another, and there might be others as well.
Here is a simple example. Jim walks to the candy machine. He actually doesn't want to spend money; he really wants a candy. He'd be happier if the candies were free. The owner of the machine has the opposite view: She actually doesn't want to give out candy. She'd be happier if people would just put money in the machine. The candy machine enforces a simple contract: Jim puts in the money; the machine's owner sees that he gets a candy.
The equivalent contract is more complex in the insurance business. A policy owner has an accident; a beneficiary enters a claim; the insurance company pays out the smallest correct settlement; and the Department of Insurance checks that the transaction operated within federal guidelines. The computer system ensures that all of the stakeholders’ interests are satisfied. The use case writing describes how this is to be done.
The Stakeholders and Interests model fills the holes in the Actors and Goals model. Every action the computer takes is tied to a stakeholder's interest. The system will accept information, validate values against business rules, update internal state, or pass out data. Primary and supporting actors are accounted for, as well as all those stakeholders who aren't present during the system operation.
One consultant described the first time he and his group listed the stakeholders and their interests for a system they had recently shipped. They suddenly found themselves looking at most of the change requests that had been generated in the first year of operation! In other words, had they simply written down the stakeholders and interests for each use case early on, they would have avoided an entire category of mistakes that didn’t show up until after they had delivered their system. Other people have reported similar experiences. Several people say they find value in listing the stakeholders and interests however casually and informally their capture requirements.
At this point (1997), it looked as though we had closed the holes in use case theory.
The Reaction Against Use Cases
As the above model became accepted, people naturally rebelled against it. It was still not formal enough for the formalists, who continued to look for a fully formal model. At the same time, it was too formal and called for too much writing to suit those who liked to think of use cases as informal, unstructured, non-requirements descriptions. This latter group responded by moving in three directions—feature lists, story cards, and task cases.
A single use case can cross the programming boundaries of several people, and so the individual programmers' work assignments aren't explicitly visible. Some programmers therefore requested "feature lists" that could be assigned to individuals. Even though extracting and maintaining these lists take a lot of work and double the maintenance burden on the team, they are still often requested.
The authors of Extreme Programming (XP) stayed with the idea of informal scenarios not having any formal structure at all. Kent Beck created the term user story to describe these sorts of requirements. A user story consists of just a phrase or a few sentences written on an index card, announcing something the user wants to do. In XP, the user story is not used as a requirements specification, but as a marker for a future conversation. Therefore, the card only needs to record enough information so the programmers and customer know what to discuss later.
Larry Constantine pursued the writing of scenario descriptions to help in user interface (UI) design. He found he didn't need to record the system's internal processing steps or its interaction with supporting actors. He could get away with a very simple two-column structure. The left column listed what the user was trying to accomplish at each step. The right column listed the system's responsibility. This two-column table provides enough information to let people invent a good UI design. He renamed it a task case, to avoid confusion with system specification use cases.
Still, there remained a split between those who still wanted to keep use cases short and informal and those who wanted them to be detailed, having outline templates and automatically updated links to other system documents. Among these various groups of use case writers, there is little in the way of commonality…aside from the desire to capture system behavior with something called use cases.
Act 3 - Now
This gets us to the present, facing Jacobson's statement about having a formal model that people don't want to follow. Here are four key pieces of advice that you should note from the evolution of use cases.
Prepare for Multiple Formats
There cannot be just one template for a use case. Some teams will do just fine with a short use case style, in which the main story is presented in a simple paragraph of prose, and the failure handling is in a few following paragraphs. Other teams will need detailed templates and careful writing conventions.
In Writing Effective Use Cases, I name three degrees of detail in writing use cases: brief, casual, and fully dressed.
The use case brief consists of two to four sentences summarizing the use case. It fits well in a spreadsheet cell, and allows the other columns in the spreadsheet to record business priority, technical complexity, release number, and other planning information.
The casual use case consists of a few paragraphs of text, covering the items mentioned above.
The fully dressed use case features the long template with fields for stakeholders, minimum guarantees, postconditions, business rules, performance constraints, and so on.
The three formats are not likely to converge, due to two forces in our industry. The first is that multiple project situations and personality types will always produce various multiple degrees of formality in use case writing. The second is that ambitious people make their name by creating something new. As soon as a topic stabilizes, someone will look for an alternative that can claim its place in the pantheon of ideas.
The point is that multiple requirements forms will always be present, and multiple levels of formality will always be needed.
Only Use Them When the Form is Appropriate
A use case form is really just a stylized way of writing, a form of prose having two sections. The first section describes a basic scenario containing actions and interactions. The second section presents a set of scenario fragments, describing how the behavior differs under varying circumstances. This form of writing can be used any time to describe behavior with alternatives, such as black-box requirements, business process, and system design descriptions.
As system black-box requirements, the use case describes: the user does this; the system does that; the system talks to another system; something goes wrong; the system now does this instead; and so on. It says very well what the system must accomplish, without saying how the system is to do it, and it does not in any way presuppose the use of object-oriented (or any other style of) design.
As business process descriptions, the use case describes: the customer does this; the clerk does that; the clerk hands something to another department; the other department does something else; and so on. When things go wrong, some department rejects a piece of work; it goes to a different department; and so on. These sorts of descriptions are relatively easy for business people to write and very easy for untrained people to read, and so they have a growing use in business process reengineering work.
As design documentation, the use case describes: the user does this; some first component does a set of things; the component forwards a request to a second component; and so on. Under various conditions, the sequencing between components is different, et cetera. Use cases are only rarely used for design documentation, because there are so many other ways to document a design.
The thing to keep in mind is that the use case form, namely, a scenario of behavior followed by scenarios of alternate behavior, fits a certain set of writing needs. Reach for use cases when that form is appropriate, and drop them as soon as the writing needs don't fit that profile.
Be Aware of Use Case Limits
Use cases don't take care of system design, UI design, feature lists, or testing, even though many people wish they would. They’re not supposed to, of course. They are supposed to describe behavioral requirements, but that doesn't stop people from looking for ways to "automagically" derive designs from use cases. These people are alternately sad and glad that use cases don't specify design. They’re sad, because they wish for a magic formula to simplify software development. They’re glad because they recognize the need for black-box specifications.
Use cases should not be used to describe UI designs for several reasons, even though the use case form permits it. There are two reasons they are not often used that way. First, a use case is normally intended as a requirements document, and the UI design is a design created by trained people after being told what the system should do. Secondly, UI design is brittle, changing often. Writing the UI design within use cases means the document will have to be updated frequently, much more often than a requirements document ought to be, and much more often than any project team (that I’ve met) can manage to do. Other forms of description, statecharts, Constantine's task cases, and screen shots do a better job when working with the user interface.
Use cases have a basic mismatch with feature lists. The same system feature is likely to show up as a line item in multiple use cases. As a consequence, someone has to convert the use case text into programming assignments. For many people including myself, this does not present a problem. They simply do the conversion in their heads, in conversations, or by annotating the use cases. Working this way avoids the double maintenance problem. Anyone who requires both use cases and feature lists is asking for double work.
Use cases are not test plans or test cases. They are missing the data values needed for test cases. However, use cases are a great input into the testing process, since they say what is supposed to happen under various conditions. Testers must still create actual test cases to match the use cases.
Avoid the Standard Mistakes in Use Cases
There are many kinds of mistakes a use case writer can make. The two most common and most costly to the project are including too many details and including UI specifics. Both make the use cases long, hard to read, and brittle.
No matter how often teachers warn against including UI specifics in the requirements document, new writers feel compelled to describe "OK" buttons, specific fields, screens, and screen sequences. The defense for doing so is that users like to work with concrete concepts. Although this is true, the use case is the wrong place to do it. It requires effort to learn how to write in a technologically neutral way. For example, "System presents the options. User selects an activity." The result is well worth it, though, since the resulting use cases are shorter, easier to read, and more robust.
Many people seem to feel guilty if the main scenario of a use case is short, so they stretch it to fifteen or even thirty-five lines long. Personally, I’ve yet to write a main success scenario longer than nine steps. It's not that nine is a magic number; it’s just that by the time I get subgoals at a good level and remove the design specifics, the task is less than nine steps. Use cases can sometimes be as short as only three steps in the main scenario.
The greatest value of the use case does not lie in the main scenario, but in alternative behaviors. The main scenario may occupy a quarter to one-tenth of the total length of the use case, because there are so many alternatives to handle. If the main scenario is thirty-five steps long, the use case will stretch to ten pages, which is much too long to read and understand. If the main scenario is between three and nine steps long, the total use case might only be two or three pages long, which is long enough.
If you can avoid including too many details and UI specifics in your use cases, then your use cases will be much easier to read, and readable use cases might actually get read. Long and unreadable use cases just get signed off—usually with nasty consequences to the project months later.
Act 4 - The Near Future
Use cases have reached a still point, which means two things:
- There is a sound model for them, which is being taught and used.
- Splinter evolution has started.
From this we can predicts a few things for the near future.
- As a mainstream technique, they will be taught in undergraduate curricula, and in standard software development and methodology classes around the world.
- Tool manufacturers and theoreticians will continue the search for formalisms that might underlie use cases.
- Tool manufacturers will produce tools that better match the theory, and make cross-linked use cases easier to write, maintain, and integrate into the CASE tool suites.
- People will look for alternatives to this now-mainstream technique, and will suggest ways to develop software without them.
- Some things will stay the same: People will continue to write too many UI details in their use cases, regardless of their tools and templates; organizations will continue to use them to avoid having people talk to each other in person.
- People will misuse them, teach them incorrectly, warp the interpretation, and blame the resulting mess on the use case form.
What you can do to ensure the usefulness of the use case is to learn:
- How to keep design specifics out of the use case;
- When to use the different levels of formality in use case writing; and
- When to reach for another form of expression, through something as simple as the two-column table.
Then, sit back and watch the arguments fly.
About the author
Alistair Cockburn (pronounced Co-burn) is the author of Writing Effective Use Cases, one of the founders of the Agile Software Development movement, and author of Agile Software Development. He posts material supporting his work at http://Alistair.Cockburn.us.
Web Sites
www.UseCases.org
www.pols.co.uk/UseCaseZone
www.ForUse.com
midwatch.org/design/ucindex.html
Books
Armour, F., Miller, G., Advanced Use Case Modeling: Software Systems, Addison Wesley, 2000.
Cockburn, A., Writing Effective Use Cases, Addison-Wesley, Boston, MA, 2000.
Constantine, L., Lockwood, L., Design for Use, Addison Wesley, 1999.
Jacobson, I., The Object Advantage : Business Process Reengineering With Object Technology, Addison Wesley, 1995.
Kulak, D., Guiney, E., Use Cases: Requirements in Context, Addison Wesley, 2000.
Articles
Jacobson, I., "Object oriented development in an industrial environment," OOPSLA '87: Object-Oriented Programming Systems, Languages and Applications. ACM SIGPLAN, pp. 183-191.
Cockburn, A., "Structuring use cases with goals", Humans and Technology technical report 1995, also appearing in Journal of Object-Oriented Programming, Sep-Oct 1997 and Nov-Dec 1997.
