Use case

In software engineering, a use case is a technique for capturing the potential 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 to achieve a specific business goal. Use cases typically avoid technical jargon, preferring instead the language of the end user or domain expert. Use cases are often co-authored by Business Analysts and end users.

In 1986, Ivar Jacobson, an important contributor to the Unified Modeling Language (UML) and Unified Process, originated the concept of the use case. Jacobson’s idea was influential and seminal. Numerous contributions have been made to the subject since then, but the most significant, influential and comprehensive, in terms of defining what use cases are and how to write them effectively, was provided by Alistair Cockburn, in his 2000 book Writing Effective Use Cases.

During the 1990s use cases became one of the most common practices for capturing functional requirements. This is especially the case within the object-oriented community where they originated, but their applicability is not restricted to object-oriented systems, because use cases are not object oriented in nature.

Scope and goals of a use case

Each use case focuses on describing how to achieve a single business goal or task. From a traditional software engineering perspective a use case describes just one feature of the system. For most software projects this means that multiple, perhaps dozens, of use cases are needed to embrace the scope of the new system. The degree of formality of a particular software project and the stage of the project will influence the level of detail required in each use case.

A use case defines the interactions between external actors and the system under consideration to accomplish a business goal. Actors are parties outside the system that interact with the system; an actor can be a class of users, roles users can play, or other systems.

Use cases treat the system as a "black box", and the interactions with system, including system responses, are as perceived from outside the system. This is deliberate policy, because it simplifies the description of requirements, and avoids the trap of making assumptions about how this functionality will be accomplished.

A use case should:

• describe a business task to serve a business goal
• have no implementation-specific language
• be at the appropriate level of detail
• be short enough to implement by one software developer in a single release.

Use Case diagrams

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

The UML standard is the most popular standard for graphical notation of use cases. However, there are a number of alternative standards.

UML Use Case diagram

OMG's UML standard defines a graphical notation for use cases, but it refrains from defining any written format for describing use cases in detail. Many people suffer under the misapprehension that a use case is its graphical notation (or is its description). While the graphical notation and descriptions are important, they are documentation of the use case -- a purpose for which the actor can use the system.

The true value of a use case lies in two areas.

The first is the written description of system behavior regarding a business task or requirement. This description focuses on the value provided by the system to external entities such as human users or other systems.

The second is the position or context of the use case among other use cases. As an organizing mechanism, a set of consistent, coherent use cases promotes a useful picture of system behavior, a common understanding between the customer/owner/user and the development team.

It is common practice to create supplementary specifications to capture requirement details that lie outside the scope of use case descriptions. Examples of these topics include performance, scale/management issues, or standards compliance.

UML Use Cases for a Simplistic Restaurant Model

The diagram on the right describes the functionality of a simplistic Restaurant System. Use cases are represented by ovals and the Actors are represented by stick figures. The Patron actor can Eat Food, Pay for Food, or Drink Wine. Only the Chef actor can Cook Food. Note that both the Patron and the Cashier are involved in the Pay for Food use case. The box defines the boundaries of the Restaurant System, i.e., the use cases shown are part of the system being modelled, the actors are not.

Interaction among actors is not shown on the use case diagram. If this interaction is essential to a coherent description of the desired behavior, perhaps the system or use case boundaries should be re-examined. Alternatively, interaction among actors can be part of the assumptions used in the use case. However, note that actors are a form of role, a given human user or other external entity may play several roles. Thus the Chef and the Cashier may actually be the same person.

Three major relationships among use cases are supported by UML. The UML standard describes graphical notation for these relationships. In one form of interaction, a given use case may include another. The first use case often depends on the outcome of the included use case. This is useful for extracting truly common behaviors from several use cases into a single description. The notation is a dashed arrow from the including to the included use case, with the label <<include>>. This usage resembles a macro expansion where the included use case behavior is placed inline in the base use case behavior. There are no paramaters or return values.

In another form of interaction, a given use case, (the extension) may extend another. This relationship indicates that the behavior of the extension use case may be inserted in the extended use case under some conditions. The notation is a dashed arrow from the extension to the extended use case, with the label <<extend>>. This can be useful for dealing with special cases, or in accommodating new requirements during system maintenance and extension.

In the third form of relationship among use cases, a generalization/specialization relationship exists. A given use case may be a specialized form of an existing use case. The notation is a solid line ending in a hollow triangle drawn from the specialized to the more general use case. This resembles the object-oriented concept of sub-classing, in practice it can be both useful and effective to factor common behaviors, constraints and assumptions to the general use case, describe them once, and deal with same as except details in the specialized cases.

