ReadySET Pro: Use Case Tutorial

Six simple steps to writing effective use cases


Use cases are a popular way to express software requirements. They are popular because they are practical. A use case bridges the gap between user needs and system functionality by directly stating the user intention and system response for each step in a particular interaction.

Use cases are simple enough that almost anyone can read them. Even customers or users can read use cases without any special training. However, writing use cases takes some practice. It is not difficult to start writing use cases, but really mastering them takes training, practice, and insight.

No single use case specifies the entire requirements of the system. Each use case merely explains one particular interaction. An organized suite of use cases and other specification techniques are needed to fully specify the software requirements.

The figure below illustrates where a use case document fits into the overall software requirements specification (SRS) and how it relates to other documents. This white paper focuses on the yellow "Use Cases" box. Ideally, your use case document is just one part of an overall set of project documents. But, don't worry if you just want to jump straight into writing use cases: this white paper focuses on them.

Project Proposal
Business Need
Market Opportunity
Software Requirements Spec
Use Cases
Use Case Suite
Use Cases
Feature Specifications
Feature Set
Feature Specifications
Non-Functional Requirements
Environmental Requirements
Structural Design
Behavioral Design
User Interface
Build System
Target & Benefits
Target Market Segment
Claimed Customer Benefits
User Needs
Classes of Users
User Stories
Quality Assurance
QA Plan
Test Suite
Test Cases
Test Runs
Interview Notes
Requests from Customers

One goal of writing use cases is to specify the system to be built, so that the resulting specification can be handed off to someone else for implementation. Another important goal is to allow potential customers to read the use cases and validate them. Long before you reach these goals, you will find that the process of writing use cases is itself a very useful way to clarify your own thinking about the system requirements: by writing step-by-step descriptions, you force yourself to think through the details of the system's features.

Use cases and feature specifications complement each other. Use cases concretely explain how a user accomplishes a goal using one or more features of the system. Feature specifications describe the same system from a different perspective: a feature spec abstractly describes everything about one software feature and all it's possible uses.

It is a good idea to write the use cases and the feature specs in parallel. For example, when working through a use case, you might realize that a particular feature needs an additional option, so you would note that in the feature spec. Likewise, when making a pass over the feature specifications, you might realize that a feature needs a particular input value to work properly, so you might need to add a step to all use cases for that feature. Together, use cases and feature specs provide checks and balances that help you write requirements that are more complete, correct, and consistent.

The rest of this white paper works through the six steps shown in yellow in the diagram below. Beside those steps, we show the corresponding steps for writing feature specifications. (You may notice that this is very similar to the test case writing steps.)

Use Case Writing Steps
1: Identify Classes of Users
2: Outline the Use Case Suite
3: List Use Case Names
4: Write Some Use Case Descriptions
5: Write Steps for Selected Use Cases
6: Evaluate Use Cases
Feature Spec Writing Steps
1: Identify Functional Areas
2: Outline the Feature Set
3: List Feature Names
4: Write Some Feature Descriptions
5: Write Specs for Selected Features
6: Evaluate Features

Note that in steps 4 and 5, we recommend that you only specify the most important use cases in detail. In any complex system, there will be a large number of potential use cases. It is usually best to take a breadth-first approach: map out your use case suite first, then fill in details incrementally as needed. This concept is key to getting the most value out of the limited time that you have to write specifications.

After the SRS is written, each part is used in later work on the system. Both use cases and feature specs affect both the design and quality assurance of the system. However, feature specifications can affect the design more directly, and the use case suite can provide a stronger starting point for the system test suite.

Step One: Identify Classes of Users

The first step in writing use cases is understanding the users, their goals, and their key needs. Not all users are alike. Some users will expect to walk up to the system and accomplish one goal as quickly as possible. For example, some banking ATM customers just want "fast cash". Others may be power users who will master every option and shortcut over time.

It is important to identify and list classes of users so that none of them are forgotten. Too often, an entire class of users are initially overlooked, e.g., administrators. This leads to a frustrating series of requirements changes when their requirements must be added later.

