In software and systems engineering, a use case is a list of steps, typically defining interactions between a role (known in Unified Modeling Language (UML) as an "actor") and a system, to achieve a goal. The actor can be a human or an 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 Systems Modeling Language (SysML) or as contractual statements.
As an important requirement technique, use cases have been widely used in modern software engineering over the last two decades. Use case driven development is a key characteristic of process models and frameworks like Unified Process (UP), Rational Unified Process (RUP), Oracle Unified Method (OUM), etc. With its iterative and evolutionary nature, use case is also a good fit for agile development.
|Structural UML diagrams|
|Behavioral UML diagrams|
In 1986 Ivar Jacobson first formulated textual, structural and visual modeling techniques for specifying use cases. In 1992 his co-authored book helped to popularize the technique for capturing functional requirements, especially in software development. Originally he used the terms usage scenarios and usage case – the latter being 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. Since then, others have contributed to improving this technique, notably including Alistair Cockburn, Larry Constantine, Dean Leffingwell, Kurt Bittner and Gunnar Overgaard.
In 2011, Ivar Jacobson published an update to use cases called Use Case 2.0, the intention being to incorporate many of his practical experiences of applying use cases since its original inception.
- Title: "goal the use case is trying to satisfy":101
- Main Success Scenario: numbered list of steps:101
- Step: "a simple statement of the interaction between the actor and a system":101
- Extensions: separately numbered lists, one per Extension:101
- Extension: "a condition that results in different interactions from .. the main success scenario". An extension from main step 3 is numbered 3a, etc.:101
Cockburn's fully dressed use case template lists the following fields:
- Title: "an active-verb goal phrase that names the goal of the primary actor"
- Primary Actor
- Goal in Context
- Stakeholders and Interests
- Minimal Guarantees
- Success Guarantees
- Main Success Scenario
- Technology & Data Variations List
- Related Information.
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"
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
- (Story): the body of the use case is simply a paragraph or two of text, informally describing what happens.
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:
- Organization (black-box), a filled icon of a house
- Organization (white-box), an unfilled icon of a house
- System (black-box), a filled icon of a box
- System (white-box), an unfilled icon of a box
- Component, an icon of a screw or bolt.
Other authors sometimes call use cases at Organization level "Business use cases".
- Very high summary, an icon of a cloud (or ++)
- Summary, an icon of a flying kite (or +)
- User-goal, an icon of waves at sea (or !)
- Subfunction, an icon of a fish (or -)
- Too low, an icon of a seabed clam-shell (or --)
Sometime 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-.
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." Actors are always stakeholders, but not all stakeholders are actors, since they "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 different actors because he is 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.
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). 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 to look 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.
In the 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.
- The list of goal names provides the shortest summary of what the system will offer (even than 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 that are 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.
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 (such as platform, performance, timing, or safety-critical aspects). These are better specified declaratively elsewhere.
- Use case templates do not automatically ensure clarity. Clarity depends on the skill of the writer(s).
- For some products and systems, use cases are complex to write and to understand, for both end users and developers who are not well trained.
- 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.
- In Agile development, especially Extreme programming, simpler user stories are preferred to use cases.
- 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. In software engineering, this difficulty is resolved by applying requirements traceability, for example with a traceability matrix. 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 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.
- User story is agile, use case is not.
- Agile and Scrum is 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 cases are mainly diagrams. Larman stresses that "use cases are not diagrams, they are text"
- Use cases are always complex and difficult to write, understand and learn.
|This section does not cite any references or sources. (August 2013)|
Text editors and/or word processors with template support are often used to write use cases. For large and complex system requirements, dedicated use case tools are helpful.
- Rational Software's RequisitePro - one of the early, well-known use case and requirement management tools in the 1990s.
- Wiki software - good tools for teams to author and manage use cases collaboratively.
Most UML Tools support both the text writing and visual modeling of use cases.
- Business case
- Event partitioning
- List of UML tools
- Misuse case
- Test Case
- Unified Process
- Use Case Points
- User story
- Jacobson et al, 1992.
- "Alistair Cockburn, "Use cases, ten years later"". Alistair.cockburn.us. Retrieved 2013-04-17.
- "Business Analysis Conference Europe 2011 - 26-28 September 2011, London, UK". Irmuk.co.uk. Retrieved 2013-04-17.
- Fowler, 2004.
- Cockburn, 2001
- Cockburn, 2001. Page 120.
- Cockburn, 2001. Inside rear cover. Field "Use Case Title".
- Alexander and Beus-Dukic, 2009. Page 121
- Cockburn, 2001. Inside front cover. Icons "Design Scope".
- Suzanne Robertson. Scenarios in Requirements Discovery. Chapter 3 in Alexander and Maiden, 2004. Pages 39-59.
- Cockburn, 2001. Inside front cover. Icons "Goal Level".
- Cockburn, 2001. Page 53.
- Cockburn, 2001. Page 55.
- Alexander and Beus-Dukic, 2009. Page 39.
- Cockburn, Alistair (2008-01-09). "Why I still use use cases". alistair.cockburn.us.
- Meyer, 2000. (page needed)
- Armour and Miller, 2000. (page needed)
- Denney, 2005. (page needed)
- Deemer, Pete. "The Scrum Primer: A Lightweight Guide to the Theory and Practice of Scrum".
- Larman, Craig. Applying UML and patterns. Prentice Hall. pp. 63–64. ISBN 0-13-148906-2.
- 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, Aug 20, 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. Dec 7, 2012.
- Meyer, Bertrand. Object Oriented Software Construction. (2nd edition). Prentice Hall, 2000.
- Gunnar Overgaard, Karin Palmkvist, Use Cases: Patterns and Blueprints, Addison-Wesley Professional, Nov 12, 2004.
- Schneider, Geri and Winters, Jason P. Applying Use Cases 2nd Edition: A Practical Guide. Addison-Wesley, 2001.
- Use Cases (Usability.gov)
- Basic Use Case Template by Alistair Cockburn
- Application of use cases for stakeholder analysis "Project Icarus: Stakeholder Scenarios for an Interstellar Exploration Program", JBIS, 64, 224-233
- "An Academic Survey on the Role of Use Cases in the UML"