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.

Back to top

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.

Back to top

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.

Back to top

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.

Back to top

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)."

Back to top

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.

Back to top

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.

Back to top

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.

Back to top

Don't get hung up on <<include>> and <<extend>> 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 <<include>> and <<extend>> 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.

Back to top

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.

Back to top

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.

Resources

• The Object Primer 2nd Edition by Scott W. Ambler. New York: Cambridge University Press, 2001.
  
  
• The Unified Process Inception Phase by Scott W. Ambler and Larry L. Constantine. Gilroy, CA: R&D Books, 2000.
  
  
• Software For Use: A Practical Guide to the Models and Methods of Usage-Centered Design by Larry L. Constantine and Lucy A.D. Lockwood
  
  
• The Unified Modeling Language Reference Manual by James Rumbaugh, Grady Booch, and Ivar Jacobson. Reading, MA: Addison-Wesley Longman, Inc., 1999.
  
  

About the author

Comments

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Write from the point of view of the actor and in the active voice
• Write scenario text, not functional requirements
• Use cases only document behavioral requirements
• Don't forget the user interface
• Create a use case template
• Organize your use-case diagrams consistently
• Don't forget the system responses to the actions of actors
• Alternate courses of action are important
• Don't get hung up on <<include>> and <<extend>> associations.
• Let use cases drive user documentation
• Let use cases drive presentations
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers