Use Cases
   HOME

TheInfoList



OR:

In
software Software is a set of computer programs and associated documentation and data. This is in contrast to hardware, from which the system is built and which actually performs the work. At the lowest programming level, executable code consists ...
and
systems engineering Systems engineering is an interdisciplinary field of engineering and engineering management that focuses on how to design, integrate, and manage complex systems over their enterprise life cycle, life cycles. At its core, systems engineering util ...
, the phrase use case is a
polyseme Polysemy ( or ; ) is the capacity for a sign (e.g. a symbol, a morpheme, a word, or a phrase) to have multiple related meanings. For example, a word can have several word senses. Polysemy is distinct from ''monosemy'', where a word has a single ...
with two
senses A sense is a biological system used by an organism for sensation, the process of gathering information about the world through the detection of stimuli. (For example, in the human body, the brain which is part of the central nervous system rec ...
: # 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. A ''use case'' is a list of actions or event steps typically defining the interactions between a role (known in the
Unified Modeling Language The Unified Modeling Language (UML) is a general-purpose, developmental modeling language in the field of software engineering that is intended to provide a standard way to visualize the design of a system. The creation of UML was originally m ...
(UML) as an ''
actor An actor or actress is a person who portrays a character in a performance. The actor performs "in the flesh" in the traditional medium of the theatre or in modern media such as film, radio, and television. The analogous Greek term is (), li ...
'') 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 Software engineering is a systematic engineering approach to software development. A software engineer is a person who applies the principles of software engineering to design, develop, maintain, test, and evaluate computer software. The term '' ...
, often representing missions or stakeholder goals. The detailed requirements may then be captured in the
Systems Modeling Language The Systems Modeling Language (SysML) is a general-purpose modeling language for systems engineering applications. It supports the specification, analysis, design, verification and validation of a broad range of systems and systems-of-systems. ...
(SysML) or as contractual statements.


History

