How to Write Good Use Case Names – 7 Tips

The first step in writing the use cases for a project is to define the scope of the project. One way to do that is to list the use case names that define all of the user goals that are in scope. To do that, you need to know how to write good use case names. Good use case names also serve as a great reference and provide context and understanding throughout the life of the project.

Goals of Use Case Naming

Use case names are also known as use case titles. When creating names, we have a set of goals:

• Clearly indicate the user goal represented by the use case.
• Avoid specifying the design of the system.
• Make people want to read the use case, not dread reading it.
• Allow for evolution of use cases across releases.
• Define the scope of the project.
• Write consistently

Common Use Case Mistakes

We identified the top ten use case mistakes in a couple of articles about a year ago. They still hold true today:

From Top Five Use Case Blunders:

• Inconsistency
• Incorrectness
• Wrong Priorities
• Implementation Cues
• Broken Traceability

From Top Ten Use Case Mistakes:

• Unanticipated Error Conditions
• Overlooking System Responses
• Undefined Actors
• Impractical Use Cases
• Out of Scope Use Cases

Writing good use case names will help avoid errors in consistency, implementation cues, scope management, and traceability. They will also help us make people want to read the use cases. Think of the use case name as the headline of a magazine article – does it make you want to read it, or avoid it?

Good use case names also serve as reminders of what a particular use case does. Weeks after we’ve written a use case, a quick scan of the title will remind us of what the use case represents. On a large project with dozens of use cases, this is invaluable.

Tips For Writing Good Use Case Names

Here are the best practices we’ve adopted, and some we’ve collected from around the internet.

• Good Use Case Names Reflect User Goals. A good use case name reflects the goal of the user (or external system). A name like “Process Invoices” doesn’t tell us what’s being done – is it collections, organization, auditing, or some other function? A more insightful name would be “Collect Late Payments From Customers.” The goal in this example is to collect payments from delinquent customers. The second name does a much better job of defining what the user is trying to do when they perform the use case.
• Good Use Case Names are As Short As Possible. Some people suggest 5 words, or even two words. There are just too many examples that make setting specific word-count limits impractical. In the previous example, “Collect Late Payments From Customers,” which words would you remove without losing meaning? This name is as short as we can make it without losing clarity. This short name is better than “Collect Late Payments From Customers Who Are Past-Due.”
• Good Use Case Names Use Meaningful Verbs. Usually people will suggest that we should prefer strong verbs to weak verbs. That is effective advice for general writing. For writing use cases, we can be more specific. A meaningless verb is one that, while indicating action, does not specify the action with enough detail. “Process the Order” can be improved with a more meaningful verb. “Validate the Ordered Items” makes it much more clear what the user is trying to achieve.
• Good Use Case Names Use An Active Voice. A call to action is a hallmark of good writing. Using an active voice will inspire action more than a passive voice. “Calculate Profitability” is more inspiring than “Profitability is Calculated.”
• Good Use Case Names Use The Present Tense. “Create New Account” is in the present tense. “New Account Was Created” is in the past tense. The present tense implies what the user is trying to do, not something that has already been done.
• Good Use Case Names Don’t Identify The Actor. Some people prefer to name the actor in the use case, because it is more specific. We like the idea of using evolutionary use cases to manage the delivery of functionality across releases. When we do this, we are often releasing the first version of the use case for one actor, and the next version for another actor. For example, “Rank Employee Performance” might be our use case. In the first release, we want to enable the functionality for supervisors – who can rank their direct employees. In the second release, we want to add the ability for managers to rank the employees that report to multiple supervisors. We prefer having two versions of the same use case over having two use cases (Rank Direct/Indirect Employee Performance).
• Good Use Case Names Are Consistent. We should always apply the same set of rules across all of our use case names. Inconsistent application of the names will create a sense of discord for our readers. Consistent names will make it more comfortable for readers, and provide a sense of cohesion for the overall project.

Other References

• Use Case Analysis
• Java Blackbelt on Use Case Diagrams
• The Coad Letter, Use Case Do’s and Don’ts

Summary

Good use case names take very little effort once we are used to writing them with a consistent style, following the tips listed above. Good names also provide benefits down the road when reviewing and reading the use cases. Good names are short, clear, and stylish. They also make us want to read the use cases, and easily jog our memories about the user’s goals.