Ask A Good Product Manager

Your product management questions answered

What is the key to writing a good Use Case?

Posted on February 4, 2008 · 1 Comment

Question: Do you have any tips for product managers on how to write a good Use Case?

I have used a few different methods of writing Use Cases in the past but have the ability to start new in my new role at a new job. The Rational Unified Process is simply too much for my coworkers. I know writing a good Use Case is more than just the format, but can you recommend a good template or format — one that includes ‘alternate flows’?

Answer from Scott Sehlhorst of Tyner Blain: This is really a great question. As with many good questions, the answer starts with “It depends.” You point out that your team is resisting the RUP as being too heavy-weight. I’m going to answer your question in terms of both process and format – as they go hand in hand. I wrote about how to approach writing use cases as part of an agile project about a year ago, and that approach works really well in that environment. I’ve found since then, that it also works extremely well on non-agile projects.

The approach is designed to very quickly get an overview of the scope of the project – a “broad” view, and then to iteratively drill down into a “deep” view of each area of development until you have them all defined. This approach, even for non-agile projects, saves a lot of effort for the analysts and results in better use cases, written more quickly. The benefit comes from being able to incorporate feedback from each “deep dive” into both the broad view and the subsequent detailed views. There is an added benefit, when working in an incremental development environment, of being able to have the teams get started with the implementation of the most important use cases while the lower priority use cases are being defined in parallel. This allows you to compress the work schedule for the team overall.

Here are the steps you should take (after each step, allow yourself to revisit the previous steps as you refine your understanding of the product):

  1. Define the use case names. Each name is in the form of subject-verb-object, with a clear goal implicit in the name.
  2. Create rough sketches of all of the use cases. Identify the primary actor, and write a brief paragraph description of the use case.
  3. Prioritize the use cases you’ve identified.
  4. Create the informal use case (free MS Word template and tutorial after the jump) for the highest priority use case.
  5. If needed or desired, create formal use case to stress the preconditions and postconditions, and to present the behavior as a series of steps. Some development and test teams need the structure, others do not.
  6. Repeat step 4 (and optionally 5) for the highest priority use case that has not been detailed.

I’ve found, with experienced, local, development and test teams, that the informal use case format (linked above) is just as effective, with a lot less work, than the formal use case document. When outsourcing development, either the informal or formal document will be more effective – depending on the team. And to date, in every case with either inexperienced or outsourced or remote testing teams, a formal use case document is more cost-effective than the heavy amounts of clarification that are involved in explaining the informal format, and in reviewing the test plans that are created.

Good luck, and let us know how it turns out – or if you have had different experiences. Thanks again for the great question!

1 other answer so far ↓

  • Patrick Masi // Feb 27, 2008 at 2:07 pm

    Another decent test for a good use case is just to make sure that it avoids any language that implies specific designs. Sentences that start with “the user clicks the start button” or “the user selects an option from the menu” are red flags – instead of defining the business requirements, you are dictating the design.

    We like to say that a good use case should be accurate even in a world without computers – this way, you are sure that the business process is driving the software solution, not the other way around.