Next, make sure that you know the key needs of each class of user. For example, one class of user may simply need a speedy transaction, whereas another class of user may need more guidance in making choices, and a third class of user may expect to reuse their knowledge of competing products.

How ReadySET Pro Helps

ReadySET Pro helps you identify classes of users and take advantage of that information while planning your use case suite.

The ReadySET Pro user needs template and use case suite template come pre-populated with reusable sample text describing classes of users that are found in many applications. The sample text will not fit your application exactly, but it gives you a big head start on this step.

When you specify additional classes of users, ReadySET Pro guides you in describing their key needs. For example, which business objects are of primary concern to these users? And, which other types of users do they interact with to accomplish specific business goals?

The ReadySET Pro templates are simply templates: they do not force you to follow a predefined process and they are not a magic bullet that does your work for you. For this first step, the reusable sample text gives you a head start can be expected to save you up to an hour. As you will see below, these time savings add up in each step.

In addition to saving time, ReadySET Pro can improve the quality of your project documents by helping with both the breadth and details of your work. ReadySET Pro provides a broad and remarkably complete set of project document templates that ask the right questions. So, you are less likely to overlook important areas of development. At the detailed level, the reusable sample text is well written and to-the-point. So, you can adapt it to fit your project, and still end up with a well written result.

Step Two: Outline the Use Case Suite

It is tempting to skip this step and jump directly into writing a use case. After writing one use case, you would write another, and so on. That process would be like coding your application without outlining the design first. You would never really know how much further you need to go before you are done, if you were spending too much time in one area, or if you had forgotten other important areas altogether.

The second step in our breadth-first approach to writing use cases is to outline the use case suite. A use case suite is an organized table of contents for your use cases: it simply lists the names of all use cases that you intend to write. The suite can be organized several different ways. For example, you can list all the classes of users, and then list use cases under each.

One particularly good use case suite organization is to use a grid where the rows are classes of users and the columns are business objects. Each cell in the grid will list use case names that are done by that class of user on that type of object. For example, in an e-commerce system, shoppers would have use cases for adding and removing products from their shopping carts. In contrast, administrators might have some very different use cases, for example, calculating the percentage of abandoned shopping carts.

The advantage of using an organized list or grid is that it gives you the big picture, and helps you put your finger on any area that needs more work. For example, in the e-commerce grid, there might be a business object "Coupon". It is obvious that shoppers use coupons, but it is easy to overlook the use cases for administrators who must create coupons. If it is overlooked, there will be a clearly visible blank space in the use case suite. These clear indications of missing requirements allow you to improve the requirements sooner rather than get bogged down in too many frustrating requirements changes later.

How ReadySET Pro Helps

The ReadySET Pro use case suite template is pre-populated with reusable sample lists and grids that help you organize your use cases around classes of users, priority, product releases, business objects, and other meaningful criteria. These lists and grids help you, for example, make sure that you cover every class of user that your system must support.

As stated above, starting with the ReadySET Pro templates can definitely save some time. In this particular step, you can expect to save some time on the actual writing. But more importantly, the templates guide your thinking toward a more complete specification that will lead to a better quality product in the end. Try our ROI Calculator to see for yourself how incremental improvements in quality can save substantial time and money.

Step Three: List Use Case Names

If you did step two, this step will be much easier to do well. Having an organized use case suite makes it easier to name use cases because the task is broken down into much smaller subtasks, each of which is more specific and concrete.

Put your finger, or cursor, on each list item or grid cell in your use case suite. Then, for each one, ask yourself about the relevant goals of users. Most of the time, you will think of two to five use cases fairly easily. Sometimes, there will be a list item or grid cell that really should be empty. For example, the administrator of an e-commerce site might not have any use cases for editing product descriptions, if that is done by a "store manager" class of users instead. In that situation, write "N/A" for "Not Applicable". Other times, you might know that there should be some use cases listed, but you cannot think of them at the moment. In that situation, write "TODO" as a reminder to come back to it later.

