“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:

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:

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.