Monthly Archives: January 2011

You Don’t Know Use Cases, Yet

Book Review: Writing Effective Use Cases by Alistair Cockburn

I’m willing to bet your Use Cases are written wrong (you do USE Use Cases, right?), or are not as effective as they could be, and I know this because mine were.  However, I had the pleasure of reading and using the book ‘Writing Effective Use Cases’ by Alistair Cockburn and now I have seen the light.

Turns out not only were my Use Cases wrong, so were all the people around me who were writing them for companies like WellPoint, Marsh & McLennan, Countrywide, Disney, and a host of smaller firms.  Well, maybe wrong is a bit strong, but certainly my Use Cases were far less effective and efficient than they could have been, I’m betting you have the same problem.

Why should you care about Use Cases?

To put it simply, you should care about Use Cases because an effective set of Use Cases will save you (and your team) major amounts of TIME, MONEY, and even potentially YOUR JOB.

Writing Effective Use Cases by Alistair Cockburn
Writing Effective Use Cases by Alistair Cockburn

Writing Effective Use Cases by Alistair Cockburn is a book that will teach you the correct way to write and utilize Use Cases, and by doing so save your projects (thus potentially saving YOU).  It is, without a doubt, one of the most important books you’ll read in the entire year.  Period.

Everyone, and I do mean EVERYONE needs to read and use this book.  This includes people who:

  • Work with websites, apps or anything else people interact with
  • Are part of a team that deals with websites, apps or anything else people interact with
  • Are in some way involved with people who work with websites, apps or anything else people interact with

To illustrate my point, I’ve slightly edited the script of the all-time best-ever classic movie, Casablanca, to highlight the importance of Use Cases:

INT. – GAMBLING HALL IN RICK’S BAR – NIGHT

Rick spins suddenly as the door in the gambling hall bursts open and is quickly slammed shut by Ugate.  Ugate braces his back to the door while several men on the other side pound on it attempting to break it down.

UGATE:

Rick! You’ve got to hide me! Rick!
They want to make changes to the requirements!

RICK:

Ugate, don’t be a fool, you can’t get away!
You’ve GOT to make those requirements changes!
You don’t have a set of solid and pre-approved Use Cases!

UGATE:

Rick!  Help me!
They told me the requirements were set,
they told me there wouldn’t BE any more changes!

In desperation, Ugate quickly moves away from the door, pulls out a pistol and fires several shots toward the door. Several bystanders in the hall scream.  The door smashes open and three Gendarme I.T. developer-type men enter, grabbing Ugate.

UGATE:

Rick!  Help me! Rick…!

The Gendarme I.T. developers wrestle the gun out of Ugate’s hands and quickly drag him out the door.

BYSTANDER PROJECT MANAGER:

I hope Rick when they come to get me
with requirements changes you’ll be more of a help!

Rick turns, speaking to the bystander PM and the room in general.

RICK:

I stick my neck out for no one!
Especially for anybody crazy enough to not have
a good set of Use Cases that everyone on the
project team approves prior to starting the project!

END

What’s a Use Case?

Here’s a quote from the book:

“A use case captures a contract between the stakeholders of a system about its behavior.  The use case describes the system’s behavior under various conditions as the system responds to a request from one of the stakeholders, called the primary actor.  The primary actor initiates an interaction with the system to accomplish some goal. The system responds, protecting the interests of all the stakeholders. Different sequences of behavior, or scenarios, can unfold, depending on the particular requests made and the conditions surrounding the requests.  The use case gathers those different scenarios together.”

The book continues,

“Use cases are fundamentally a text form, although they can be written using flow charts, sequence charts, Petri nets, or programming languages.  Under normal circumstances, they serve as a means of communication from one person to another, often among people with no special training.  Simple text is, therefore, usually the best choice.”

Here’s an example of what a Use Case looks like.

Example Use Case

Why are Use Cases so important?