The name of each use case should be an active verb phrase describing a goal. For example: "Select product for purchase". The name should be written in terms that a user might use themselves. So, "Put product in shopping cart" is also fine. Use case names should not be written in implementation terms: "Insert SKU into checkout phase one hash-table" is definitely wrong. Keep in mind that one of the goals of writing use cases is to allow potential customers and users to read and validate them.

It is important to keep in mind that use cases focus on users' goals. For example, a banking ATM user's goal might be to "Get cash quickly." It is never the user's goal to "Choose preferred language", that is simply a step imposed by the system on the user who is trying to get cash quickly.

As you work through this step, you may also think of a feature that should be specified in the feature set. If that happens, just take a moment to note down the name of the feature.

Before moving on to the next step, it is worth pointing out that the result of this step is itself very valuable. Having a fairly complete suite of use case names, by itself, is major progress on the system specification. It already is enough for you to start doing some things that can help your overall project succeed. At this point, you can already get a better feeling for the scope of the release. You can already roughly prioritize use cases. You are already validating your definition of the classes of users. And, you can already recognize some needed features that might have been overlooked if you had jumped down into detailed steps too soon.

How ReadySET Pro Helps

The use case suite template is pre-populated with the names of several common use cases. This reusable sample text is centered around the process of user registration and login. That gives you a big head start if you are building an application that requires login. The sample text can also be helpful for application without login, because the samples demonstrate the correct tone, phrase structure, and level of detail.

Step Four: Write Some Use Case Descriptions

In step three, you may have generated ten to fifty use case names on your first pass. That number will grow as you continue to formalize the software requirements specification. That level completeness of the specification is very desirable because it gives more guidance in design and implementation planning, it can lead to more realistic schedules and release scoping decisions, and it can reduce requirements changes later.

The downside to mapping out the big picture is simply that it is too big. It could take a long time to fully specify every use case that you have mapped out. And, the resulting document could become too large, making it harder to validate and maintain.

The solution is to be selective before moving to the next level of detail. For example, if there are clearly too many use cases for one release, reschedule some of them for later releases. Also, it's a good idea to just write descriptions rather than get into detailed steps for each use case. Going deep into the details of just a few use cases is enough to shake out uncertainties and identify areas for improvement. The bulk of the use cases can be done later, it needed at all.

Write one to three sentence descriptions of each use case that you plan to implement in this release. The description should provide a little more information on the user's goal and briefly outline the strategy that the user will follow. Sometimes there will be two or more ways to accomplish the same goal. If there are significant differences in strategy, it is a good idea to split the use case into two distinct use cases.

How ReadySET Pro Helps

The use cases template is pre-populated with descriptions of several use cases focused on user registration and login. As mentioned in the previous steps, that reusable text can give you a big head start, and demonstrate the correct tone, phrase structure, and level of detail.

Step Five: Write Steps for Selected Use Cases

Now it is time for the main event: actually writing the use case steps. This is a task that you can expect to take ten to forty-five minutes for each use case. That might average out to only about ten use cases in a typical work day. Again, you must be selective to get the most value in return for your limited available time.

Focus on use cases that seem most likely to affect the success of the project. For example, select use cases that:

Each use case should show a straightforward example of the user succeeding at a goal. The steps in a use case are almost always a linear sequence. You should not use programming constructs such as if-statements or loops, if at all possible. Rather than use conditional statements, use an extension point to describe any type of failure or error condition.

Each use case step has two parts: a user intention and system response:

User Intention
The user intention is a phrase describing what the user intends to do in that step. Typical steps involve accessing information, providing input, or initiating commands. Usually the user intent clearly implies a UI action. For example, if I intend to save a file, then I could probably press Control-S. However, "press Control-S" is not written in use cases. In general, you should try not to mention specific UI details: they are too low-level and may change later.
System Response
The system response is a phrase describing the user-visible part of the system's reaction to the user's action. As above, it is best not to mention specific details that may change later. For example, the system's response to the user saving a file might be "Report filename that was saved". The system response should not describe an internal action. For example, it may be true that the system will "Update database record", but unless that is something that the user can immediately see, it is not relevant to the use case.