In 1987,
Ivar Jacobson Ivar Hjalmar Jacobson (born 1939) is a Swedish computer scientist and software engineer, known as major contributor to UML, Objectory, Rational Unified Process (RUP), aspect-oriented software development and Essence. Biography Ivar Jacobson w ...
presented the first article on use cases at the
OOPSLA OOPSLA (Object-Oriented Programming, Systems, Languages & Applications) is an annual ACM research conference. OOPSLA mainly takes place in the United States, while the sister conference of OOPSLA, ECOOP, is typically held in Europe. It is opera ...
'87 conference. He described how this technique was used at
Ericsson (lit. "Telephone Stock Company of LM Ericsson"), commonly known as Ericsson, is a Swedish multinational networking and telecommunications company headquartered in Stockholm. The company sells infrastructure, software, and services in informat ...
to capture and specify requirements of a system using textual, structural, and
visual modeling Visual modeling is the graphic representation of objects and systems of interest using graphical languages. Visual modeling is a way for experts and novices to have a common understanding of otherwise complicated ideas. By using visual models com ...
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 Object-oriented programming (OOP) is a programming paradigm based on the concept of "objects", which can contain data and code. The data is in the form of fields (often known as attributes or ''properties''), and the code is in the form of pr ...
system engineering method and helped to popularize use cases for capturing
functional requirements In software engineering and systems engineering, a functional requirement defines a function of a system or its component, where a function is described as a specification of behavior between inputs and outputs. Functional requirements may invol ...
, especially in
software development Software development is the process of conceiving, specifying, designing, programming, documenting, testing, and bug fixing involved in creating and maintaining applications, frameworks, or other software components. Software development invol ...
. In 1994 he published a book about use cases and object-oriented techniques applied to
business model A business model describes how an organization creates, delivers, and captures value,''Business Model Generation'', Alexander Osterwalder, Yves Pigneur, Alan Smith, and 470 practitioners from 45 countries, self-published, 2010 in economic, social, ...
s and
business process reengineering Business process re-engineering (BPR) is a business management strategy originally pioneered in the early 1990s, focusing on the analysis and design of workflows and business processes within an organization. BPR aims to help organizations fundam ...
. At the same time,
Grady Booch Grady Booch (born February 27, 1955) is an American software engineer, best known for developing the Unified Modeling Language (UML) with Ivar Jacobson and James Rumbaugh. He is recognized internationally for his innovative work in software archit ...
and
James Rumbaugh James E. Rumbaugh (born August 22, 1947) is an American computer scientist and object-oriented methodologistobject-oriented analysis and design Object-oriented analysis and design (OOAD) is a technical approach for analyzing and designing an application, system, or business by applying object-oriented programming, as well as using visual modeling throughout the software development proces ...
methods, the
Booch method The Booch method is a method for object-oriented software development. It is composed of an object modeling language, an iterative object-oriented development process, and a set of recommended practices. The method was authored by Grady Booch wh ...
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 Objectory is an object-oriented methodology mostly created by Ivar Jacobson, who has greatly contributed to object-oriented software engineering Object-oriented programming (OOP) is a programming paradigm based on the concept of "objects", wh ...
software development process. The resulting
Unified Process The Unified Software Development Process or Unified Process is an iterative and incremental software development process framework. The best-known and extensively documented refinement of the Unified Process is the Rational Unified Process (RU ...
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 Larry LeRoy Constantine (born 1943) is an American software engineer, professor in the Center for Exact Sciences and Engineering at the University of Madeira Portugal, and considered one of the pioneers of computing. He has contributed numerous c ...
developed in 1995, in the context of
usage-centered design Usage-centered design is an approach to user interface design based on a focus on user intentions and usage patterns. It analyzes users in terms of the roles they play in relation to systems and employs abstract (essential) use cases for task a ...
, 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 Alistair Cockburn ( ) is an American computer scientist, known as one of the initiators of the agile movement in software development. He cosigned (with 17 others) the Manifesto for Agile Software Development. Life and career Cockburn starte ...
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 In systems engineering and software engineering, requirements analysis focuses on the tasks that determine the needs or conditions to meet the new or altered product or project, taking account of the possibly conflicting requirements of the ...
, 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, Object Oriented Software Engineering (OOSE), as driving element; *
Unified Modeling Language The Unified Modeling Language (UML) is a general-purpose, developmental modeling language in the field of software engineering that is intended to provide a standard way to visualize the design of a system. The creation of UML was originally m ...
(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 The entity-control-boundary (ECB), or entity-boundary-control (EBC), or boundary-control-entity (BCE) is an architectural pattern used in use-case driven object-oriented software design that structures the classes composing a software according ...
approach; * and
agile development In software development, agile (sometimes written Agile) practices include requirements discovery and solutions improvement through the collaborative effort of self-organizing and cross-functional teams with their customer(s)/ end user(s), ad ...
.


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 Alistair Cockburn ( ) is an American computer scientist, known as one of the initiators of the agile movement in software development. He cosigned (with 17 others) the Manifesto for Agile Software Development. Life and career Cockburn starte ...
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: Other authors sometimes call use cases at the Organization level "Business use cases".


Goal levels

Cockburn suggests annotating each use case with a symbol to show the "Goal Level"; the preferred level is "User-goal" (or colloquially "sea level"). 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. Page 120. * Title: "an active-verb goal phrase that names the goal of the primary actor" * 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: * 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 In software development and product management, a user story is an informal, natural language description of features of a software system. They are written from the perspective of an end user or user of a system, and may be recorded on index ...
. Alistair Cockburn stated: Martin Fowler stated:


Actors

A use case defines the interactions between external actors and the system under consideration to accomplish a goal. Actors must be able to make decisions, but need not be human: "An actor might be a person, a company or organization, a computer program, or a computer system—hardware, software, or both."Cockburn, 2001. Page 53. Actors are always stakeholders, but not all stakeholders are actors, since they may "never interact directly with the system, even though they have the right to care how the system behaves." For example, "the owners of the system, the company's board of directors, and regulatory bodies such as the Internal Revenue Service and the Department of Insurance" could all be stakeholders but are unlikely to be actors. Similarly, a person using a system may be represented as a different actor because of playing different roles. For example, user "Joe" could be playing the role of a Customer when using an Automated Teller Machine to withdraw cash from his own account or playing the role of a Bank Teller when using the system to restock the cash drawer on behalf of the bank. Actors are often working on behalf of someone else. Cockburn writes that "These days I write 'sales rep for the customer' or 'clerk for the marketing department' to capture that the user of the system is acting for someone else." This tells the project that the "user interface and security clearances" should be designed for the sales rep and clerk, but that the customer and marketing department are the roles concerned about the results.Cockburn, 2001. Page 55. A stakeholder may play both an active and an inactive role: for example, a Consumer is both a "mass-market purchaser" (not interacting with the system) and a User (an actor, actively interacting with the purchased product).Alexander and Beus-Dukic, 2009. Page 39. In turn, a User is both a "normal operator" (an actor using the system for its intended purpose) and a "functional beneficiary" (a stakeholder who benefits from the use of the system). For example, when user "Joe" withdraws cash from his account, he is operating the Automated Teller Machine and obtaining a result on his own behalf. Cockburn advises looking for actors among the stakeholders of a system, the primary and supporting (secondary) actors of a use case, the system under design (SuD) itself, and finally among the "internal actors", namely the components of the system under design.


Business use case

In the same way that a use case describes a series of events and interactions between a user (or other types of Actor) and a system, in order to produce a result of value (goal), a business use case describes the more general interaction between a business system and the users/actors of that system to produce business results of value. The primary difference is that the system considered in a business use case model may contain people in addition to technological systems. These "people in the system" are called business workers. In the example of a restaurant, a decision must be made whether to treat each person as an actor (thus outside the system) or a business worker (inside the system). If a waiter is considered an actor, as shown in the example below, then the restaurant system does not include the waiter, and the model exposes the interaction between the waiter and the restaurant. An alternative would be to consider the waiter as a part of the restaurant system (a business worker) while considering the client to be outside the system (an actor).


Visual modeling

Use cases are not only texts but also diagrams if needed. In the
Unified Modeling Language The Unified Modeling Language (UML) is a general-purpose, developmental modeling language in the field of software engineering that is intended to provide a standard way to visualize the design of a system. The creation of UML was originally m ...
, the relationships between use cases and actors are represented in
use case diagram A use case diagram is a graphical depiction of a user's possible interactions with a system. A use case diagram shows various use cases and different types of users the system has and will often be accompanied by other types of diagrams as well. Th ...
s originally based upon
Ivar Jacobson Ivar Hjalmar Jacobson (born 1939) is a Swedish computer scientist and software engineer, known as major contributor to UML, Objectory, Rational Unified Process (RUP), aspect-oriented software development and Essence. Biography Ivar Jacobson w ...
's
Objectory Objectory is an object-oriented methodology mostly created by Ivar Jacobson, who has greatly contributed to object-oriented software engineering Object-oriented programming (OOP) is a programming paradigm based on the concept of "objects", wh ...
notation.
SysML The Systems Modeling Language (SysML) is a general-purpose modeling language for systems engineering applications. It supports the specification, analysis, design, verification and validation of a broad range of systems and systems-of-systems. S ...
uses the same notation at a system block level. In addition, other behavioral UML diagrams such as
activity diagram Activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice, iteration and concurrency. In the Unified Modeling Language, activity diagrams are intended to model both computational and o ...
s,
sequence diagram A sequence diagram or system sequence diagram (SSD) shows process interactions arranged in time sequence in the field of software engineering. It depicts the processes involved and the sequence of messages exchanged between the processes needed ...
s,
communication diagram A communication diagram in the Unified Modeling Language (UML) 2.0, is a simplified version of the UML 1.x collaboration diagram. UML has four types of interaction diagrams: * Sequence diagram * Communication diagram * Interaction overview di ...
s, and state machine diagrams can also be used to visualize use cases accordingly. Specifically, a
System Sequence Diagram A system is a group of interacting or interrelated elements that act according to a set of rules to form a unified whole. A system, surrounded and influenced by its environment, is described by its boundaries, structure and purpose and expressed ...
(SSD) is a sequence diagram often used to show the interactions between the external actors and the system under design (SuD), usually for visualizing a particular scenario of a use case. Use case analysis usually starts by drawing use case diagrams. For agile development, a requirement model of many UML diagrams depicting use cases plus some textual descriptions, notes, or ''use case briefs'' would be very lightweight and just enough for small or easy project use. As good complements to use case texts, the visual diagram representations of use cases are also effective facilitating tools for the better understanding, communication, and design of complex system behavioral requirements.


Examples

Below is a sample use case written with a slightly modified version of the Cockburn-style template. Note that there are no buttons, controls, forms, or any other UI elements and operations in the basic use case description, where only user goals, subgoals, or intentions are expressed in every step of the basic flow or extensions. This practice makes the requirement specification clearer and maximizes the flexibility of the design and implementation. Use Case: Edit an article Primary Actor: Member ''(Registered User)'' Scope: a
Wiki A wiki ( ) is an online hypertext publication collaboratively edited and managed by its own audience, using a web browser. A typical wiki contains multiple pages for the subjects or scope of the project, and could be either open to the pu ...
system Level: ! ''(User goal or sea level)'' Brief: ''(equivalent to a
user story In software development and product management, a user story is an informal, natural language description of features of a software system. They are written from the perspective of an end user or user of a system, and may be recorded on index ...
or an epic)'' : The member edits any part (the entire article or just a section) of an article they are reading. Preview and changes comparison are allowed during the editing. Stakeholders ... Postconditions : Minimal Guarantees: : Success Guarantees: :* The article is saved and an updated view is shown. :* An edit record for the article is created by the system, so watchers of the article can be informed of the update later. Preconditions: : The article with editing enabled is presented to the member. Triggers: : The member invokes an edit request (for the full article or just one section) on the article. Basic flow: # The system provides a new editor area/box filled with all the article's relevant content with an informative edit summary for the member to edit. If the member just wants to edit a section of the report, only the original content of the section is shown, with the section title automatically filled out in the edit summary. # The member modifies the article's content until the member is satisfied. # The member fills out the edit summary, tells the system if they want to watch this article, and submits the edit. # The system saves the article, logs the edit event, and finishes any necessary post-processing. # The system presents the updated view of the article to the member. Extensions: 2–3. : a. Show preview: :# The member selects ''Show preview'' which submits the modified content. :# The system reruns step 1 with the addition of the rendered updated content for preview, and informs the member that his/her edits have not been saved yet, then continues. : b. Show changes: :# The member selects ''Show changes'' which submits the modified content. :# The system reruns step 1 with the addition of showing the results of comparing the differences between the current edits by the member and the most recent saved version of the article, then continues. : c. Cancel the edit: :# The member selects ''Cancel''. :# The system discards any change the member has made, then goes to step 5. 4a. Timeout: ...


Advantages

Since the inception of the agile movement, the
user story In software development and product management, a user story is an informal, natural language description of features of a software system. They are written from the perspective of an end user or user of a system, and may be recorded on index ...
technique from
Extreme Programming Extreme programming (XP) is a software development methodology intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development,"Human Centred Technology Workshop 2006 ", 2006, PD ...
has been so popular that many think it is the only and best solution for the agile requirements of all projects.
Alistair Cockburn Alistair Cockburn ( ) is an American computer scientist, known as one of the initiators of the agile movement in software development. He cosigned (with 17 others) the Manifesto for Agile Software Development. Life and career Cockburn starte ...
lists five reasons why he still writes use cases in
agile development In software development, agile (sometimes written Agile) practices include requirements discovery and solutions improvement through the collaborative effort of self-organizing and cross-functional teams with their customer(s)/ end user(s), ad ...
. # The list of goal names provides the ''shortest'' summary of what the system will offer (even then user stories). It also provides a project planning skeleton, to be used to build initial priorities, estimates, team allocation, and timing. # The main success scenario of each use case provides everyone involved with an agreement as to what the system will basically do and what it will not do. It provides the context for each specific line item requirement (e.g. fine-grained user stories), a context that is very hard to get anywhere else. # The extension conditions of each use case provide a framework for investigating all the little, niggling things that somehow take up 80% of the development time and budget. It provides a look-ahead mechanism, so the stakeholders can spot issues likely to take a long time to get answers for. These issues can and should then be put ahead of the schedule so that the answers can be ready when the development team gets around to working on them. # The use case extension scenario fragments provide answers to the many detailed, often tricky, and ignored business questions: "What are we supposed to do in this case?" It is a thinking/documentation framework that matches the if...then...else statement that helps the programmers think through issues. Except it is done at investigation time, not programming time. # The full use case set shows that the investigators have thought through every user's needs, every goal they have with respect to the system, and every business variant involved. In summary, specifying system requirements in use cases have these apparent benefits compared with traditional or other approaches: User focused Use cases constitute a powerful, user-centric tool for the software requirements specification process. Use case modeling typically starts from identifying key stakeholder roles (''actors'') interacting with the system, and their goals or objectives the system must fulfill (an outside perspective). These user goals then become the ideal candidates for the names or titles of the use cases which represent the desired functional features or services provided by the system. This user-centered approach ensures that what has real business value and the user really want is developed, not those trivial functions speculated from a developer or system (inside) perspective. Use case authoring has been an important and valuable analysis tool in the domain of User-Centered Design (UCD) for years. Better communication Use cases are often written in natural languages with structured templates. This narrative textual form (legible requirement stories), understandable by almost everyone, and complemented by visual UML diagrams fosters better and deeper communications among all stakeholders, including customers, end-users, developers, testers, and managers. Better communications result in quality requirements and thus quality systems delivered. Quality requirements by structured exploration One of the most powerful things about use cases resides in the formats of the use case
templates Template may refer to: Tools * Die (manufacturing), used to cut or shape material * Mold, in a molding process * Stencil, a pattern or overlay used in graphic arts (drawing, painting, etc.) and sewing to replicate letters, shapes or designs Co ...
, especially the main success scenario (basic flow) and the extension scenario fragments (extensions, exceptional and alternative flows). Analyzing a use case step by step from preconditions to postconditions, exploring and investigating every action step of the use case flows, from basic to extensions, to identify those tricky, normally hidden and ignored, seemingly trivial but realistically often costly requirements (as Cockburn mentioned above), is a structured and beneficial way to get clear, stable and quality requirements systematically. Minimizing and optimizing the action steps of a use case to achieve the user goal also contribute to a better
interaction design Interaction design, often abbreviated as IxD, is "the practice of designing interactive digital products, environments, systems, and services." Beyond the digital aspect, interaction design is also useful when creating physical (non-digital) produ ...
and user experience of the system. Facilitate testing and user documentation With content based upon an action or event flow structure, a model of well-written use cases also serves as excellent groundwork and valuable guidelines for the design of test cases and user manuals of the system or product, which is an effort-worthy investment up-front. There are obvious connections between the flow paths of a use case and its test cases. Deriving functional test cases from a use case through its scenarios (running instances of a use case) is straightforward.


Limitations

Limitations of use cases include: * Use cases are not well suited to capturing non-interaction-based requirements of a system (such as algorithm or mathematical requirements) or
non-functional requirements In systems engineering and requirements engineering, a non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours. They are contrasted with functi ...
(such as platform, performance, timing, or safety-critical aspects). These are better specified declaratively elsewhere. * As there are no fully standard definitions of use cases, each project must form its own interpretation. * Some use case relationships, such as ''extends'', are ambiguous in interpretation and can be difficult for stakeholders to understand as pointed out by Cockburn (Problem #6) * Use case developers often find it difficult to determine the level of
user interface In the industrial design field of human–computer interaction, a user interface (UI) is the space where interactions between humans and machines occur. The goal of this interaction is to allow effective operation and control of the machine f ...
(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. In software engineering, this difficulty is resolved by applying
requirements traceability Requirements traceability is a sub-discipline of requirements management within software development and systems engineering. Traceability as a general term is defined by the IEEE Systems and Software Engineering Vocabulary as (1) the degree to whic ...
, for example with a
traceability matrix In software development, a traceability matrix (TM) is a document, usually in the form of a table, used to assist in determining the completeness of a relationship by correlating any two baselined documents using a many-to-many relationship com ...
. Another approach to associate UI elements with use cases is to attach a UI design to each step in the use case. This is called a use case storyboard. * Use cases can be over-emphasized.
Bertrand Meyer Bertrand Meyer (; ; born 21 November 1950) is a French academic, author, and consultant in the field of computer languages. He created the Eiffel programming language and the idea of design by contract. Education and academic career Meyer recei ...
discusses issues such as driving system design too literally from use cases, and using use cases to the exclusion of other potentially valuable requirements analysis techniques. * Use cases are a starting point for test design, but since each test needs its own success criteria, use cases may need to be modified to provide separate post-conditions for each path. * Though use cases include goals and contexts, whether these goals and motivations behind the goals (stakeholders' concerns and their assessments including non-interaction) conflict or negatively/positively affect other system goals are subject of goal-oriented requirement modeling techniques (such as BMM, I*,
KAOS KaOS is a desktop Linux distribution that features the latest version of the KDE desktop environment, the LibreOffice office suite, and other popular software applications that use the Qt toolkit. History The first version of KaOS was released ...
and
ArchiMate ArchiMate ( ; originally from Architecture-Animate) is an open and independent enterprise architecture modeling language to support the description, analysis and visualization of architecture within and across business domainsScrum Scrum may refer to: Sport * Scrum (rugby), a method of restarting play in rugby union and rugby league ** Scrum (rugby union), scrum in rugby union * Scrum, an offensive melee formation in Japanese game Bo-taoshi Media and popular culture * M ...
are neutral on requirement techniques. As the Scrum Primer states,
'' Product Backlog items are articulated in any way that is clear and sustainable. Contrary to popular misunderstanding, the Product Backlog does not contain "user stories"; it simply contains items. Those items can be expressed as user stories, use cases, or any other requirements approach that the group finds useful. But whatever the approach, most items should focus on delivering value to customers.''
Use case techniques have evolved to take Agile approaches into account by using use case slices to incrementally enrich a use case. Use cases are mainly diagrams.
Craig Larman Craig Larman (born 1958) is a Canadian computer scientist, author, and organizational development consultant. With Bas Vodde, he is best known for formulating LeSS (Large-Scale Scrum), and for several books on product and software development. E ...
stresses that "use cases are not diagrams, they are text". Use cases have too much UI-related content. As some put it,
'' Use cases will often contain a level of detail (i.e. naming of labels and buttons) which make it not well suited for capturing the requirements for a new system from scratch.''
Novice misunderstandings. Each step of a well-written use case should present ''actor'' goals or intentions (the essence of functional requirements), and normally it should not contain any user interface details, e.g. naming of labels and buttons, UI operations, etc., which is a ''bad'' practice and will unnecessarily complicate the use case writing and limit its implementation. As for capturing requirements for a new system from scratch, ''use case diagrams'' plus ''use case briefs'' are often used as handy and valuable tools, at least as lightweight as user stories. Writing use cases for large systems is tedious and a waste of time. As some put it,
'' The format of the use case makes it difficult to describe a large system (e.g. CRM system) in less than several hundred pages. It is time-consuming and you will find yourself spending time doing an unnecessary amount of rework.''
Spending much time writing tedious use cases which add no or little value and result in a lot of rework is a ''bad smell'' indicating that the writers are not well skilled and have little knowledge of how to write quality use cases both efficiently and effectively. Use cases should be authored in an iterative, incremental, and evolutionary (''agile'') way. Applying use case templates does not mean that all the fields of a use case template should be used and filled out comprehensively from up-front or during a special dedicated stage, i.e. the requirement phase in the traditional ''waterfall'' development model. In fact, the use case formats formulated by those popular template styles, e.g. the RUP's and the Cockburn's (also adopted by the OUM method), etc., have been proved in practice as valuable and helpful tools for capturing, analyzing and documenting complex requirements of large systems. The quality of a good use case documentation (''model'') should not be judged largely or only by its size. It is possible as well that a quality and comprehensive use case model of a large system may finally evolve into hundreds of pages mainly because of the inherent complexity of the ''problem'' in hand, not because of the poor writing skills of its authors.


Tools

Text editors and/or
word processor A word processor (WP) is a device or computer program that provides for input, editing, formatting, and output of text, often with some additional features. Word processor (electronic device), Early word processors were stand-alone devices ded ...
s with template support are often used to write use cases. For large and complex system requirements, dedicated use case tools are helpful. Some of the well-known use case tools include: * CaseComplete * Enterprise Architect *
MagicDraw MagicDraw is a proprietary visual UML, SysML, BPMN, and UPDM modeling tool with team collaboration support. Designed for business analysts, software analysts, programmers, and QA engineers, this dynamic and versatile development tool facilitat ...
*
Rational Software Rational Machines is an enterprise founded by Paul Levy and Mike Devlin in 1981 to provide tools to expand the use of modern software engineering practices, particularly explicit modular architecture and iterative development. It changed its ...
's RequisitePro - one of the early, well-known use case and requirement management tools in the 1990s. * Software Ideas Modeler *
Wiki software Wiki software (also known as a wiki engine or a wiki application), is collaborative software that runs a wiki, which allows the users to create and collaboratively edit pages or entries via a web browser. A wiki system is usually a web application ...
- good tools for teams to author and manage use cases collaboratively. Most
UML tools This article compares UML tools. UML tools are software applications which support some functions of the Unified Modeling Language. General Features See also * List of requirements engineering tools Requirements engineering tools ar ...
support both the text writing and visual modeling of use cases.


See also

* Abuse case *
Business case A business case captures the reasoning for initiating a project or task. It is often presented in a well-structured written document, but may also come in the form of a short verbal agreement or presentation. The logic of the business case is that, ...
*
Entity-control-boundary The entity-control-boundary (ECB), or entity-boundary-control (EBC), or boundary-control-entity (BCE) is an architectural pattern used in use-case driven object-oriented software design that structures the classes composing a software according ...
*
Event partitioning Event partitioning is an easy-to-apply systems analysis technique that helps the analyst organize requirements for large systems into a collection of smaller, simpler, minimally-connected, easier-to-understand "mini systems" / use cases. Overview ...
*
Feature Feature may refer to: Computing * Feature (CAD), could be a hole, pocket, or notch * Feature (computer vision), could be an edge, corner or blob * Feature (software design) is an intentional distinguishing characteristic of a software item ...
*
List of UML tools A ''list'' is any set of items in a row. List or lists may also refer to: People * List (surname) Organizations * List College, an undergraduate division of the Jewish Theological Seminary of America * SC Germania List, German rugby union ...
*
Misuse case Misuse case is a business process modeling tool used in the software development industry. The term ''Misuse Case'' or ''mis-use case'' is derived from and is the inverse of use case.Sindre and Opdahl (2001).Capturing Security Requirements throug ...
*
Requirement In product development and process optimization, a requirement is a singular documented physical or functional need that a particular design, product or process aims to satisfy. It is commonly used in a formal sense in engineering design, includi ...
*
Requirements elicitation In requirements engineering, requirements elicitation is the practice of researching and discovering the requirements of a system from users, customers, and other stakeholders. The practice is also sometimes referred to as "requirement gathering". ...
*
Scenario In the performing arts, a scenario (, ; ; ) is a synoptical collage of an event or series of actions and events. In the ''commedia dell'arte'', it was an outline of entrances, exits, and action describing the plot of a play, and was literally pi ...
*
Storyboard A storyboard is a graphic organizer that consists of illustrations or images displayed in sequence for the purpose of pre-visualizing a motion picture, animation, motion graphic or interactive media sequence. The storyboarding process, i ...
*
Test case In software engineering, a test case is a specification of the inputs, execution conditions, testing procedure, and expected results that define a single test to be executed to achieve a particular software testing objective, such as to exercise ...
* Use case points


References


Further reading

* Alexander, Ian, and Beus-Dukic, Ljerka. ''Discovering Requirements: How to Specify Products and Services''. Wiley, 2009. * Alexander, Ian, and Maiden, Neil. ''Scenarios, Stories, Use Cases''. Wiley 2004. * Armour, Frank, and Granville Miller. ''Advanced Use Case Modeling: Software Systems''. Addison-Wesley, 2000. * Kurt Bittner, Ian Spence, ''Use Case Modeling'', Addison-Wesley Professional, 20 August 2002. * Cockburn, Alistair. ''Writing Effective Use Cases.'' Addison-Wesley, 2001. * Larry Constantine, Lucy Lockwood, ''Software for Use: A Practical Guide to the Essential Models and Methods of Usage-Centered Design'', Addison-Wesley, 1999. * Denney, Richard. ''Succeeding with Use Cases: Working Smart to Deliver Quality''. Addison-Wesley, 2005. * Fowler, Martin. ''UML Distilled (Third Edition)''. Addison-Wesley, 2004. * Jacobson Ivar, Christerson M., Jonsson P., Övergaard G., ''Object-Oriented Software Engineering - A Use Case Driven Approach'', Addison-Wesley, 1992. * Jacobson Ivar, Spence I., Bittner K. ''Use Case 2.0: The Guide to Succeeding with Use Cases'', IJI SA, 2011. * Dean Leffingwell, Don Widrig, ''Managing Software Requirements: A Use Case Approach'', Addison-Wesley Professional. 7 December 2012. * Kulak, Daryl, and Eamonn Guiney. ''Use cases: requirements in context.'' Addison-Wesley, 2012. * Meyer, Bertrand. ''Object-Oriented Software Construction''. (2nd edition). Prentice Hall, 2000. * Schneider, Geri and Winters, Jason P. ''Applying Use Cases 2nd Edition: A Practical Guide''. Addison-Wesley, 2001. * Wazlawick, Raul S. ''Object-Oriented Analysis and Design for Information Systems: Modeling with UML, OCL, and IFML''. Morgan Kaufmann, 2014.


External links


Use case column
an
Basic Use Case Template
by
Alistair Cockburn Alistair Cockburn ( ) is an American computer scientist, known as one of the initiators of the agile movement in software development. He cosigned (with 17 others) the Manifesto for Agile Software Development. Life and career Cockburn starte ...

Use Cases
at GSA's Usability.gov
Application of use cases for stakeholder analysis "Project Icarus"
at
Academia.edu Academia.edu is a for-profit open repository of academic articles free to read by visitors. Uploading and downloading is restricted to registered users. Additional features are accessible only as a paid subscription. Since 2016 various social ...

Search for "use case"
at IBM Developer {{DEFAULTSORT:Use Case Software project management Software requirements Unified Modeling Language Systems Modeling Language 1986 establishments in Sweden 1986 in computing Swedish inventions Agile software development