A use case is a technique used in software and systems engineering to capture the functional requirements of a system. Use cases describe the interaction between a primary actor—the initiator of the interaction—and the system itself, represented as a sequence of simple steps. Actors are something or someone which exist outside the system under study, and who (or which) take part in a sequence of activities in a dialogue with the system, to achieve some goal: they may be end users, other systems, or hardware devices. Each use case is a complete series of events, from the point of view of the actor.^[1] Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software. ... Systems engineering techniques are used in complex projects: from spacecrafts to chip design, from robotics to creating large software products to building bridges, Systems engineering uses a host of tools that include modeling & simulation, requirements analysis, and scheduling to manage complexity Systems Engineering (SE) is an interdisciplinary approach and means... Functional requirements define the internal workings of the software: that is, the calculations, technical details, data manipulation and processing, and other specific functionality that show how the use cases are to be satisfied. ... In the Unified Modeling Language (UML), an actor is something or someone who supplies a stimulus to the system. ...

According to Bittner and Spence:

Each use case describes how the actor will interact with the system to achieve a specific goal. One or more scenarios may be generated from each use case, corresponding to the detail of each possible way of achieving that 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 systems analysts and end users. The UML use case diagram can be used to graphically represent an overview of the use cases for a given system. In the Unified Modeling Language (UML), an actor is something or someone who supplies a stimulus to the system. ... In computing, a scenario is a typical interaction between the user and the system or between two software components. ... Economics and commerce define an end-user as the person who uses a product. ... A domain expert or subject matter expert (SME) is a person with special knowledge or skills in a particular area. ... Systems analysis is the science dealing with analysis of complex, large scale systems and the interactions within those systems. ... In the field of software engineering, the Unified Modeling Language (UML) is a standardized specification language for object modeling. ... A use case diagram is a type of behavioral diagram defined by the Unified Modeling Language (UML). ...

Within systems engineering, use cases are used at a higher level than within software engineering, often representing missions or stakeholder goals. The detailed requirements may then be captured in SysML requirement diagrams or similar mechanisms. The term stakeholder has two distinct uses in the English language: The traditional usage, in law and notably gambling, a third party who temporarily holds money or property while its owner is still being determined. ... SysML, or Systems Modeling Language, is a general-purpose systems engineering modeling language. ...

History

In 1986, Ivar Jacobson, later an important contributor to the Unified Modeling Language (UML) and Rational Unified Process, first codified the visual modeling technique for specifying use cases. Originally he used the terms usage scenarios and usage case, but found that neither of these terms sounded natural in English, and eventually he settled on the term use case^[3]. Since Jacobson originated use case modeling many others have contributed to improving this technique, including Kurt Bittner, Alistair Cockburn, Gunnar Overgaard, and Geri Schneider. Ivar Hjalmar Jacobson (born in Ystad, Sweden, on September 2, 1939) is a Swedish computer scientist. ... In the field of software engineering, the Unified Modeling Language (UML) is a standardized specification language for object modeling. ... The Rational Unified Process (RUP) is an iterative software development process created by the Rational Software Corporation, now a division of IBM. The RUP is an extensive refinement of the (generic) Unified Process. ... Visual modeling is the graphic representation of objects and systems of interest using graphical languages. ... Alistair Cockburn (name pronounced Co-burn, in the Scottish way) is one of the initiators of the Agile movement in software development. ...

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. Functional requirements define the internal workings of the software: that is, the calculations, technical details, data manipulation and processing and other specific functionality that show how the use cases are to be satisfied. ... Object-oriented programming (OOP) is a computer programming paradigm in which a software system is modeled as a set of objects that interact with each other. ...

Overview

Each use case focuses on describing how to achieve a goal or task. For most software projects this means that multiple, perhaps dozens, of use cases are needed to define 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.

Use cases should not be confused with the features of the system under consideration. A use case may be related to one or more features, a feature may be related to one or more use cases.

A use case defines the interactions between external actors and the system under consideration to accomplish a goal. An actor specifies a role played by a person or thing when interacting with the system.^[4] The same person using the system may be represented as two different actors because they are playing different roles. For example, "Joe" could be playing the role of a Customer when using an Automated Teller Machine to Withdraw Cash, or playing the role of a Bank Teller when using the system to Restock the Cash Drawer.

