In both software and systems engineering, a use case is a structured description of a system’s behavior as it responds to requests from external actors, aiming to achieve a specific goal. The term is also used outside software/systems engineering to describe how something can be used.
In software (and software-based systems) engineering, it is used to define and validate functional requirements. A use case is a list of actions or event steps typically defining the interactions between a role (known in the Unified Modeling Language (UML) as an actor) and a system to achieve a goal. The actor can be a human or another external system. In 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 the Systems Modeling Language (SysML) or as contractual statements.
Differences between systems and software engineering use cases In software engineering, the use case defines potential scenarios of the software in response to an external request (such as user input). In systems engineering, a use case models high-level functional behavior across technical and human components.
Definition
In software and systems engineering, the phrase use case is a polyseme with two senses: A usage scenario for a piece of software; often used in the plural to suggest situations where a piece of software may be useful. A potential scenario in which a system receives an external request (such as user input) and responds to it. This article discusses the latter sense.
History
In 1987, Ivar Jacobson presented the first article on use cases at the OOPSLA'87 conference. He described how this technique was used at Ericsson to capture and specify requirements of a system using textual, structural, and visual modeling techniques to drive object-oriented analysis and design. Originally he had used the terms usage scenarios and usage case – the latter a direct translation of his Swedish term användningsfall – but found that neither of these terms sounded natural in English, and eventually he settled on use case.
In 1992 he co-authored the book Object-Oriented Software Engineering – A Use Case Driven Approach, which laid the foundation of the OOSE system engineering method and helped to popularize use cases for capturing functional requirements, especially in software development. In 1994 he published a book about use cases and object-oriented techniques applied to business models and business process reengineering.
At the same time, Grady Booch and James Rumbaugh worked at unifying their object-oriented analysis and design methods, the Booch method and Object Modeling Technique (OMT) respectively. In 1995 Ivar Jacobson joined them and together they created the Unified Modelling Language (UML), which includes use case modeling. UML was standardized by the Object Management Group (OMG) in 1997. Jacobson, Booch and Rumbaugh also worked on a refinement of the Objectory software development process. The resulting Unified Process was published in 1999 and promoted a use case driven approach.
Since then, many authors have contributed to the development of the technique, notably: Larry Constantine developed in 1995, in the context of usage-centered design, so called "essential use-cases" that aim to describe user intents rather than sequences of actions or scenarios which might constrain or bias the design of user interface; Alistair Cockburn published in 2000 a goal-oriented use case practice based on text narratives and tabular specifications; Kurt Bittner and Ian Spence developed in 2002 advanced practices for analyzing functional requirements with use cases; Dean Leffingwell and Don Widrig proposed to apply use cases to change management and stakeholder communication activities; Gunnar Overgaard proposed in 2004 to extend the principles of design patterns to use cases.
In 2011, Jacobson published with Ian Spence and Kurt Bittner the ebook Use Case 2.0 to adapt the technique to an agile context, enriching it with incremental use case "slices", and promoting its use across the full development lifecycle after having presented the renewed approach at the annual IIBA conference.
General principle Use cases are a technique for capturing, modeling, and specifying the requirements of a system. A use case corresponds to a set of behaviors that the system may perform in interaction with its actors, and which produces an observable result that contributes to its goals. Actors represent the role that human users or other systems have in the interaction.
In the requirement analysis, at their identification, a use case is named according to the specific user goal that it represents for its primary actor. The case is further detailed with a textual description or with additional graphical models that explain the general sequence of activities and events, as well as variants such as special conditions, exceptions, or error situations.
According to the Software Engineering Body of Knowledge (SWEBOK), use cases belong to the scenario-based requirement elicitation techniques, as well as the model-based analysis, techniques. But the use cases also support narrative-based requirement gathering, incremental requirement acquisition, system documentation, and acceptance testing.
Variations There are different kinds of use cases and variations in the technique:
System use cases specify the requirements of a system to be developed. They identify in their detailed description not only the interactions with the actors but also the entities that are involved in the processing. They are the starting point for further analysis models and design activities. Business use cases focus on a business organization instead of a software system. They are used to specify business models and business process requirements in the context of business process reengineering initiatives. Essential use cases, also called abstract use cases, describe the potential intents of the actors and how the system addresses these, without defining any sequence or describing a scenario. This practice was developed with the aim of supporting the user-centric design and avoiding to induce bias about the user interface in the early stage of the system specifications. Use Case 2.0 to adapt the technique for the context of agile development methods. This technique enriches the requirement-gathering practice with support for user-story narratives. It also provides use case "slices" to facilitate incremental elicitation of requirements and enable incremental implementation.
Scope The scope of a use case can be defined by a subject and by goals:
The subject identifies the system, sub-system, or component that will provide the interactions. The goals can be structured hierarchically, taking into account the organizational level interested in the goal (e.g. company, department, user), and the decomposition of the user's goal into sub-goals. The decomposition of the goal is performed from the point of view of the users, and independently of the system, which differs from traditional functional decomposition.
Usage Use cases are known to be applied in the following contexts:
Object Oriented Software Engineering (OOSE), as driving element; Unified Modeling Language (UML), as a behavioral modelling instrument; Unified Software Development Process (UP) and its fore-runner, the IBM Rational Unified Process (RUP); up-front documentation of software requirements specification (SRS), as an alternative structure for the functional requirements; deriving the design from the requirements using the entity–control–boundary approach; and agile development.
Templates
There are many ways to write a use case in the text, from use case brief, casual, outline, to fully dressed etc., and with varied templates. Writing use cases in templates devised by various vendors or experts is a common industry practice to get high-quality functional system requirements.
Cockburn style
The template defined by Alistair Cockburn in his book Writing Effective Use Cases has been one of the most widely used writing styles of use cases.
Design scopes
Cockburn suggests annotating each use case with a symbol to show the "Design Scope", which may be black-box (internal detail is hidden) or white box (internal detail is shown). Five symbols are available:Cockburn, 2001. Inside front cover. Icons "Design Scope".
Scope Icon Symbol Organization (black-box) Filled House Organization (white-box) Unfilled House System (black-box) Filled Box System (white-box) Unfilled Box Component Screw or Bolt
Other authors sometimes call use cases at the Organization level "Business use cases".Suzanne Robertson. Scenarios in Requirements Discovery. Chapter 3 in Alexander and Maiden, 2004, pp. 39–59.
Goal levels
Cockburn suggests annotating each use case with a symbol to show the "Goal Level";Cockburn, 2001. Inside front cover. Icons "Goal Level". the preferred level is "User-goal" (or colloquially "sea level").
Goal Level Icon Text Symbol Symbol Very High Summary Cloud ++ Summary Flying Kite + User Goal Waves at Sea ! Subfunction Fish - Too Low Seabed Clam-Shell --
Sometimes in text writing, a use case name followed by an alternative text symbol (! +, -, etc.) is a more concise and convenient way to denote levels, e.g. place an order!, login-.
Fully dressed
Cockburn describes a more detailed structure for a use case but permits it to be simplified when less detail is needed. His fully dressed use case template lists the following fields:Cockburn, 2001, p. 120.
Title: "an active-verb goal phrase that names the goal of the primary actor"Cockburn, 2001. Inside rear cover. Field "Use Case Title". Primary Actor Goal in Context Scope Level Stakeholders and Interests Precondition Minimal Guarantees Success Guarantees Trigger Main Success Scenario Extensions Technology & Data Variations List
In addition, Cockburn suggests using two devices to indicate the nature of each use case: icons for design scope and goal level.
Cockburn's approach has influenced other authors; for example, Alexander and Beus-Dukic generalize Cockburn's "Fully dressed use case" template from software to systems of all kinds, with the following fields differing from Cockburn:Alexander and Beus-Dukic, 2009, p. 121.
Variation scenarios "(maybe branching off from and maybe returning to the main scenario)" Exceptions "i.e. exception events and their exception-handling scenarios"
Casual
Cockburn recognizes that projects may not always need detailed "fully dressed" use cases. He describes a Casual use case with the fields:
Title (goal) Primary Actor Scope Level (Story): the body of the use case is simply a paragraph or two of text, informally describing what happens.
Fowler style
Martin Fowler states "There is no standard way to write the content of a use case, and different formats work well in different cases."Fowler, 2004. He describes "a common style to use" as follows: Title: "goal the use case is trying to satisfy" Main Success Scenario: numbered list of steps Step: "a simple statement of the interaction between the actor and a system" Extensions: separately numbered lists, one per Extension Extension: "a condition that results in different interactions from .. the main success scenario". An extension from main step 3 is numbered 3a, etc.
The Fowler style can also be viewed as a simplified variant of the Cockburn template. This variant is called a user story.
Alistair Cockburn stated:
Martin Fowler stated:
Actors