White papers > Use Case Tutorial

Page 1

	Use Case Tutorial  Six simple steps to writing effective use cases

Introduction

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	→	Design Structural Design Behavioral Design User Interface Build System Architecture Persistence Security
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.

Page:   1   2   3     Next >>