Kristof Kovacs

Software architect, consultant

Use cases are the best type of requirements specification

Photo courtesy of

When planning a software development, especially if it involves a team, I like to sit down with the client, and together we write a list of the expected features of the software as seen from the user's perspective. The list has three columns, as recommended in SCRUM best practices, so it's best done in a spreadsheet, and the columns are written to complete this sentence:

"As a ___(role)___, I ___(need feature)___, because ___(business reason)___."

Everyone immediately understands the first two. But the third one, it looks like over-engineering. It's not really necessary, is it? Surely the guy who came up with this form never had a real project on his hands? Who has time for such things?

Well, experience shows that the third column is important. It is at least as important as the first two, and sometimes even more. Why is that?

It's because of the old zen saying, "in the beginner's mind there are many possibilities, but in the expert's there are few". And because you are an expert at what you do, it's hard to imagine how somebody else, who is an expert in something else, can misunderstand what you mean in the second column. The third column adds context to the second.

A story of use cases and forklifts

Years ago, when we were not yet using this method of collecting requirements, I was involved in a project about tracking the movement of pallets around in a factory. One of the functionalities was to intelligently calculate where a pallet should move next. The requirement was specified something like this:

"The program must calculate where a pallet should be moved next, and show it to the user."

It's clear, isn't it? So the developer created the "Move this pallet..." dialog (we were in the age of client-side programs with remote Oracle database) in a way that there was a big drop-down list called "Next location", and the automatically calculated next location was already selected there as the default, so most of the time the user just had to hit Enter. What could be more user-friendly?

Only it turned out, that using the three column requirements version, it would have sounded something like this:

"As a forklift operator, I need the program to calculate where a pallet should be moved next and show it to me, because I have to choose which pallets to put on my forklift."

Sounds similar enough, but what a difference! He actually needed a very different, actually much simpler thing: a list of pallets, and their next location in the same list, to be able to choose which ones to fork up! With the solution that was made, he ended up having to select pallets by random, and see if their calculated next location matched where he was going. Not good.

So, context is the key! More information never hurt anybody, but often helps to prevent such costly mistakes. Most developers are smart enough to figure out what factors are most needed in a feature (speed? flexibility? extendability? security?), and are able to choose the best compromise if given enough information. So explaining why some feature is needed, in the context of business, is something that takes only a few seconds per feature, but may spare a few thousand dollars.

By the way, the story has a happy ending. When the real requirement was finally understood, the developer suggested an even better solution: the forklift operator was given a new dialog, where he entered where he wanted to go, and he got a list of only those pallets that needed to be taken there, so he didn't even have to browse a list and spot the right ones. This has made their jobs faster and more enjoyable.

(Because, let's face the truth: forklift operators don't enjoy looking at dialogs. What they enjoy is driving their powerful machines at just the right speed when stuff is not yet falling down.)

"As a project manager, I need specifications in the three column format, because it helps suggesting the best solution to the client."