Editing Use case (section)

== General principle ==
Use cases are a technique for capturing, modeling, and specifying the requirements of a system.<ref name=":8" /> 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 [[Requirements analysis|requirement analysis]], at their identification, a use case is named according to the specific user goal that it represents for its primary actor. The case is further detailed with a textual description or with additional graphical models that explain the general sequence of activities and events, as well as variants such as special conditions, exceptions, or error situations.

According to the [[Software Engineering Body of Knowledge|Software Engineering Body of Knowledge (SWEBOK)]],<ref>{{Cite book|title=SWEBOK: guide to the software engineering body of knowledge|publisher=IEEE Computer Society|author1=Bourque, Pierre | author2=Fairley, R. E. (Richard E.)|year=2014|isbn=978-0-7695-5166-1|edition=Version 3.0|pages=1-6 to 1-8|oclc=880350861}}</ref> use cases belong to the scenario-based [[Requirements elicitation|requirement elicitation]] techniques, as well as the [[Model-based systems engineering|model-based analysis]], techniques. But the use cases also support narrative-based requirement gathering, incremental requirement acquisition, system documentation, and acceptance testing.<ref name=":1" />

=== 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.<ref name=":2" /> 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.<ref name=":4" /> 
* 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.<ref name=":6" /> 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.<ref name=":5" /> 
* Use Case 2.0 to adapt the technique for the context of agile development methods.<ref name=":1" /> 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.<ref name=":9">{{Cite web|last=Object Management Group|author-link=Object Management Group|date=2017|title=Unified Modeling Language Specification Version 2.5.1|url=https://www.omg.org/spec/UML/2.5.1|access-date=16 August 2020|website=www.omg.org}}</ref> 
* 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.<ref name=":7" /> 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.<ref name=":8" />  

=== Usage ===
Use cases are known to be applied in the following contexts:

* [[Object-oriented software engineering|Object Oriented Software Engineering (OOSE)]], as driving element;<ref name=":3" />  
* [[Unified Modeling Language]] (UML), as a behavioral modelling instrument;<ref name=":9" /> 
* [[Unified Process|Unified Software Development Process (UP)]] and its fore-runner, the [[IBM]] [[Rational Unified Process|Rational Unified Process (RUP)]];<ref name=":5" />
* up-front documentation of [[software requirements specification]] (SRS), as an alternative structure for the functional requirements;<ref>{{Cite book|last=Wiegers, Karl Eugene|title=More about software requirements: thorny issues and practical advice|date=2010|publisher=Microsoft Press|isbn=978-0-7356-2267-8|pages=Chapter 11|oclc=73814167}}</ref>
* deriving the design from the requirements using the [[entity–control–boundary]] approach;<ref name=":5" />
* and [[agile software development|agile development]].<ref name=":1" /><ref>{{Cite web|last=Ambler, Scott|author-link=Scott Ambler|date=2004|title=System Use Cases: An Agile Introduction|url=http://agilemodeling.com/artifacts/systemUseCase.htm|access-date=16 August 2020|website=agilemodeling.com}}</ref>