Use cases treat the system as a black box, and the interactions with the system, including system responses, are perceived as from outside the system. This is a deliberate policy, because it forces the author to focus on what the system must do, not how it is to be done, and avoids the trap of making assumptions about how the functionality will be accomplished. Black box is technical jargon for a device or system or object when it is viewed primarily in terms of its input and output characteristics. ...

Use cases may be described at the abstract level (business use case, sometimes called essential use case), or at the system level (system use case). The differences between these is the scope.

• The business use case is described in technology free terminology which treats the business process as a black box and describes the business process that is used by its business actors (people or systems) to achieve their goals (e.g., manual payment processing, expense report approval, manage corporate real estate.) The business use case will describe a process that provides value to the business actor, and it describes what the process does.
• The system use cases are normally described at the sub process level (for example, create voucher) and specify the data input and the expected data response. The system use case will describe how the actor and the system interact. For this reason it is recommended that a system use case specification begin with a verb (e.g., create voucher, select payments, exclude payment, cancel voucher.)

A use case should:

• Describe how the system shall be used by an actor to achieve a particular goal.
• Include no implementation-specific language.
• Be at the appropriate level of detail.
• Not include detail regarding user interfaces and screens. This is done in user-interface design.

Writing a use case

Degree of detail

Alistair Cockburn, in Writing Effective Use Cases, identified three levels of detail in writing use cases:^[5] Alistair Cockburn (name pronounced Co-burn, in the Scottish way) is one of the initiators of the Agile movement in software development. ...

• A brief use case consists of a few sentences summarizing the use case. It can be easily inserted in a spreadsheet cell, and allows the other columns in the spreadsheet to record priority, technical complexity, release number, and so on.

• A casual use case consists of a few paragraphs of text, summarizing the use case.

• A fully dressed use case is a formal document based on a detailed template with fields for various sections; and it is the most common understanding of the meaning of a use case. Fully dressed use cases are discussed in detail in the next section on use case templates.

Appropriate detail

Some software development processes do not require anything more than a simple use case to define requirements. However, some other development processes require detailed use cases to define requirements. The larger and more complex the project, the more likely that 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 summarize the business requirement from the point of view of users. However, later in the process, software developers need far more specific and detailed guidance.

Rational Unified Process invites developers to write a brief use case description in the use case diagram, with a casual description as comments and a detailed description of the flow of events in a textual analysis. All those can usually be input into the use case tool (e.g., a UML Tool, SysML Tool), or can be written separately in a text editor. The Rational Unified Process (RUP) is an iterative software development process created by the Rational Software Corporation, now a division of IBM. The RUP is an extensive refinement of the (generic) Unified Process. ... A use case diagram is a type of behavioral diagram defined by the Unified Modeling Language (UML). ... A UML tool is an application software that supports some or all parts of the processes or the creation of the artifacts described in the software industry standard Unified Modeling Language (UML), which is used in the field of software engineering. ...

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
• Version
• Summary
• Actors
• 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

A 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 an achievable 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 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 more than four words are proposed for a name, there is usually a shorter and more specific name that could be used.

Version

Often a version section is needed to inform the reader of 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

A summary section is used to capture the essence of a 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.

Actors

An actor is someone or something outside the system that either acts on the system – a primary actor – or is acted on by the system – a secondary actor. An actor may be a person, a device, another system or sub-system, or time. Actors represent the different roles that something outside has in its relationship with the system whose functional requirements are being specified. An individual in the real world can be represented by several actors if they have several different roles and goals in regards to a system. ddgdgdgfg

Preconditions

A preconditions section defines all the conditions that must be true (i.e., describes the state of the system) for the trigger (see below) to meaningfully cause the initiation of the use case. That is, if the system is not in the state described in the preconditions, the behavior of the use case is indeterminate.

Note that the preconditions are not the same thing as the "trigger" (see below): the mere fact that the preconditions are met does NOT initiate the use case.

However, it is theoretically possible both that a use case should be initiated whenever condition X is met and that condition X is the only aspect of the system that defines whether the use case can meaningfully start. If this is really true, then condition X is both the precondition and the trigger, and would appear in both sections. But this is rare, and the analyst should check carefully that they have not overlooked some preconditions which are not part of the trigger. If the analyst has erred, the module based on this use case will be triggered when the system is in a state the developer has not planned for, and the module may fail or behave unpredictably.

