How to Use the User Interface to Discover All the Use Cases

December 29, 2009

If you build software for a living, it’s a matter of time before you find yourself discovering too late in a project that some important piece of functionality wasn’t accounted for. Often this is the result of assumptions — whoever was responsible for writing the functional spec assumed that some piece of functionality must be included, since omitting it would be illogical. Discovery of a missed piece of functionality usually sounds something like:

“Of course moderators have to approve user-uploaded photos! How could they not?”

Omissions like this are particularly common in the administrative half of applications. After all, the product guys invest lots of time designing the public-facing user interface, but use cases for administrative users are often overlooked or assumed to somehow just automagically be there. Those tasked with detailed spec-writing are often surprised that, in most systems, there are at least as many use cases for administrators as for public users.

This article discusses a simple technique for discovering those easy-to-miss use cases as early in the project as possible.

Accounting for all Basic UI Functions

You’re probably familiar with the set of basic database functions collectively known as CRUD:

  • Create a new record
  • Recall an existing record
  • Update an existing record
  • Delete an existing record

These four actions constitute the basic functions upon which almost all data storage and retrieval actions are based.

Corresponding to these four primary database functions are eight primary actions that your UI may provide:

UI Actions CRUD Functions
add create
view recall
list recall
search recall
edit update
recycle update (assumes setting a flag)
restore update (assumes setting a flag)
delete delete

Since our goal is to avoid surprises late in the project, we’re going to try to account for every action by every actor (user) upon every object in the system.

By way of example, let’s assume your system is something like flickr, so it will have use cases to handle its Photograph objects. We can account for those use cases like in this example:

Use Cases – Photograph Object
UI Action Actor Use Case
add new user Registered user uploads a new photograph.
view any user User clicks on thumbnail to view a full-size enlargement of a photograph.
view registered user User clicks on thumbnail to view a full-size enlargement of a private photograph whose access is restricted to users on the owner’s friends list.
list any user User views a list of thumbnails for photographs uploaded in the past seven days.
list registered user Registered user views a list of thumbnails for photographs they have uploaded.
list registered user Registered user views a list of thumbnails for photographs they have recycled.
list moderator Moderator views a list of thumbnails for photographs awaiting moderation.
search any user User searches for photographs by keywords and/or tags.
search any user User searches for photographs by minimum or maximum dimensions.
edit registered user Registered user edits metadata (title, description, tags, etc.) for one of their photographs.
edit registered user Registered user selects tags and applies them to a group of his photographs.
edit registered user Registered user changes the visibility of a photograph from ‘visible’ to ‘invisible’.
edit registered user Registered user changes the visibility of a photograph from ‘invisible’ to ‘visible’.
edit registered user Registered uploads a new photograph to replace an existing one. (Note: This action puts the photograph back in the queue for moderator approval.)
edit moderator Moderator sets the status of a photograph to ‘approved’.
edit moderator Moderator sets the status of a photograph to ‘rejected’.
recycle registered user Registered user recycles one photograph.
recycle registered user Registered user recycles photographs selected from a group.
recycle registered user Registered user recycles all of the photographs in a selected album.
restore registered user User restores a recycled photograph.
delete registered user Registered user permanently deletes a recycled photograph.

This is an example using only the system’s Photograph object. The idea is to go through this exercise with, yes, every object in the system.

Whoa! That’s going to be a lot of use cases!

Yes, it probably is, and it’s invariably more than you’d expect after just a cursory review of a system. But that’s the whole point: A cursory review misses a lot, so this is a fairly easy, methodical way to step through all of the actions, actors and objects in a system.

Are you crazy? Do you know how long that will take?

Yes, actually I know exactly how long it takes. I also know that it’s worth every minute. Here’s why: By the time any project is successfully completed, you have — one way or another — done this exercize. If you haven’t, the project didn’t complete successfully, and vice versa.

If this sounds tedious, it is. It can take days (or longer) to plow through all of the use cases uncovered by this technique. Note that I say uncovered and not created; this approach is meant to reveal and capture all those little cases nobody thought to include. One way or the other, your system won’t be complete until you account for all of these use cases, so the sooner you discover them, the better.

Since you’re going to have to account for all of these use cases in order to succeed, there are some compelling reasons to do it early in the project:

  • Identifying all of the likely use cases early helps you decide how to phase the project, which features to defer, and which pieces of functionality can probably be omitted altogether.
  • Identifying as many use cases as possible early in the project gives you the best data on how long it’s likely to take, how much it’s likely to cost, and in fact whether it’s worth doing.
  • Identifying use cases early enables testers to begin drafting test plans almost immediately.
  • Identifying use cases early enables tech writers to start writing user manuals almost immediately.
  • Identifying use cases early enables the whole team to succeed by design rather than by chance, which is good, because chance has a lousy track record.

It’s worth noting that there won’t necessarily be use cases for every action by every actor for every object. For example, there’s often no requirement for registered public users to delete thier own account (that is, the User object that represents their own account). It’s common to decide that not all functions are required for every object. Remember, the goal is to account for every possibility, not necessarily to implement them all.

Spawn PHP Framework

Learn all about installing and working with this easy-to-use MVC framework.

Continue reading »

Coming Soon: Scaveng

Scaveng is a scriptable web scraper. Stay tuned for more.