InformIT

Becoming a Software Developer Part 4: Understanding Use Cases and Requirements

By

Date: May 1, 2002

Article is provided courtesy of Addison Wesley.

Return to the article

Where do requirements come from? How can use cases help to record requirements? What does a good use case look like? What do I do with a use case once I have it?

Introduction

One very intriguing aspect of software development is that whenever someone gets an idea for a new application, we nearly always think that it will be easy to implement. Only after getting a closer look at what the idea really involves do we begin to get a clue about the true complexity of the new application. No matter how much experience a developer has, the first guess as to how long the application will take to create is going to be completely wrong.

To give a sense of this, let's consider a simple application, say a membership system for a running club. Nothing too complicated, you understand—just a means of recording the members' names and addresses, tracking when their membership fees are due, and sending email to notify members about upcoming events and races. It would also be nice if there was a way of recording race results so that the club could publish lists of age-ranked results in the newsletter.

How hard could it be to produce a little application like that? It sounds quite trivial, doesn't it? Take a guess now, and after you've finished reading this article see whether you would revise your original estimate.

Understanding the Requirements

Requirements are very slippery things. Software developers often speak about "The Requirements" as if they're cast in concrete, never to be changed or questioned in any way. The reality, however, is that requirements come from people, and you can bet that whoever dreamed them up in the first place is just as capable of making a mistake or forgetting things as you are.

So the first thing you want to do whenever you hear about an idea for a new application is "explore the requirements space" and attempt to understand the vision for the application.

Exploring the Requirements Space

What this fancy-sounding phrase really means is that you need to meet with the person with the idea and have a conversation about what he or she is really trying to achieve. You need to get an idea of the motivation(s) underlying the request for the application. You also need a sense of how the application is intended to be used, and any ideas that people have for ways in which the application could be used.

Understanding the Vision

To do a really good job developing the application, you have to understand the vision for the application. This means that you have to work with the people who want the application, to jointly envision how the application will be and could be used.

For our little club membership system, let's make it easy and assume that what is wanted is an application for the club's membership secretary, that it would be used to send out reminders when membership fees become due, and that every so often someone would go to the trouble of manually entering the race results. Someone also dreamed up the cool idea of having the application pull down race results from the web and automatically update the members' results, but nobody was sure whether that would be really useful.

Defining the Project Scope

The next step to take is to define what the project is supposed to deliver. Yes, you understand the vision for the application, but what exactly does it mean in detail? How much complexity is still hiding under the covers? How many different users will there be, and exactly what do they expect to be able to do with the application?

To answer these questions, you have to do some more work with the people who want the application, precisely naming which user goals the application needs to support. You don't want to get stuck in "analysis paralysis," so forget about gathering all of the details about these requirements right now. All you want is a list of the users and the goals that the application is supposed to support.

Effectively, what you're doing is naming the use cases. You identify the primary actors, the important roles that the actors play when working with the application, and the goals that the various actors have. The combination of a primary actor and a goal is the name of a use case. (It's also useful to include a goal description so that there is some context to help people understand the goal.)

For our little membership system, here are some possible use cases:

The first use case—Club Secretary : Maintain membership list—is really a summary goal, since it includes several related user goals:

When trying to determine the overall size and complexity of an application, you have to watch out for these summary goals. Yes, they're great for organizing our thinking about the application, but an amazing amount of work can be hiding inside an innocuous statement like "Maintain membership list."

Elaborating the Use Cases

Once some of the use cases have been named, you're ready to start investigating the real complexity of the system. Your hardest task is to guess how many use cases you will eventually have to deliver. This is difficult because everybody forgets things. It's extremely unlikely that the initial list of use cases is complete—it's likely to contain some use cases that are interesting to think about but will never actually be implemented, and it's likely to be lacking some really crucial use cases that will make everyone wonder how they were missed.

As long as you work in collaboration with the eventual end users, you can normally manage to name most of the use cases in the first few weeks of a project. You'll never manage to get them all at the start of a project. Some new use cases will only be identified after the users have been working with the application for a while and discover new ways that the application could help. This is perfectly normal. It's why most software developers choose to develop incrementally, delivering a small part of the application initially and then adding extra features every few weeks or months.

All you need to get started is a few use cases that the project sponsors consider important enough to be delivered first. Once you have these, the time has come to work with your users to semi-formally document how the system will work for each use case. To do this, you need to record the guarantees for the use case, and then document the main success scenario. The guarantees define what correct operation of the application looks like. The main success scenario describes the design for the actor's interaction with the application. This design of how the users will interact with the application is part of the requirements for the software. This is why you must have users actively involved in defining use cases, because if developers write them what you get are applications that were easy to develop but are a real pain to use.

Club Secretary : Notify members about special events. Send out information about forthcoming events and races to members.

Minimal Guarantee:

Success Guarantee:

Main Success Scenario:

  1. Club Secretary: Enter event details.

  2. Club Secretary: Choose members to send notice to.

  3. Membership System: Display number of members to be notified and await confirmation from the Club Secretary.

  4. Membership System: Send email notification to every selected member.

  5. Membership System: Record that notice was sent to selected members.

In this example, the users have decided that sending out multiple emails for the same event is a really bad idea, hence the guarantees stating this requirement. Step 3 of the main success scenario shows how the membership system shows up in the use case, and why when writing the use case it's important to put the minimum constraints on the design of the user interface.

It's perfectly acceptable to place technology constraints on the developers. Step 4 states that the membership system sends out email for notification. If that's what the users want, then that's what should be recorded as a requirement in the use case. On the other hand, if the users don't care how notification happens, that step would have been written as Membership System: Send notification to every selected member and the developers would then have design freedom to play with phone, fax, email, and possibly telepathy for notifying the membership about the special event.

Understanding the Hidden Complexity of Requirements

Although the main success scenario in a use case shows some details of what's supposed to happen, it can still hide an amazing amount of complexity. The complexity hides in how the application is supposed to deal with all of the weird and wonderful things that can go wrong at each step.

For example, at step 3 the Club Secretary may need to go back and choose a different set of members because the number selected the first time is wrong. Similarly, how is the application supposed to support resending an event notification to a different, partially overlapping subset of the membership?

Of course, you'll find even more complexity as you elaborate each of the use cases in turn. As you do this, it's normal for users to name other use cases that they hadn't thought of previously, so don't attempt to rush this activity. Once you have a few fully elaborated use cases, you can start getting serious about designing the application. Initially, it's sufficient to try to understand what the users really want and to attempt to grasp the underlying complexity.

Obviously, there is much more to writing a complete use case. My next article, "Becoming a Software Developer, Part 5: Creating Acceptance Tests from Use Cases," will look at the ways that the various steps in a use case scenario can fail, and how to create acceptance test cases to ensure that the implementation is correct. If you're impatient to find out more and can't wait until the next article, check out Alistair Cockburn's book Writing Effective Use Cases (Addison-Wesley, 2000, ISBN 0-201-70225-8).

So now, after reading how to partially elaborate a single use case, how hard do you think it will be to create this little application? Do you want to revise your original estimate yet?

© 2026 Pearson Education, Informit. All rights reserved.

800 East 96th Street, Indianapolis, Indiana 46240