Tips and techniques to improve the quality of system use-case models

Write from the point of view of the actor and in the active voice

Use cases should be written in the active voice: "The student indicates the seminar," instead of in the passive voice, "The seminar is indicated by the student." Furthermore, use cases should be written from the point of view of the actor. After all, the purpose of use cases is to understand how your users will work with your system.

Write scenario text, not functional requirements

A use case describes a series of actions that provide value to an actor; it doesn't describe a collection of features. For example, the "Enroll Student in Seminar" use case describes how a student interacts with the system to sign up for a seminar. It doesn't describe what the user interface looks like or how it works. You have other models to describe this important information, such as your user interface model and your supplementary specifications. Object-oriented analysis is complex, which is why you have several models to work with, and you should apply each model appropriately.

Use cases only document behavioral requirements

A use case is neither a class specification nor a data specification. This is the sort of information that should be captured by your conceptual model, which in the object world is modeled via a UML class model. You are likely to refer to classes described in your conceptual model, for example, the "Enroll in Seminar" use case includes concepts, such as seminars and students, both of which would be described by your conceptual model.

Don't forget the user interface

System use cases often refer to major user interface (UI) elements, often called boundary or user interface items, such as HTML pages and reports. Use cases will sometimes refer to minor UI elements, such as buttons or data entry fields, although this level of detail is not as common.

Create a use case template

Use cases include a fair amount of information, information that can easily be documented in a common format. You should consider developing your own template (see the tip "Documenting a Use Case)."

Organize your use-case diagrams consistently

Common practice is to draw inheritance and extend associations vertically, with the inheriting/extending use case drawn below the parent/base use case. Similarly, include associations are typically drawn horizontally. Note that these are simple rules of thumb -- rules that, when followed consistently, result in diagrams that are easier to read.

Don't forget the system responses to the actions of actors

Your use cases should describe both how your actors interact with your system and how your system responds to those interactions. For example, with the "Enroll in Seminar" use case, if the system does not respond when the student indicates they want to enroll in a seminar, the student would soon become discouraged and walk away.

Alternate courses of action are important

Start with the happy path, the basic course of action -- but don't forget the alternate courses as well. Alternate courses will be introduced to describe potential usage errors, as well as business logic errors and exceptions. This important information is needed to drive the design of your system, so don't forget to model it in your use cases.

Don't get hung up on <> and <> associations.

I'm not quite sure what happened, but I've always thought the proper use of include and extend associations, as well as uses and extends associations in older versions of the UML, were never described well. As a result, use-case modeling teams had a tendency to argue about the proper application of these associations, wasting an incredible amount of time on an interesting, but minor, portion of the overall modeling technique. I even worked at one organization that went so far as to outlaw the use of the <> and <> stereotypes, an extreme solution that had to be reversed after a few weeks when it was realized that the company still needed these concepts, even though the organization hadn't come to a full agreement as to their proper use.

Let use cases drive user documentation

The purpose of user documentation is to describe how to work with your system. Each use case describes a series of actions taken by actors using your system. In short, use cases contain the information from which you can start writing your user documentation. For example, the "how to enroll in a seminar" section of your system's user documentation could be written using the "Enroll in Seminar" use case as its base.

Let use cases drive presentations

Part of software development is communicating your work efforts with project stakeholders, resulting in the occasional need to give presentations. Because use cases are written from the point of view of your users, they contain valuable insight into the type of things your stakeholders are likely to want to hear about in your presentations. In other words, use cases often contain the logic from which to develop presentation scripts.