A Couple Tips on Keeping Use Cases Simple

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!

3 Comments

  1. Schneider and Winters, Applying Use Cases, is also very good.

    The problem with Cockburn isn't Cockburn; it's some managerial types and some consultant types who turn his wisdom into mandatory templates where you must fill in every last field, leading to a 15 page description of Log In. Since he wrote Agile Development — a whole book about sufficiency over bureaucracy — I can't believe he intended his books to be used that way. But a mandatory template used as a checklist is a very mechanical management tool, and thus easily misused.

  2. I haven't read Schneider and Winters. Thanks for the tip!

    Recently, I've been leafing through Tom Pender's UML Bible. It also has some great stuff. Most of my experience with UML has been the basic behavioral model stuff that's typical in the BA world, so I have tried to supplement that a bit with a few good books.

    Your site has become my favorite quick-reference on on UML, though. I know I've said it before, but I'm a big fan.

  3. Thanks for the reference Martin. I am happy when folks find my book useful. 🙂

    Jonathan – really nice site here. It is nice to see other folks blogging about the business analyst role. I have been cross referencing with other bloggers in this space – it is good for our community to see the same information from different viewpoints.

    I'll add you to my blogroll at http://www.writingusecases.com and would appreciate if you link back to my site. Check it out first and see if you like it 🙂

    I'll have to check out Martin's site as well.

    Thanks for the great articles. They give me good ideas of other ways to express information.

Post a Comment

Your email address will not be published. Required fields are marked *