Use Cases are important because they are the foundation and agreed-upon approach that a team will base a System Under Design on.  Use Cases if written properly will help everyone on the team.  Whether your team is composed of business owners, operations staff, executives, developers or project managers, a good Use Case will help all of them clearly understand exactly what the expected behavior is of a System Under Design is, and isn’t.  The Use Case helps the team understand each of the components, from the highest level behavior all the way down to sub-function behavior, everyone will know exactly how it’ll work.

And the type of System Under Design that Use Cases are created for do not matter, it could be anything from; creating an application to buy stocks over the internet, developing a new process for handling customer service calls or even texting someone using a smartphone.

The importance comes from several aspects of well written Use Cases including:

  • They clearly define what is in scope, and thus by definition what is out of scope
  • They provide sufficient detail so all team members clearly understand the purpose and function of each of the components of the System Under Design
  • Well-written Use Cases only provide the actual information necessary for understanding the behavior of the System Under Design, there is no extra, technically advanced, distracting or conflicting information
  • Because they are non-technical in writing style, everyone can read, understand, use and refer back to the Use Case
  • The Use Case acts as a contract and project guide, ensuring agreement and alignment of all parties involved in developing the System Under Design
  • A well-written Use Case acts as the foundation upon which all project management, requirements documentation, development and testing will stem from

Well-written Use Cases identify the points of success as well as failure for a System Under Design, ensuring there are no hidden ‘gotchas’ when a system or process is being developed.  This alone can often save a project.  This means a far better user experience that ensures the solution will benefit the end users and the company and/or team developing it.

A good set of Use Cases, starting at the top most summary level (typically referred to as Cloud or White) and going down to the more detailed sub-function level (typically labeled Fish or Indigo) provides a complete blueprint for how the System Under Design will behave across all situations and actors.  As such, they are a living set of documents that can be incorporated into the Requirements Document and thus referred to over and over again as questions or issues arise during development.  For this reason alone Use Cases are worth their weight in gold.

The other major benefit of a good set of Use Cases is helping to ensure the best possible user experience is provided because all functional and process issues have been considered and ironed-out way before development ever commences.

Many companies write and use Use Cases in their development efforts, however I’ve seldom (if ever) seen consistent and well constructed Use Cases.  There’s just as much variation to the format and quality of Use Cases as there are projects, or so it would seem.

Learn the correct way to write a Use Case

Believe it or not, there is a correct (and thus incorrect) way to write a Use Case, and you owe it to yourself to learn it.  The book, Writing Effective Use Cases by Alistair Cockburn is the tool you need to help you learn the correct way to write and use Use Cases.

The book itself is very easy to read and use, and is structured to allow anyone to:

  • Understand what use cases are, including the format, context and contents
  • Develop their own Use Cases, simple at first, but adding complexity over time
  • Take quizzes at the end of each chapter (with some answers included) to ensure the concepts are clearly understood
  • Act as a reference and handy ‘how-to’ tool when you start writing (or reading other) Use Cases

Conclusion: You don’t know Use Cases, yet

So my guess is just like me, you probably don’t know an efficient vs. non-efficient Use Case.  Like mine, I’m betting your Use Cases (assuming you use Use Cases, which you most definitely should) are probably not written as effectively as they could be.  Some of you may actually be calling your documents ‘Use Cases’ when in fact they aren’t Use Cases at all.  My former Use Cases were a very poor rendition of what a proper Use Case is.  But after reading and using the book ‘Writing Effective Use Cases’ by Alistair Cockburn I’m on the path to victory.

Now you can be too.

Reading and using this book to create effective Use Cases absolutely will benefit you, your team and your company the next time you have to participate in the design or creation of a System or Process.  And who knows? By being so much more effective and efficient, the next job you save, or promotion received, just might end up being your own!

As Rick said to Captain Renault:

RICK:

Louis, I think this is the beginning
of a beautiful friendship (with Use Cases).

Let's Connect

120Subscribers+1
934FollowersFollow
4,284FollowersFollow