Page 116 -

As the requirements analyst defines additional alternative paths, it may become clear that
one of them is more likely to be used than the basic course of events. In this case, it may be
useful to swap them—make the alternative path into the basic course of events, and add a
new alternative path to describe the behavior previously called the basic course of events.
Table 6-6 shows a final use case for a search-and-replace function, which is numbered
UC-8 in this example.

TABLE 6-6. Use case for a simple search-and-replace function
Name UC-8: Search
Summary All occurrences of a search term are replaced with replacement text.
Rationale While editing a document, many users find that there is text somewhere in the file being edited
that needs to be replaced, but searching for it manually by looking through the entire document is
time-consuming and ineffective. The search-and-replace function allows the user to find it auto-
matically and replace it with specified text. Sometimes this term is repeated in many places and
needs to be replaced. At other times, only the first occurrence should be replaced. The user may
also wish to simply find the location of that text without replacing it.
Users All users
Preconditions A document is loaded and being edited.
Basic course of 1. The user indicates that the software is to perform a search-and-replace in the document.
events 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 occurrences are to
be replaced.
4. The software replaces all occurrences of the search term with the replacement text.
Alternative paths 1. In Step 3, the user indicates that only the first occurrence is to be replaced. In this case, the soft-
ware 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
specify replacement text. In this case, the software highlights the first occurrence of the search
term and the use case ends.
3. The usermaydecidetoabort thesearch-and-replace operation atanytimeduring Steps1, 2,or
3. In this case, the software returns to the precondition state.
Postconditions All occurrences of the search term have been replaced with the replacement text.

Develop Use Cases Iteratively
As the use cases are developed, additional information about how the software should
behave will become clear. Exploring and writing down the behavior of the software will lead
a requirements analyst to understand various aspects of the users’ needs in a new light, and
additional use cases and functional requirements will start to become clear as well. As this
happens, they should be written down with a name, number, and summary—once they are
in this form, the analyst can apply the four-step process to complete them.
The first step in developing use cases is identifying the basic ones that will be developed.
The list of features in the vision and scope document is a good starting point, as there will
usually be at least one use case per feature (usually more than one). This will probably not
be the final set of use cases—additional ones will probably be discovered during the devel-
opment of the use cases.
108 CHAPTER SIX