In software engineering, a use case (pronounced yoos-case) is a technique for capturing the requirements of a new system or software change. Each Use Case provides one or more scenarios that convey how the system should interact with the end user or another system. Use Cases typically avoid technical jargon, preferring instead the language of the end user, or domain expert. Use Cases are often co-authored by software developers and end users.

Table of contents

1 Main Scenario 2 Alternate Scenarios 3 Scope of a Use Case 4 Other Parts of a Use Case 5 A Better Technique

Main Scenario

At a minimum, each use case should convey a primary scenario, or the typical course of events. The main scenario is often conveyed as a set of steps, for example:

• The system prompts the user to logon.
• The user enters his name and password.
• The system verifies the logon information.

...and so on.

Alternate Scenarios

Use cases may contain secondary, or alternate scenarios which are slight variations on the main theme. Exceptions, or what happens when things go wrong, may also be described.

Scope of a Use Case

Each use case focuses on just one feature of the system. For most software projects this means that multiple, perhaps dozens, of use case are needed to fully specify the new system. The degree of formality of a particular software project may influence the level of detail required in each use case. It is generally accepted that each use case be short enough to implement by one software developer in one release.

Other Parts of a Use Case

There are various formats, or templates for use case documents. Often, use cases provide a summary section that can be written earlier in a software project to capture the essence of the scenario before the main body is complete. A preconditions section can be used to convey any starting conditions that are assumed before the scenario can begin. Likewise, a post-conditions section summarizes the state of affairs after the scenario is complete.

A Better Technique

Use cases are a newer, more agile format for capturing sofware requirements. They are often contrasted to large, monolithic documents that attempt but fail to completely convey all possible requirements before construction of a new system begins. Use cases can be easily added and removed from a software project as priorities change. Use cases can also serve as the basis for the estimating, scheduling, and validating effort.