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.

Step Four: Write Some Use Case Descriptions

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.

Step Three: List Use Case Names