Use Cases vs Requirements vs Attributes/Methods

Related Sites

Here's a simple "Save File" use case:

USAGE: (reads like the user manual)

Basic Course:

The user selects the Save option from the file menu in order to save the current document to disk. The system displays a "File Save" dialog which allows the user to specify the directory and filename. After the user specifies this information, the file is stored to disk.

Alternative Courses:

If the filename specified by the user already exists at the specified location, the user is asked whether the existing file should be overwritten. If not, the "File Save" dialog is redisplayed.

If the disk is full, the system displays an alert to the user, and re-displays the "File Save" dialog, allowing the user do navigate to a different volume.

If an error occurs while writing the file, an alert is displayed.

..........

REQUIREMENTS: (reads like a specification document)

The system shall provide the ability to save files to disk. The system shall warn the user if an existing file is about to be overwritten.

..........

ATTRIBUTES and METHODS: (presumes a specific design at the requirements stage)

User specifies volume name, directory name, and a 32 character alphanumeric filename. The "CheckExistingFiles" method on the CDirectoryManager class is invoked. This method calls the "DisplayAlert" method of the CAlertHandler class if a file already exists in the specified location.

..........

All three of the above clearly specify some useful information about a system. Only the first one is a properly written use case. Clearly we don't want one use case per "shall" statement, as both of the stated requirements legitimately should be allocated to the "Save File" use case.

We might be able to guess the design correctly during the requirements definition phase, but it really isn't a good idea to be doing detailed design before we understand everything the system is supposed to do. Notice also that more than half the complexity of the use case occurs in the alternative courses of action; you're not done when you've written the basic course.

Writing the use case completely and unambiguously describes the behavior of the system, without presuming any specific design. "Solution space" objects such as the "File Save Dialog" (which would be an Interface Object) are identified by describing system usage from the user manual perspective.

There's an old (and too often ignored) programming maxim that is worth keeping in mind when approaching use cases. It goes: "write the user manual before you write the code". I probably heard this first 10 or 20 years before reading Jacobson's OOSE book.

A short introduction of use cases by Martin Fowler

Alistair Cockburn, Structuring Use Cases with Goals

Alistair Cockburn, Writing Effective Use Cases