Page 115 -

bottom line of the window, followed by the search term and the replacement term. Either
implementation would satisfy this use case.

Sometimes there is functionality that is replicated in many use cases. For example, say the
use cases for a program to play music files includes UC-15 (see Table 6-4), a use case that
allows a user to explore and edit information in one of his audio files.

TABLE 6-4. Basic course of events for “UC-15: Edit Audio File Information”
Precondition An audio file is highlighted.
Basic course of events 1. The user indicates that the software is to display information about the audio file.
2. The software responds by displaying the information fields (track name, artist, length,
genre, and year) associated with the audio file.
3. The user indicates that one of the information fields is to be replaced and specifies a
replacement value.
4. The software updates the audio file with the new value.
Postcondition Same as precondition state, except the audio file has an updated information field.

If the requirements analyst intends that the user be given the option to select an audio file in
many different use cases and edit that file at any time, each of those use cases may have a
use case step or an alternative path that reads: “The user indicates that the file is to be edited.
Use case UC-15 is executed.” In this way, multiple use cases can be extended to include this
functionality. The requirements analyst needs to describe it only once, which makes the use
cases clearer. This technique has the benefit of giving the designers and programmers hints
about where they can reuse code when the software is being developed.

Alternative Paths
Often, a use case has one basic course of events, as well as several alternative courses that
are very similar and that share many of the same steps. In these cases, they are docu-
mented as different alternative paths (rather than in separate use cases), to show that they
are closely related. An alternative path provides behavior that is similar to the basic course
of events but that differs in one or more key behaviors.
For example, an alternative path for the search-and-replace use case would be to only

replace the first occurrence of the search string. Table 6-5 shows the alternative path for
this behavior, as well as an alternative path for searching without replacement and
another one for aborting the operation:

TABLE 6-5. Alternative paths for search-and-replace
Alternative paths 1. In Step 3, the user indicates that only the first occurrence is to be replaced. In this case, the
software finds the first occurrence of the search term in the document being edited and
replaces it with the replacement text. The postcondition state is identical, except only the first
occurrence is replaced and the replacement text is highlighted.
2. In Step 3, the user indicates that the software is only to search and not replace, and does not
specifyreplacementtext.Inthiscase,thesoftwarehighlightsthefirstoccurrenceofthesearch
term and the use case ends.
3. The user may decide to abort the search-and-replace operation at any time during Steps 1, 2,
or 3. In this case, the software returns to the precondition state.

SOFTWARE REQUIREMENTS 107