Use case steps can be written in either two-column or one-column format. The two-column format forces every step to include an explicit user intention and system response. The one-column format gives you more flexibility to skip system responses that are obvious, and to handle multiple actors interacting with the system in one use case.

Recall that one of the advantages of writing use cases is that it forces you to clearly think through the details of the system. Capture your insights by writing notes and questions as you go. If a use case step reminds you of a specific requirement in a system feature, make a note of it in the corresponding feature specification.

How ReadySET Pro Helps

ReadySET Pro contains several high-quality, reusable sample use cases. These use cases demonstrate the proper use of both formats, and the proper handling of exceptions. You can preview the Use Case Template or any other template through the Document Map.

A separate "use case format" document defines a notation for expressing user intentions using a small set of standard keywords.

Each use case template in ReadySET Pro also indicates its priority, frequency, preconditions, and direct actors. Possible values for these project management fields are also defined in the "use case format" document.

Step Six: Evaluate Use Cases

An important goal of any requirements specification is to support validation of the requirements. There are two main ways to evaluate use cases:

To make customer or user validation more effective, it is important to keep the steps simple, concrete, and at the right level of detail. As recommended above, you should avoid using programming constructs, in part, because users may not be familiar with them. Also, users have a bad habit of providing feedback on anything that is part of the use case, even if that is not the type of feedback you need. For example, if you had included unneeded UI details such as "Scroll and control-click the name of each desired country in the list", then you are likely to get feedback on the way that standard list widgets work rather than insights into the actual task at hand. Phrasing the user intention as "Select desired counties" forces everyone to focus on the relevant issues, e.g., will the user even know which countries are desired at this point in the interaction?

When reviewing use cases, you should start by checking for too many steps or especially difficult steps. A step may be difficult for a user if it requires knowledge that the user does not have in mind at that time, e.g., what are the zip codes of your last three residences? User often have difficulty remembering to perform "post-completion" steps that do not seem relevant to their immediate goal, e.g., children often do not remember to put away toys because their goal was simply to play with them.

Another very simple way to evaluate use cases is to try performing them yourself. A rough mockup of the system can simply list the contents of each screen, without getting into details of screen layout or particular UI widget selections. Pretending to use the mockup to work through the use case can point out some use case problems. For example, you may have specified a particular system response for a step, but then find that there is no good way for the system to present that response on the current screen.

You can perform a more careful evaluation of your use cases and UI mockups with cognitive walk-throughs. In the cognitive walk-through method, you ask yourself these questions for each step:

How ReadySET Pro Helps

ReadySET Pro's use case templates contain high-quality, reusable sample text that makes it easier to write use cases at the right level of detail. Keeping the right level of detail makes it easier to evaluate and improve your use cases without getting bogged down in UI details too soon.

The light-weight, web-based nature of ReadySET Pro makes it easy to share individual documents with a potential customer or user so that they can provide feedback. And, the comprehensive set of templates provided by ReadySET Pro helps you evaluate the use cases for consistency with project goals, claimed product benefits, user needs, the system design, and the QA plan.

The ReadySET Pro UI design template encourages designers to start with abstract descriptions of each screen that can be used to evaluate use cases. Without this step in design, far too many UI designers immediately jump into UI screen layout, widget selection, and careful wording of particular labels. While those design decisions need to be made eventually, it is usually better to start by validating the overall interaction flow for the highest priority use cases.


This white paper presented six simple steps to writing effective use cases. The keys to using use cases to effectively specify software requirements are to:

ReadySET Pro provides valuable help for writing effective use cases by giving you templates that include reusable content and set good examples for you to follow. Both of these advantages give you a big head start on your own software requirements specification. ReadySET Pro users typically save at least three hours by using the use case suite and use case templates alone. To estimate how these savings, and the savings from other templates, add up to days or weeks of project time, see the ROI Calculator.