Use case

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 Use Cases diagrams 6 Benefits of Use Cases 7 Problems with Use Cases

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 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.

Use Cases diagrams

Many people are introduced to Use Cases via UML, which defines a graphical notation for representing Use Cases. See here for more detail. UML does not define standards for the written format to describe Use Cases, and thus many people have the misapprehension that the graphical notation defines the nature of a use case; however, the graphical notation can only give the simplest overview of a Use Case or set of Use Cases.

Benefits of Use Cases

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. One reason Use Cases have become popular is that they have proved easily understandable by business users, and so have proved an excellent bridge between software developers and end users.

Problems with Use Cases

Use Cases are not without their difficulties. Use Cases are excellent for capturing the functional requirements of a system; but they are not so successful for capturing the non-functional requirements.