Page 117 -

Many requirements analysts have found that a four-step approach is effective in develop-
ing use cases. Table 6-7 contains a script that describes this approach.

TABLE 6-7. Use case development script

Name Use case development script
Purpose A four-step approach to use case development
Summary This approach to developing use cases allows the information to be gathered and docu-
mented naturally, in a way that lends itself to an iterative approach of alternating iteration,
documentation, and verification of use cases.
Work products Output
Use Cases
Entry criteria A requirements analyst has received feedback from elicitation and is ready to develop use
cases.
Basic course of events 1. Identify the basic set of use cases. Assign a name and number to each use case.
2. Add a rationale and summary to each use case. Identify which users will interact with each
use case, and add them as well. Create a master list of user categories that identifies all of
the information known about each kind of user: titles, roles, physical locations, approxi-
mate number of users in the category, organizational policies they must adhere to, and
anything else that makes someone part of their category. Where possible, add precondi-
tion and postcondition states to the use cases.
3. Define the basic course of events and the alternative paths for each use case. Finish adding
the precondition and postcondition states. If additional users and use cases are discov-
ered, add them as well (starting with just a name and number, and then adding the other
information as in Step 2).
4. Verify each use case, ensuring that all paths make sense and are correct. Go through each
step with user representatives to make sure that they accurately represent the way they
expect the users to interact with the software. Look for any steps that are awkward for the
user that could be made more efficient. Finish all use cases that were added in Step 3.
Exit criteria The use cases are complete and no additional information has been uncovered, which may
lead to additional use cases being developed. If additional use cases have been discovered,
return to Step 1 to fill them in.

A requirements analyst defining a set of use cases for this software would start by creating
one use case for each feature. Initially, each of these would have a name and a number.
The numbering system does not matter, as long as it is unique. (A number such as “UC-1”
is sufficient.) The requirements analyst should create a new use case document with a

blank template for each of these use cases, filling in the name and number for each of
them and proceeding through each of the four steps to create a complete set of use cases.

NOTE
An expanded use case format and a great deal of practical information
on developing use cases for software projects can be found in Use Cases:
Requirements in Context by Daryl Kulak, Eamonn Guiney, and Erin
Lavkulich (Addison Wesley, 2000).

SOFTWARE REQUIREMENTS 109