In the near future I’m going to use a word. I’m going to use it as a cornerstone of an argument for something a bit radical. Not very, but a bit. The word is Use Case. Since everyone has an opinion, I’m going to be specific about what I mean.

Use Cases were invented by Ivar Jacobson in the 1980’s as a way to solicit requirements. It is NOT a way to use spare day-old boxes, arrows, and lollipops. While UML has a thing called Use Cases, that ain’t it. I mean a list of actor/system interactions with some context and some deviations. What do I want to use it for? It gives me, a developer, a fuller idea of what I’m actually supposed to build for my customer.

As close as I usually get is, after a conversation with a customer or team lead, is a bulleted list of things to do. It looks a bit like this:

• Add an activity to my time sheet.
• Set a start and end time to the activity.
• Describe the activity.
• You can’t save the activity if it doesn’t have a description or time range.
• Choose a time code associated with the activity. There should be a default.
• Display the activity on the time sheet.

It is generally how I think I’m going to implement the feature in enough detail to get all the corner cases implemented. This is not a Use Case, it’s a todo list. It doesn’t share any information about workflow or context or motivation. In short, I’m left with no empathy for my users. And if I don’t have empathy for my users, how can I try to make their lives, or at least their experience using my software, better?

A Use Case as I want to use term focuses on workflow and on the context surrounding the actions being described. It has the following parts:

• Title A name to distinguish it from other Use Cases
• User Intention Describes who, why, and what
• Precondition Where in the system your interaction will take place
• Interactions The happy path
• Extensions How conditions cause the happy path to deviate
• Postconditions How I expect those interactions to impact the system

Most of these are just prose, the interactions and extensions are tables with two columns, the actor’s actions and the system’s response. Each row is numbered. The Interaction rows are simple numbers. The extensions are numbered with numbers and letters to relate to the interaction they modify.

Great! I’ve created a wonky definition! Now what the heck does that look like?

An example

Add an Activity to a Time Sheet

Tony logs time spent working on the Bryce Co project so Cheryl can bill against the Bryce Co account.

Precondition User is logged in and viewing an editable timesheet

Interactions

Extensions

User enters none or only one of the start and end time