Use case
A use case is a methodology used in software and systems engineering to describe the interactions between external actors—such as users or other systems—and a system to achieve a specific, observable goal that provides value.[1] It outlines a sequence of actions, including primary flows, alternative paths, and exceptions, serving as a foundational tool for capturing and organizing functional requirements in a clear, user-centered manner.[2] Originating in the late 1980s, the concept was introduced by Swedish computer scientist Ivar Jacobson at the OOPSLA '87 conference, where he presented textual and visual techniques for modeling system behaviors to address the growing complexity of object-oriented software development.[3] Jacobson's work gained prominence through his 1992 book Object-Oriented Software Engineering: A Use Case Driven Approach, co-authored with Mats Christerson, Patrik Jonsson, and Gunnar Övergaard, which popularized use cases as a core practice in requirements engineering.[4] Over time, the approach evolved into Use-Case 2.0, integrating agile principles like user stories and iterative development to make it lighter and more scalable for modern methodologies such as Scrum and Kanban.[1] Use cases play a central role across the software development lifecycle, acting as a "hub" that connects requirements elicitation, system architecture, design, testing, and user documentation.[1] They help identify potential errors early, prevent scope creep by focusing on essential functionalities, and facilitate communication among stakeholders by providing concrete scenarios rather than abstract specifications.[2] Key components include actors (entities initiating interactions), goals (desired outcomes), and system responses (steps and behaviors), often represented textually or visually via UML use case diagrams to enhance clarity and reusability.[5] Beyond software, use cases extend to business process modeling and product design, emphasizing practical value in diverse engineering contexts.[6]Fundamentals
Definition
A use case is a textual or visual description of how external actors interact with a system to achieve specific goals, serving as a foundational tool in requirements engineering to capture functional behaviors and system responses.[1] Originating from object-oriented analysis, it outlines sequences of actions that yield observable results of value to actors, such as users or other systems, without prescribing internal implementation details.[7] Primary components of a use case include actors, defined as external entities that initiate or participate in interactions; scenarios, which detail step-by-step exchanges between actors and the system; preconditions, specifying required states before execution; postconditions, outlining expected outcomes upon completion; and extensions, handling alternative or exceptional paths.[7] In the Unified Modeling Language (UML), use cases are formalized as behavioral specifications within use case diagrams, representing declarations of offered behaviors by a subject in collaboration with actors to deliver stakeholder value.[7] Use cases differ from user stories, which are concise, agile artifacts focusing on user needs in a "As a [role], I want [goal] so that [benefit]" format without detailed steps, whereas use cases provide comprehensive interaction narratives.[8] They also contrast with functional specifications, which elaborate on system internals and implementation mechanisms derived from use cases, rather than high-level actor-system dialogues.[9]Historical Development
The concept of use cases traces its roots to systems analysis techniques developed in the 1960s, which emphasized describing user interactions with systems to capture requirements. However, the modern formulation of use cases as a structured practice emerged in the late 1980s through the work of Ivar Jacobson, a Swedish computer scientist, who introduced the term in 1986 while developing object-oriented methods at Ericsson. Jacobson had been evolving the idea since 1967, drawing on earlier ideas like scenario-based analysis to make requirements more user-centered and actionable in software engineering.[10] A pivotal milestone came in 1992 with Jacobson's book Object-Oriented Software Engineering: A Use Case Driven Approach, which positioned use cases as the central driver for analysis, design, and implementation in object-oriented development, influencing widespread adoption in the 1990s. Use cases were formally standardized in 1997 with the release of UML 1.0 by the Object Management Group (OMG), integrating them as a core diagramming element for modeling system behaviors and actor interactions. Refinements in UML 2.0, adopted in 2005, enhanced their extensibility through mechanisms like include and extend relationships, allowing for more modular and reusable specifications while addressing limitations in earlier versions.[11] Following the Agile Manifesto in 2001, use cases integrated into iterative methodologies, adapting to lightweight practices like user stories while retaining depth for complex requirements; Alistair Cockburn's 2001 book Writing Effective Use Cases contributed key styles and templates, such as goal-level summaries, bridging traditional and agile approaches. By the 2010s, Jacobson's Use-Case 2.0 framework (introduced around 2011 and refined thereafter) modernized the practice for agile, lean, and scaled environments, emphasizing essentials like use case slices for incremental delivery. This evolved further with Use Case 3.0, released in December 2024, aligning with the Use Case Foundation principles co-developed with Cockburn to support contemporary development needs.[12][4][13] In AI system design, they address ethical gaps by modeling bias mitigation and transparency requirements, as seen in UML-based "use case cards" frameworks inspired by the EU AI Act (2024), which document intended purposes and risks to promote accountable AI deployment.[14]Core Principles
General Principles
Use cases adhere to a goal-oriented methodology that prioritizes the intentions and objectives of users over intricate technical implementations, ensuring that descriptions capture the essence of what the system must achieve from an external perspective. This approach treats the system as a black-box, concealing internal mechanisms to focus solely on observable interactions between actors and the system, thereby promoting clarity and abstraction from implementation details.[15] In constructing use cases, practitioners first identify primary actors—those initiating the goal—and secondary actors that support or assist, establishing the foundational interactions (detailed further in the Key Elements and Actors section). The structure typically comprises a main success scenario outlining the primary path from trigger to successful outcome, supplemented by extensions that handle alternative paths, failures, or exceptions to provide a comprehensive view of possible behaviors. Traceability is ensured by linking use cases directly to functional requirements and stakeholder needs, serving as a contractual bridge between user goals and system responsibilities.[15] Best practices emphasize maintaining conciseness while achieving completeness, limiting main scenarios to 3-11 steps with simple, intent-focused language to avoid verbosity. Iterative refinement through techniques like brainstorming and evaluation allows progressive enhancement, starting from high-level outlines and incorporating feedback across development stages. Alignment with non-functional requirements, such as performance and security, is integrated via preconditions, postconditions, and stakeholder interest protections to ensure holistic coverage.[15]Key Elements and Actors
In use case modeling, actors represent external entities that interact with the system to achieve specific goals. An actor is formally defined as a classifier denoting a coherent set of roles that users of an entity can play when interacting with the entity, such as humans, other systems, or hardware devices. Actors can be human, involving users or stakeholders, or non-human, such as external software systems or automated processes that provide or receive services from the subject system. Actors are classified into primary and secondary types based on their role in initiating and supporting use case execution. The primary actor is the entity that initiates the interaction with the system to accomplish a goal, driving the primary flow of events. In contrast, secondary actors are those upon which the system relies to perform actions or provide support during the use case, such as external databases or third-party services. This distinction ensures that use cases clearly delineate responsibilities and system boundaries. Interaction elements within a use case describe the sequence of actions between actors and the system. These include triggers, which are events or conditions that initiate the use case, such as a user request or system event; main flows, outlining the primary sequence of steps to achieve the goal; alternative flows, which handle variations in the main path under normal conditions; and exception flows, addressing error conditions or failures. Additionally, guarantees specify the postconditions that must hold true upon successful completion, regardless of the path taken, ensuring the actor's goal is met or the system state is preserved. In UML, use cases employ <Variations and Applications
Scope and Usage Variations
In use case modeling, scope defines the boundaries of the interactions and functionalities described, distinguishing between system scope, which focuses on the interactions within a specific software system or component, and enterprise scope, which encompasses the broader organizational or business processes involving multiple systems or human activities.[16] System scope treats the software as a black box, detailing user interactions with its interface to achieve goals within a contained timeframe, such as a single session.[17] Enterprise scope, in contrast, views the organization as the system under discussion, capturing end-to-end business workflows that may span days or weeks and include manual steps beyond automation.[16] Boundaries are determined using tools like context diagrams, which visualize external actors and their interactions with the system, alongside in/out lists that categorize elements as within or outside the scope to prevent overlap or omission.[17][18] Use cases exhibit variations in their application, primarily between functional and non-functional types, where functional use cases describe core system behaviors and user interactions to fulfill specific goals, such as processing a transaction, while non-functional use cases address cross-cutting concerns like security or performance, often modeled as aspects that weave into primary flows.[19] High-level use cases provide overviews of major functionalities for initial planning, whereas detailed use cases elaborate step-by-step scenarios ready for implementation, including extensions and exceptions.[20] In waterfall processes, use cases are typically developed comprehensively upfront to lock in requirements before design and coding, emphasizing stability and traceability.[21] Conversely, in iterative processes, use cases evolve incrementally, with initial versions refined through feedback loops to accommodate changes.[21] Use cases adapt across the software lifecycle for requirements elicitation, where they facilitate stakeholder collaboration to uncover needs through scenario brainstorming; validation, by serving as living documents tested against working software for alignment; and maintenance, enabling impact analysis during updates via traceability to test cases.[22] In agile sprints, use cases support iterative refinement, with variants like behavior-driven development integrating them into acceptance criteria for frequent validation.[22] For microservices scoping, use cases delineate service boundaries by mapping high-level business functionalities to independent, loosely coupled components, aiding decomposition in greenfield projects. Use cases operate at varying goal levels to balance abstraction and detail: summary level captures high-level overviews of multi-step processes spanning extended periods, user-goal level focuses on primary actor outcomes achievable in a single interaction, and subfunction level breaks down supporting tasks for reuse or clarity, though it risks delving into design details.[20][23] These levels, symbolized by cloud (summary), sea (user-goal), and fish/clam (subfunction) metaphors, ensure use cases remain actor-centric while adapting to project needs.[23]Business and Systems Applications
In business analysis, use cases serve as a foundational tool for capturing organizational goals, defining end-to-end processes, and ensuring value delivery to stakeholders by outlining how an organization interacts with its environment to achieve objectives such as revenue growth or operational efficiency.[24] Unlike software-focused use cases that emphasize system-user interactions, business use cases adopt a broader scope, encompassing multi-step workflows that may span days or weeks and involve diverse actors like customers, suppliers, and managers to align activities with strategic priorities.[24] This approach facilitates the identification of value streams, where processes are refined to eliminate redundancies and enhance outcomes, such as streamlining supply chain operations to reduce costs.[25] A key integration in business use cases is with Business Process Model and Notation (BPMN), which transforms narrative use cases into executable models for simulation and automation, supporting organizational processes by mapping participants to swimlanes, activities to tasks, and decisions to gateways.[25] Guidelines for this conversion involve parsing use case text—identifying subjects as participants, verbs as activities, and conditions as rules—to create structured BPMN diagrams that handle both primary and exception flows, thereby improving process maturity and alignment with business goals like faster decision-making.[25] In enterprise architecture frameworks such as TOGAF, use cases are embedded within the Architecture Development Method (ADM), particularly in the Business Architecture phase, to define capabilities, baseline current processes, and target future states that deliver measurable business value, such as enhanced agility in digital transformation initiatives.[26] Business use cases differ from software variants through their emphasis on broader stakeholder involvement, including external regulators and partners, and incorporation of regulatory compliance requirements that extend beyond technical functionality to legal and ethical obligations.[24] In finance, for instance, use cases model compliance with anti-money laundering standards like Know Your Customer (KYC) by detailing automated transaction monitoring and reporting workflows to mitigate risks and ensure adherence to frameworks such as the Bank Secrecy Act.[27] Similarly, in healthcare, use cases address HIPAA requirements by specifying secure data handling processes, from patient consent to audit trails, to protect privacy while enabling efficient care delivery and reducing breach-related penalties.[28] In systems engineering, use cases are applied to hardware-software hybrid environments, such as IoT and embedded systems, where they drive requirements elicitation to ensure interoperability between components like sensors and cloud services, while addressing safety-critical scenarios in domains like automotive or medical devices.[29] For IoT applications, use cases capture dynamic interactions—such as real-time data exchange in smart manufacturing—to generate functional and non-functional requirements, often enhanced by AI techniques like SVM classifiers for prioritization and validation, promoting reliable system behavior across heterogeneous networks.[29] In safety-critical embedded systems, use cases emphasize fault-tolerant designs compliant with standards like ISO 26262 for automotive or IEC 61508 for industrial controls, modeling scenarios like failure recovery in autonomous vehicles to verify interoperability and minimize risks from hardware-software integration.[30] Developments in 2025 highlight use cases in AI governance, particularly for regulatory compliance in business and systems contexts. The America's AI Action Plan (July 2025) discusses AI use cases for accelerating processes and improving sectors like healthcare, while proposing regulatory sandboxes supported by the FDA for testing AI tools, under frameworks led by NIST and the FDA to evaluate ethical deployment and bias mitigation.[31] These initiatives extend to critical infrastructure and security, ensuring systems meet evolving standards for transparency and accountability while supporting broader organizational resilience.[31] In business contexts, actors typically include external entities like regulators, expanding beyond internal users to incorporate compliance oversight in process design.[24]Templates and Formats
Cockburn Template
The Cockburn template, developed by Alistair Cockburn, provides a structured format for authoring use cases that emphasizes goal-oriented scenarios, actor interactions, and handling of variations to ensure comprehensive coverage of system behaviors.[32] It includes key sections such as the title, which captures the primary goal as a concise, active-verb phrase (e.g., "Withdraw Cash"); scope, defining the boundary of analysis; level, indicating the granularity of the goal; primary and secondary actors, identifying the initiators and supporting entities; stakeholders, listing interested parties and their concerns; preconditions, specifying required initial states; success guarantees, outlining post-success conditions; main success scenario, detailing the step-by-step happy path; extensions, addressing alternative or exceptional flows; and sub-variations, noting minor deviations within steps.[33] This structure promotes clarity by mapping the use case as a navigational aid through primary and branching paths, facilitating requirements elicitation and validation. Design scopes in the Cockburn template refer to the perspective from which the use case is viewed, influencing the depth and focus of the content: system scope treats the system as a black box, emphasizing external interactions and user-visible behaviors without internal details; enterprise scope adopts a white box view of the organization, incorporating broader business processes and inter-system dynamics; and process scope targets specific workflows, allowing for detailed procedural breakdowns.[32] These scopes guide content depth—for instance, a system scope keeps descriptions concise and actor-focused, while an enterprise scope expands to include organizational impacts, ensuring the use case aligns with varying project needs without overwhelming lower-level details.[33] Goal levels in the template classify the abstraction of the use case to match the intended audience and purpose: sea level represents high-level user goals achievable in a single session (e.g., "Purchase Item Online"), focusing on end-user value; kite level covers summary or sub-goals that span multiple sessions (e.g., "Manage Inventory"), providing contextual overviews; and fish level delves into detailed, low-level steps or subfunctions (e.g., "Validate Payment Details"), breaking down complex interactions into granular actions.[33] These levels, symbolized by nautical metaphors (sea for user-visible, kite for aerial summary, fish for submerged details), help writers avoid overly abstract or microscopic descriptions, aligning the use case with goal orientation principles.[34] The template supports two primary formats to accommodate different stages of development: the fully dressed format, which populates all sections with comprehensive narratives, numbered steps, and explicit handling of extensions, is ideal for critical requirements documentation where precision and completeness mitigate risks in complex projects; in contrast, the casual format uses an outline or bullet-point style with only essential elements like the main scenario and actors, suited for early brainstorming or agile iterations to foster rapid collaboration without exhaustive detail.[32] This dual approach balances thoroughness with efficiency, allowing teams to evolve use cases progressively from casual sketches to fully dressed specifications as understanding deepens.[33]Fowler Template
The Fowler template, introduced by Martin Fowler in his work on UML and requirements analysis, provides a lightweight and practical format for documenting use cases, emphasizing brevity to facilitate quick iteration in software development.[35] This template structures use cases around core elements: a brief name that encapsulates the primary goal, a concise summary outlining the overall purpose and scope, identification of actors (such as users or external systems involved), a numbered sequence of steps in the main flow of events to describe essential interactions between actors and the system, and extensions that handle alternative or exceptional paths branching from the main flow.[36] The focus remains on capturing only the vital interactions without exhaustive details, ensuring the documentation remains readable and actionable.[37] Key features of the template include its seamless integration with UML use case diagrams, where the textual content serves as the primary artifact and diagrams provide optional visual overviews of relationships among use cases and actors.[35] It also stresses preconditions—states or conditions that must hold true before the use case begins—and postconditions, which specify the expected outcomes or system states upon completion, helping to clarify boundaries and validate implementation.[36] This structure aligns well with agile environments, promoting short, narrative-driven descriptions that support iterative development and collaboration without imposing heavy documentation overhead.[38] Compared to more comprehensive formats, the Fowler template prioritizes conciseness for rapid prototyping and development, omitting deep explorations of sub-variations or nested scenarios unless they directly impact core functionality.[35]Modeling and Representation
Visual Modeling Techniques
Visual modeling techniques provide graphical representations of use cases, enabling stakeholders to visualize system interactions, actors, and relationships in a structured manner beyond textual narratives. The primary technique is the Unified Modeling Language (UML) use case diagram, which depicts the functional requirements of a system through simple, intuitive symbols. In these diagrams, actors are represented as stick figures symbolizing external entities interacting with the system, use cases appear as ovals encapsulating specific functionalities or goals, and solid lines denote associations between actors and use cases.[39][40] UML use case diagrams further incorporate relationships to model dependencies and variations among use cases. The "include" relationship, shown as a dashed arrow labeled «include», indicates that one use case mandatorily incorporates the behavior of another, promoting reuse and modularity. Conversely, the "extend" relationship, depicted similarly but labeled «extend», allows optional behavior to be added to a base use case under specific conditions, such as exceptional scenarios. These elements collectively form a boundary around the system, often enclosed in a rectangle to distinguish it from external actors.[40][39] For systems engineering contexts, earlier versions of the Systems Modeling Language (SysML v1) extend UML use case diagrams to address broader interdisciplinary requirements, including hardware and software integration. SysML v1 use case diagrams retain core UML elements like actors and ovals but emphasize system boundaries and stakeholder value derivation, making them suitable for complex, non-software systems. They facilitate high-level requirements capture in non-technical terms, aiding collaboration across engineering disciplines. As of July 2025, SysML v2 provides an independent modeling language based on the Kernel Modeling Language (KerML), supporting use case concepts for complex systems while emphasizing system boundaries and stakeholder value.[41][42][43] To elaborate on the internal flows of use cases, UML activity diagrams serve as a complementary visual technique, modeling the sequence of actions, decisions, and parallel processes within a single use case. These diagrams use rounded rectangles for activities, diamonds for decision nodes, and arrows for control flows, providing a flowchart-like view of dynamic behavior that refines the high-level overview from use case diagrams. This approach is particularly effective for detailing workflows or scenarios that extend beyond simple actor interactions.[44][39] In business-oriented applications, Business Process Model and Notation (BPMN) offers another graphical method to visualize use cases within end-to-end processes, using pools for participants, tasks as rounded rectangles, and gateways for branching logic. BPMN diagrams map how use cases fit into operational workflows, emphasizing sequence, events, and collaborations, which enhances traceability from business requirements to system implementation.[45][46] Best practices for visual modeling recommend integrating these diagrams with detailed textual descriptions to achieve a holistic specification, where diagrams provide an at-a-glance overview and text elaborates preconditions, postconditions, and step-by-step flows. This combination mitigates ambiguity and ensures alignment between visual and narrative elements. Additionally, automated generation of diagrams from textual use case specifications maintains consistency and reduces manual errors in iterative development processes. Recent advancements, such as UML profiles for security modeling, enable the extension of use case diagrams to incorporate threat analysis and secure interactions, as outlined in specialized frameworks for vulnerability assessment.[47][48]Supporting Tools
Several software tools facilitate the creation, documentation, and management of use cases, ranging from specialized modeling environments to collaborative diagramming platforms. Historically, Rational Rose, developed by Rational Software in the 1990s, was a pioneering CASE (Computer-Aided Software Engineering) tool that supported UML-based use case modeling through visual diagrams and scenario generation, though it has been largely superseded by modern alternatives following IBM's acquisition in 2003, with support for later versions ending in 2024.[49][50] Among proprietary tools, Sparx Systems' Enterprise Architect provides comprehensive support for use case diagrams, including actor modeling, scenario elaboration, and traceability to requirements, enabling teams to generate visual representations and maintain links across project artifacts.[51] Lucidchart offers an intuitive online interface for constructing UML use case diagrams, with features for embedding actors, ovals for use cases, and system boundaries, suitable for rapid prototyping in collaborative settings.[52] In contrast, open-source options like diagrams.net (formerly Draw.io) allow free creation of use case diagrams via drag-and-drop shapes, supporting export to various formats and integration with platforms like Confluence for team workflows.[53] For agile environments, Jira plugins such as Structure by Tempo and Easy Agile Programs enhance use case management by enabling hierarchical organization of user stories and epics, with traceability to sprints and backlogs, though specialized add-ons like QMetry extend this to requirement-linked use cases.[54][55] Key features across these tools include automated diagram generation from textual descriptions, traceability matrices to link use cases to tests or requirements, and real-time collaboration via cloud syncing, with proprietary tools often providing advanced simulation capabilities while open-source variants emphasize accessibility and customization.[56] Methodological support is bolstered through integrations with requirements management systems; for instance, Enterprise Architect connects with IBM Engineering Requirements Management DOORS (DOORS Next) to import use cases as traceable requirements, ensuring bidirectional updates for compliance-heavy projects.[57] Similarly, Azure DevOps incorporates use case modeling via extensions like Modern Requirements, which automates the conversion of textual use cases into work items and diagrams, facilitating agile iteration and reporting.[58] Emerging AI-assisted tools address gaps in manual authoring by leveraging large language models (LLMs) for generation; as of 2025, platforms like GitMind and Miro use AI to suggest use case structures from natural language prompts, producing diagrams and scenarios while integrating with collaborative editors, though human validation remains essential for accuracy.[59] These advancements expand beyond traditional tools by automating initial drafts, particularly in dynamic environments.Practical Examples
Basic Use Case Examples
Basic use cases illustrate the fundamental structure of interactions between actors and systems in software engineering, focusing on primary goals and handling simple variations. These examples draw from established methodologies to demonstrate how use cases capture user intentions without unnecessary detail.Example 1: ATM Withdrawal
Actors: Primary actor: Customer; Secondary actor: Bank system.[60] Preconditions: The customer has a valid ATM card and sufficient funds in their account; the ATM is operational.[60] Main Success Scenario:- The customer inserts their ATM card into the machine.
- The bank system prompts for the PIN.
- The customer enters the PIN.
- The bank system validates the PIN against the card details.
- The customer selects the withdrawal option and specifies the amount.
- The bank system checks the account balance and dispenses the cash if sufficient.
- The bank system ejects the card and updates the account balance.[60]
- At step 4a: If the PIN is invalid, the system prompts for re-entry (up to three attempts); after three failures, the card is retained.[60]
- At step 6a: If funds are insufficient, the system displays an error message and returns to the main menu without dispensing cash.[60]
Example 2: E-Commerce Login
Actors: Primary actor: Customer; Secondary actor: E-commerce system.[12] Preconditions: The customer has a registered account with valid credentials; the e-commerce website is accessible.[12] Main Success Scenario:- The customer navigates to the login page on the e-commerce site.
- The customer enters their username and password.
- The e-commerce system verifies the credentials against the stored user data.
- The system grants access and redirects the customer to their account dashboard or the homepage.[12]
- At step 3a: If credentials are invalid, the system displays an error message and prompts the customer to retry (limited to three attempts).[12]