Writing a use case

Degree of detail

Alistair Cockburn in Writing Effective Use Cases identifies three degrees of detail in writing use cases...

Brief

A brief use case consists of a few sentences summarizing the use case. It is highly suitable to use a spreadsheet for planning software development. A brief use case can be easily inserted in a spreadsheet cell, and allows the other columns in the spreadsheet to record business priority, technical complexity, release number, etc .

Casual

A casual use case consists of a few paragraphs of text, covering the items mentioned above, elaborating the use case in the form of a summary or story.

Detailed

A detailed or complex use case is a formal document based on a long template with fields for various sections; and it is the most common understanding of the meaning of a use case. Detailed use cases are discussed in detail in the next section on use case templates and can be seen there as well.

Appropriate detail

Some software development methodologies do not require anything more than a simple use case to define requirements. However, some other development methodologies require detailed use cases to define requirements. The larger and more complex the project, the more likely it will be necessary to use detailed use cases.

The level of detail in a use case often differs according to the progress of the project. The initial use cases may be brief; but as the development process unfolds the use cases become ever more detailed. This reflects the different requirements of the use case. Initially they need only be brief; because they are used to summarise the business requirement from the point of view of users. However, later in the process, software developers need far more specific and detailed guidance.

Use case templates

There is no standard template for documenting detailed use cases. There are a number of competing schemes, and individuals are encouraged to use templates that work for them or the project they are on. Standardization within each project is more important than the detail of a specific template. There is, however, considerable agreement about the core sections; beneath differing terminologies and orderings there is an underlying similarity between most use cases.

Typical sections include:

• Use Case Name
• Iteration
• Summary
• Preconditions
• Triggers
• Basic course of events
• Alternative paths
• Postconditions
• Business rules
• Notes
• Author and date

Different templates often have additional sections, e.g. assumptions, exceptions, recommendations, technical requirements. There may also be industry specific sections.

Use case name

The use case name provides a unique identifier for the use case. It should be written in verb-noun format (e.g., "Borrow Books", "Withdraw Cash"), should describe a completable goal (e.g., "Register User" is better than "Registering User") and should be sufficient for the end user to understand what the use case is about. Goal-driven use case analysis will name the use cases according to the Actor's goals thus ensuring use cases are strongly user centric. Two to three words is the optimum length. If four or more words are proposed in the name there is usually a shorter better name that can be used.

Iteration

'Bold text'Bold textItalic text'Italic text'Italic text'Italic text'Italic text'Italic text'Italic text'Italic text'Often an iteration section is needed to inform the reader the stage a use case has reached. The initial use case developed for business analysis and scoping may well be very different from the evolved version of that use case when the software is being developed. Older versions of the use case may still be current documents, because they may be valuable to different user groups.

Summary

The summary section is used to capture the essence of the use case before the main body is complete. It provides a quick overview which is intended to save the reader from having to read the full contents of a use case to understand what the use case is about. Ideally a summary is just a few sentences or a paragraph in length and includes the goal and principal actor.

Preconditions

A preconditions section is used to convey any conditions that must be true when a user initiates a use case. They are not however the triggers that initiate a use case. Where one or more preconditions are not met, the behaviour of the use case should be considered indeterminate.

Triggers

The Triggers section describe the starting condition(s) which cause a use case to be initiated. Can be external, temporal or internal

Basic course of events

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

1. The system prompts the user to logon.
2. The user enters their name and password.
3. The system verifies the login information.
4. The system logs user on to system.

...and so on.

Alternative paths

Use cases may contain secondary paths, or alternative scenarios which are variations on the main theme. Exceptions, or what happens when things go wrong, may also be described, either within the alternative paths section or in a section on their own. The alternative paths make use of the numbering of the basic course of events to show at which point they differ from the basic scenario, and if appropriate where they rejoin. The intention is to avoid repeating information unnecessarily.

An example of an alternative path would be:

1. The system recognizes cookie on users machine.
2. Go to step 4 (Main path)

An example of an exception path would be:

3. The system does not recognize users logon information

4. Go to step 1 (Main path)

Postconditions

The post-conditions section summarizes the state of affairs after the scenario is complete.

Business rules

Business rules are written or unwritten rules that determine how an organization conducts its business with regard to a use case. Business rules are a special kind of assumption. Business rules may be specific to a use case or apply across all the use cases, and indeed all the business.