Triggers

A triggers section describes the event that causes the use case to be initiated. This event can be external, temporal or internal. If the trigger is not a simple true "event" (e.g., the customer presses a button), but instead "when a set of conditions are met", there will need to be a triggering process that continually (or periodically) runs to test whether the "trigger conditions" are met: the "triggering event" is a signal from the trigger process that the conditions are now met.

There is varying practice over how to describe what to do when the trigger occurs but the preconditions are not met.

• One way is to handle the "error" within the use case (as an exception). Strictly, this is illogical, because the "preconditions" are now not true preconditions at all (because the behaviour of the use case is determined even when the preconditions are not met).
• Another way is to put all the preconditions in the trigger (so that the use case does not run if the preconditions are not met) and create a different use case to handle the problem. Note that if this is the local standard, then the use case template theoretically does not need a preconditions section!

Basic course of events

At a minimum, each use case should convey a primary scenario, or typical course of events, also called "basic flow" or "happy flow". 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 log on.
2. The user enters his name and password.
3. The system verifies the logon 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 of their own. 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 user's machine.
2. Go to step 4 (Main path)

An example of an exception path would be:

3. The system does not recognize user's logon information

4. Go to step 1 (Main path)

According to Anthony J H Simons and Ian Graham, alternate paths were not originally part of use cases. Instead, each use case represented a single user's interaction with the system. In other words, each use case represented one possible path through the system. Multiple use cases would be needed before designs based on them could be made. In this sense, use cases are for exploration, not documentation.

Postconditions

The post-conditions section describes what the change in state of the system will be after the use case completes. Post-conditions are guaranteed to be true when the use case ends.

Business rules

Business rules are written (or unwritten) rules or policies that determine how an organization conducts its business with regard to a use case. Business rules are a special kind of requirement. Business rules may be specific to a use case or apply across all the use cases, or across the entire business. Use cases should clearly reference BRs that are applicable and where they are implemented. Business rules describe the operations, definitions and constraints that apply to an organization in achieving its goals. ...

Notes

Experience has shown that however well-designed a use case template is, the analyst will have some important information that does not fit under a specific heading. Therefore all good templates include a section (eg "Notes to Developers") that allows less-structured information to be recorded.

Author and date

This section should list when a 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 case notation

In Unified Modeling Language, the relationships between all (or a set of) the use cases and actors are represented in a use case diagram or diagrams, originally based upon Ivar Jacobson's Objectory notation. SysML, a UML profile, uses the same notation at the system block level. In the field of software engineering, the Unified Modeling Language (UML) is a standardized specification language for object modeling. ... A use case diagram is a type of behavioral diagram defined by the Unified Modeling Language (UML). ... Ivar Hjalmar Jacobson (born in Ystad, Sweden, on September 2, 1939) is a Swedish computer scientist. ... Objectory is an object-oriented methodology mostly created by Ivar Jacobson, who is also responsible for object-oriented software engineering. ... SysML, or Systems Modeling Language, is a general-purpose systems engineering modeling language. ...

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, 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. Use case survey is a list of names and perhaps brief descriptions of use cases associated with a system, component, or other logical or physical entity. ...

Benefits of use cases

Use cases are a mature model to capture functional requirements before construction of a new system begins. Proponents prefer them to large, monolithic documents which they believe cannot be simultaneously complete and meaningful, and regard them as an excellent technique for capturing the functional requirements of a system. Proponents cite these advantages:

• Use cases have proven to be easily understandable by business users, and thus to act as a bridge between them and software developers.
  • Use cases put requirements in context, describing them in clear relationship to business tasks.
  • Use case diagrams help stakeholders understand the nature and scope of the business area or the system under development.
  • Use cases do not need to be specified in a special language. They can be written in any style that suits the needs of the project.
  • Use cases are easily translated into scenarios ("stories"), which express the analyst's understanding of the business needs in a way that the business user can understand on their own terms.
  • Use cases prompt the consideration and discussion of alternative paths, thus capturing less frequent behaviour and so improving system robustness.
