Enter Keywords:
Home arrow Product Engineering Practices arrow Use Cases
Use Cases Print E-mail
A use case is a description of a specific interaction that a user may have with the software. Use cases are deceptively simple tools for describing the behavior of the software. A use case contains a textual description of all of the ways that the intended users could work with the software through its interface. Use cases do not describe any internal workings of the software, nor do they explain how that software will be implemented. They simply show the steps that the user follows to use the software to do his work. All of the ways that the users interact with the software can be described in this manner.

Use Case Template

A typical use case includes these sections, usually laid out in a table:

Use case number and name
Brief description of the use case
Description of the reason that the use case is needed
A list of all categories of users that interact with this use case
The state of the software before the use case begins
Basic Course of Events
A numbered list of interactions between the system and one or more users
Alternative Paths
Conditions under which the basic course of events could change
The state of the software after the use case ends

This example shows a final use case for a search-and-replace function (which is numbered UC-8):

UC-8: Search
All occurrences of a search term are replaced with replacement text. 
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 automatically 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. 
All users
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 document.
  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 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 specify replacement text. In this case, the software highlights the first occurrence of the search 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.
All occurrences of the search term have been replaced with the replacement text. 

Use Case Development Script

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 development of the use cases.

Many requirements analysts have found that a four-step approach is effective in developing use cases. The following script describes this approach.


Use Case Development Script


 A four-step approach to use case development


 This approach to developing use cases allows the information to be gathered and documented naturally, in a way that lends itself to an iterative approach of alternating iteration, documentation and verification of use cases.

 Work Products

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, approximate 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 precondition 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 discovered, 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 which are awkward for the user that could be made more efficient. Finish all use cases which 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.

< Prev   Next >

Main Menu
Software Project Planning Practices
Review Practices
Product Engineering Practices
For Educators: Lecture Notes and Handouts
Praise for "Applied Software Project Management"
News from O'Reilly
Latest Releases from O'Reilly
Contact Us
Buy the Book
"Applied Software Project Management" © 2005 O'Reilly Media, Inc.
Website © 2006 Stellman & Greene Consulting LLC. Photos by Nisha Sondhe.