Notes

Experience has shown that whatever template is used, analysts discover there is always important information that doesn't fit the structure of the template. Therefore each template usually includes a section for such seemingly inevitable information.

Author and date

This section should list when this version of the use case was created and who documented it. It should also list and date any versions of the use case from an earlier stage in the development which are still current documents. The author is traditionally listed at the bottom, because it is not considered to be essential information; use cases are intended to be collaborative endeavors and they should be jointly owned.

Use cases and the development process

The specific way use cases are used within the development process will depend on which development methodology is being used. In certain development methodologies, a brief use case survey is all that is required. In other development methodologies, the use cases evolve in complexity and change in character as the development process proceeds. In some methodologies, they may begin as brief business use cases, evolve into more detailed system use cases, and then eventually develop into highly detailed and exhaustive test cases.

Benefits of Use Cases

Use cases are a newer, more agile format for capturing software 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 have a number of advantages:

• Use case modelling (including the writing of use case specifications) is generally regarded as an excellent technique for capturing the functional requirements of a system.
• Use cases discourage premature design.
• Use cases are traceable.
• Use cases can serve as the basis for the estimating, scheduling, and validating effort.
• Use cases are reusable within a project. The use case can evolve at each iteration from a method of capturing requirements, to development guidelines to programmers, to a test case and finally into user documentation.
• Use case alternative paths capture additional behaviour that can improve system robustness.
• Use cases are useful for scoping. Use cases make it easy to take a staged delivery approach to projects; they can be relatively easily added and removed from a software project as priorities change.
• Use cases have proved to be easily understandable by business users, and so have proven an excellent bridge between software developers and end users.
• Use case specifications don't use a special language. They can be written in a variety of styles to suit the particular needs of the project.
• Use cases allow us to tell stories. It is very easy to describe a use case in a concrete way by turning it into a story or scenario.
• Use cases are concerned with the interactions between the user and the system. They make it possible for user interface designers to become involved in the development process either before or in parallel with software developers.
• Use cases put requirements in context, they are clearly described in relationship to business tasks.
• Use case diagrams help stakeholders to understand the nature and scope of the business area or the system under development.
• Use case diagrams can be recorded using the UML and maintained within widely available CASE tools
• Use cases and use case diagrams can be fully integrated with other analysis and design deliverables created using a CASE tool to produce a complete requirements, design and implementation repository

Limitations of Use Cases

Use cases are not without their limitations:

• Use cases are not well suited to easily capturing non-functional requirements of a system.
• Use cases templates do not automatically ensure clarity. Clarity depends on the skill of the writer(s).
• Use cases are not well suited to safety critical and real time systems where a greater degree of precision is required.
• Use cases have a learning curve involved in interpreting them correctly, for both end users and programmers.
• Proponents of Extreme Programming often consider use cases needlessly document centric, preferring to use the simpler approach of user stories.
• Use case developers often find it difficult to determine the level of user interface(UI) dependency to incorporate in the use case. While use case theory suggests that UI not be reflected in use cases, many find it awkward to abstract out this aspect of design as it makes the use cases difficult to visualize.
• Use cases say little about the data required for the tasks.
• Use cases cope poorly with non-task activities (activities that are not real work tasks, but where product functionality is still required). For example, ad hoc reports, games, browsing without a precise goal, and various supervisory functions (e.g. checking the system itself is working smoothly).
• Use cases are too detailed to be used as domain-level requirements, and thus are not suited to COTS-based acquisition.

Software

• Case Complete
• eRequirements

See also the list of UML tools.

See also

• Business case

External links

• Understanding Use Case Modeling Basic introduction to use case modelling

• Precise Use Cases

• Estimating With Use Case Points This article describes the process to measure the size of an application modeled with UML, using use case points.

• Use Case Template This PDF file from Bredemeyer contains a useful template for Use Cases.

• Succeeding with Use Cases: Working Smart to Deliver Quality Book focusing on synergistic benefits of use cases “cross-pollinated” with other software / quality engineering disciplines: Quality Function Deployment(QFD), Software Reliability engineering, Model-Based Specification (Preconditions, Postconditions, and Invariants), Requirements Configuration Management and Project Portfolio Management.

• Introduction to UML 2 Use Case Diagrams by Scott W. Ambler

• UML 2 Use Case Diagram Guidelines by Scott W. Ambler

• Software Requirements - Styles and Techniques by Soren Lauesen, book focussing on techniques for eliciting software requirements.