🌁Software Engineering: Use Case (Definitions)

"A description of how the system will be used." (Jesse Liberty, "Sams Teach Yourself C++ in 24 Hours" 3rd Ed., 2001)

"The definition of a behavior of the software product based on gradually described interactions between user and system." (Johannes Link & Peter Fröhlich, "Unit Testing in Java", 2003)

"A set of possible sequences of interactions (scenarios) between systems and users (actors) in a particular environment and related to a particular goal. The use case and goal are sometimes considered to be synonymous. Use cases capture the intended behavior of the system, without specifying how that behavior is implemented. Use cases can be employed to identify, clarify, and organize system requirements, and, during later stages of software development, to validate design, create test cases, and create online help and user manuals." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"A sequence of actions a system performs that yields an observable result of value to a particular actor. A use-case class contains all main, alternate, and exception flows of events related to producing the 'observable result of value'." (Bruce MacIsaac & Per Kroll, "Agility and Discipline Made Easy: Practices from OpenUP and RUP", 2006)

"A concrete usage of a system, characterized by a set of scenarios, a set of requirements to which it traces, and a specification state machine." (Bruce P Douglass, "Real-Time Agility", 2009)

"A description of how end users will use a software code. It describes a task or a series of tasks that users will accomplish using the software and includes the responses of the software to user actions. Use cases may be included in the Software Requirements Document (SRD) as a way of specifying the end users’ expected use of the software." (Mark S Merkow & Lakshmikanth Raghavan, "Secure and Resilient Software Development", 2010)

"A model of human/machine interaction similar to data flow diagrams, in that it represents communications between external entities (here called 'Actors') and processes, but the assumption is that the processes involved represent systems (typically shown only as a single process representing the entire system). The content of data flows are not documented and, rather than being decomposed into lower-level detail, these details are simply described in text as 'steps'. There is no notion of storing data in intermediate 'data stores'." (David C Hay, "Data Model Patterns: A Metadata Map", 2010)

"A sequence of transactions in a dialogue between an actor and a component or system with a tangible result, where an actor can be a user or anything that can exchange information with the system." (IQBBA, "Standard glossary of terms used in Software Engineering", 2011)

"A sequence of transactions in a dialogue between an actor and a component or system with a tangible result. An actor can be a user or anything that can exchange information with the system." (Tilo Linz et al, "Software Testing Foundations" 4th Ed, 2014)

"A description of a series of interactions between actors. The actors can be users or parts of the application. A simple template might include a title, main success scenario, and extensions (other variations on the scenario)." (Rod Stephens, "Beginning Software Engineering", 2015)

"It is a list of events and actions among systems and users in a specific environment and for a specific goal." (Yassine Maleh et al, 'Strategic IT Governance and Performance Frameworks in Large Organizations", 2019)

"Technique used to define required functionality and objectives, and to design tests." (ITIL)