• Uniquely identified use cases can be traced back to business requirements or stakeholder needs.
• Use cases organise and structure the requirements model, permitting common behaviour to be factored out.
• Use cases can serve as a basis for the estimating, scheduling, and validating efforts.
• Use cases are reusable within a project. A use case can evolve at each iteration, from a method of capturing requirements, to development guidelines for programmers, to a test case and finally into user documentation.
• 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 that represent interactions between a user and a system (others will represent interactions between systems) make it possible for user interface designers to become involved in the development process before, or in parallel with, software developers (although use cases are also said to discourage inappropriate premature design).
• Use cases and use case diagrams recorded using UML can be maintained with widely available CASE tools, and thus be fully integrated with other analysis and design deliverables created using a CASE tool. The result is a complete requirements, design, and implementation repository.
• Test cases (system, user acceptance and functional) can be directly derived from use cases (see also limitations with respect to test cases).
• Use cases are critical for the effective execution of Performance Engineering.

This article is about the term in software engineering. ... Performance engineering is the set of roles, skills, activities, practices, tools, and deliverables applied at every phase of the Systems Development Lifecycle which ensures that a solution will be designed and implemented to meet the non-functional requirements defined for the solution. ...

Limitations of use cases

Use cases have limitations:

• Use case flows are not well suited to easily capturing non-interaction based requirements of a system (such as algorithm or mathematical requirements) or non-functional requirements (such as platform, performance, timing, or safety-critical aspects). These are better specified declaratively elsewhere.
• Use cases templates do not automatically ensure clarity. Clarity depends on the skill of the writer(s).
• There is a learning curve involved in interpreting use cases correctly, for both end users and developers. As there are no fully standard definitions of use cases, each group must gradually evolve its own interpretation. Some of the relations, such as extends, are ambiguous in interpretation and can be difficult for stakeholders to understand.
• Proponents of Extreme Programming often consider use cases too needlessly document-centric, preferring to use the simpler approach of a user story.
• Use case developers often find it difficult to determine the level of user interface (UI) dependency to incorporate in a use case. While use case theory suggests that UI not be reflected in use cases, it can be awkward to abstract out this aspect of design, as it makes the use cases difficult to visualize.
• Use cases can be over-emphasized. In Object Oriented Software Construction (2nd edition), Bertrand Meyer discusses issues such as driving the system design too literally from use cases and using use cases to the exclusion of other potentially valuable requirements analysis techniques.
• Use cases have received some interest as a starting point for test design.^[6] Some use case literature, however, states that use case pre and postconditions should apply to all scenarios of a use case (i.e., to all possible paths through a use case) which is limiting from a test design standpoint. If the postconditions of a use case are so general as to be valid for all possible use case scenarios, they are likely not to be useful as a basis for specifying expected behavior in test design. For example, the outputs and final state of a failed attempt to withdraw cash from an ATM are not the same as a successful withdrawal: if the postconditions reflect this, they too will differ; if the postconditions don’t reflect this, then they can’t be used to specify the expected behavior of tests. An alternate perspective on use case pre & postconditions more suitable for test design based on model-based specification is discussed in ^[7]

Extreme Programming (or XP) is a software engineering methodology, the most prominent of several agile software development methodologies, prescribing a set of daily stakeholder practices that embody and encourage particular XP values (below). ... A user story is a software system requirement formulated as one or two sentences in the everyday language of the user. ... The user interface is the part of a system exposed to users. ...

Software

• See the list of UML tools.

This article lists Unified Modeling Language tools, classified by their proprietary or non-proprietary status. ...

References

Pearson can mean Pearson PLC the media conglomerate. ... Pearson can mean Pearson PLC the media conglomerate. ...

See also

• Business case
• User story

A business case is a structured proposal for business change that is justified in terms of costs and benefits. ... A user story is a software system requirement formulated as one or two sentences in the everyday language of the user. ...

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.
• Use Case Tutorials An introduction to use cases and use case-driven development.
• Use Cases (Usability.gov)
• Basic Use Case Template by Alistair Cockburn
• Alistair Cockburn's Website
• Getting Started With Use Cases
• "Why Use Cases are unable to align IT systems to changing requirements ?"