Page 114 -

Preconditions and Postconditions
Any software that is being executed can be thought of as being in a state of operation.
When the software is in a certain state, it means that a specific set of operations are avail-
able to the user that are not available when the software is in other states. For example, a
word processor could have an existing document loaded, a new document displayed, or it
could be displaying no document at all. It could be showing a configuration window or a
dialog box. These are all different, distinct states that the word processing software can be
in. There are certain actions that are only available to the user when the software is in a
particular state. For example, the user can enter text into the document if the word pro-
cessor has an existing document loaded, but not if it is displaying a dialog box.
The precondition is the state of the software at the beginning of the use case. This represents
the entry criteria for the use case: if the software is not in that state, the use case does not
apply. The postcondition is the state that the software is left in after the use case is com-
pleted. In the use case, each of these states can be described in words (“the word processor
is loaded but no document is being edited”), although it is also possible to create a name
for each state and refer to it by name.

Basic Course of Events
The basic course of events is the core of the use case. Table 6-3 shows a very simple basic
course of events for a word processor’s search-and-replace feature.

TABLE 6-3. Basic course of events for search-and-replace
Precondition A document is loaded and being edited.
Basic course of events 1. The user indicates that the software is to perform a search-and-replace in the docu-
ment.
2. The software responds by requesting the search term and the replacement text.
3. The user inputs the search term and replacement text and indicates that all occur-
rences are to be replaced.
4. The software replaces all occurrences of the search term with the replacement text.
Postcondition All occurrences of the search term have been replaced with the replacement text.

The basic course of events consists of a series of steps. The first step will generally be the

action that the user takes in order to initiate the use case. The remaining steps are a series
of interactions between the user and the software. Each interaction consists of one or
more actions that the user takes, followed by a response by the software. In this case, the
software is responding to the user entering the search term and replacement text and indi-
cating that the replacement should occur.
This basic course of events does not contain words like “click,” “button,” “text box or
“window.” User interface design elements should be left out of use cases to allow the
designer as many options as possible. For example, this particular use case could be imple-
mented as a pop-up dialog box that contains text boxes for the search term and replace-
ment text, and a button that says “Replace All.” (This is how many word processors,
including Microsoft Word, do it). But that’s not the only way to satisfy this use case. In the
Emacs text editor, for example, the user hits Meta-X and enters “replace-string” on the
106 CHAPTER SIX