21wanajh84l_aa_sl160_.jpg Use cases are great. I consider them requirement “objects” in the “object oriented” sense. They are atomic functions that are portable and not necessarily dependent upon a certain situation. I think that modularity and “reusability” are among the most valuable aspects of using use cases to express requirements.

This modularity can be undermined, though, if we allow our use cases to get too far into specifics and implementation detail.

The book Use Cases: Requirements in Context (2nd Edition), by Kulak and Guiney, provides us with a couple simple ways to self-check our use cases to ensure that they include the appropriate level of detail, but aren’t reaching too far into design.

Use Case Naming

According to Kulak and Guiney, there are guidelines to naming use case that can help keep them at the appropriate level of detail. Use case names:

  • Should conform to verb-noun construction: mail checks, determine eligibility, trace shipment, print letter
  • Can contain adjectives or adverbs
  • Should not contain any situation-specific data
  • Should not be tied to an organization structure, paper forms, computer implementation, or manual process: enter form 104-B, complete approval window, get approval from immediate supervisor in Accounting DepartmentShould not use “weak verbs” … that do not describe the action: process, complete, do, track

One of my stumbling points when I first began authoring use cases was that I was prone to getting into the “who, what, when, where and how” in my use case names. Doing so isn’t necessarily wrong from a correctness standpoint, but it certainly undermines what is, as I mentioned above, one of the best things about use cases: their modularity. A name that is that two lines long is probably indicative to deep a level of detail in the use case. What I prefer to do now, and what I think it pretty standard, is to use the use case goal as the name.

So, the use case name should be brief, concise, and indicative of what the use case is accomplishing. Obviously, you can give a use case a short name and still include too much fluff, and this tip is offered more as a “helpful hint” type of tool than a fix-all. Here’s another way to check your use cases for appropriate detail:

Is “the system” stealing the show?

Does the use case take a user’s (actor’s) perspective, or does it appear that the user is just along for the ride while the system steals the show? Kulak & Guiney’s tip here is this:

When design creeps into a use case, it becomes quite obvious. When the system is performing several steps before responding to a user, it sounds an alarm that perhaps internal system design is being created and exposed.

Do you sometimes look back at your use cases and have to admit that they are difficult to distinguish from fully detailed test scripts, replete with steps including buttons to click, screens to access, where the system is going to grab a certain piece of data, etc.?

We get off the use case “straight-and-narrow” when we begin including detail in the steps of the use case that may need to change based on how the use case is implemented. Whether we use buttons or text links; 1 screen or 5 screens; or jsp’s, asp’s, or php’s, the user goal is the same. We want the steps of our use cases to include what a user or system must do to accomplish the goal, not on all the dirty details of how, and all the intricate functions the system may have to perform to support the user goal. That’s not to say that some of that detail doesn’t have it’s place in the use case. By all means, include business rules with use cases – but in a business rules section, or in a separate business rule repository and not as steps in the use case.

Anyway, I am finding the book to be an easy read and a nice resource of practical information on how to effectively express requirements through use cases. I’d encourage you to grab a copy of the book if you want to learn more about use cases, but have a hard time staying with Cockburn’s books, which are great resources, but have never been mistaken for light reading.

Do you have any little tips or tricks for keeping your use cases at the appropriate level of detail? Any preferred books or resources on use case basics? If so, please feel free to share. I always appreciate your comments!