Use case
Encyclopedia
In software engineering
and systems engineering
, a use case is a description of steps or actions between a user (or "actor
") and a software system which leads the user towards something useful. The user or actor might be a person or something more abstract, such as an external software system or manual process.
Use cases are a software modeling technique that helps developers to determine which features to implement and how to resolve errors gracefully.
Within 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 SysML requirement diagrams or similar mechanisms.
, later an important contributor to both the Unified Modeling Language
(UML) and the Rational Unified Process
(RUP), first formulated the textual, structural and visual modeling
techniques for specifying use cases. The use case technique became popular through Jacobson's 1992 book Object-Oriented Software Engineering - A Use Case Driven Approach, co-authored with Magnus Christerson, Patrik Jonsson and Gunnar Övergaard. Originally he used the terms usage scenarios and usage case, which were the more correct translations of the Swedish word "användningsfall" he used, but found that neither of these terms sounded natural in English, and eventually he settled on the term use case. Since Jacobson originated use case modeling many others have contributed to improving this technique, including Kurt Bittner, Ian Spence, Alistair Cockburn
, Gunnar Övergaard, Karin Palmkvist, Patrik Jonsson, Magnus Christerson and Geri Schneider.
During the 1990s use cases became one of the most common practices for capturing functional requirements
. This is especially the case within the object-oriented community where they originated, but their applicability is not restricted to object-oriented systems.
is all that is required. In other development methodologies , use cases evolve in complexity and change in character as the development process proceeds. Use cases can be a valuable source of usage information and usage testing ideas. In some methodologies, they may begin as brief business use cases, evolve into more detailed system use cases, and then eventually develop into highly detailed and exhaustive test cases...
Use cases should not be confused with the features of the system.
One or more features (a.k.a. "system requirements") describe the functionality needed to meet a stakeholder request or user need (a.k.a. "user requirement"). Each feature can be analyzed into one or more use cases, which detail cases where an actor uses the system. Each use case should be traceable to its originating feature, which in turn should be traceable to its originating stakeholder/user request.
Use cases treat the system as a black box, and the interactions with the system, including system responses, are perceived as from outside the system. This is a deliberate policy, because it forces the author to focus on what the system must do, not how it is to be done, and avoids making assumptions about how the functionality will be accomplished.
A use case should:
Use cases are mostly text documents, and use case modeling is primarily an act of writing text and not drawing diagrams. Use case diagrams are secondary in use case work.
, in Writing Effective Use Cases, identified three levels of detail in writing use cases:
Some software development process
es do not require anything more than a simple use case to define requirements. However, some other development processes require detailed use cases to define requirements. The larger and more complex the project, the more likely that it will be necessary to use detailed use cases.
The level of detail in a use case often differs according to the progress of the project. The initial use cases may be brief, but as the development process unfolds the use cases become even more detailed. This reflects the different requirements of the use case. Initially they need only be brief, because they are used to summarize the business requirement from the point of view of users. However, later in the process, software developers need far more specific and detailed guidance.
The Rational Unified Process
invites developers to write a brief use case description in the use case diagram
, with a casual description as comments and a detailed description of the flow of events in a textual analysis. All those can usually be input into the use case tool (e.g., a UML Tool
, SysML Tool), or can be written separately in a text editor.
Types of Actors
Alternate approach:
The reference for this section is a book on object oriented analysis and design. So as such, it does not apply directly to Use Cases. It applies to the analysis and design of a system that would implement a use case. It does not apply to the construction of a use case.
This alternative has worked well in hundreds of use cases. The reason is that the primary consumer of a use case is one or more software developers. It represents the single transaction of one and only one actor. Other systems may be affected, but only one actor initiates this transaction.
If there are other use cases that are associated with a subject use case, they can be referenced in the subject use case appendix. Other documents such as a work-flow map can be used to tie together associated use cases and the actors they represent. A use case diagram may also be used to relate various actors in a system and the use cases with which they are associated.
, 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.
Software engineering
Software Engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software...
and systems engineering
Systems engineering
Systems engineering is an interdisciplinary field of engineering that focuses on how complex engineering projects should be designed and managed over the life cycle of the project. Issues such as logistics, the coordination of different teams, and automatic control of machinery become more...
, a use case is a description of steps or actions between a user (or "actor
Actor (UML)
An actor in the Unified Modeling Language "specifies a role played by a user or any other system that interacts with the subject.""An Actor models a type of role played by an entity that interacts with the subject ,...
") and a software system which leads the user towards something useful. The user or actor might be a person or something more abstract, such as an external software system or manual process.
Use cases are a software modeling technique that helps developers to determine which features to implement and how to resolve errors gracefully.
Within 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 SysML requirement diagrams or similar mechanisms.
History
In 1986 Ivar JacobsonIvar Jacobson
Ivar Hjalmar Jacobson is a Swedish computer scientist, known as major contributor to UML, Objectory, RUP and aspect-oriented software development.- Biography :...
, later an important contributor to both the Unified Modeling Language
Unified Modeling Language
Unified Modeling Language is a standardized general-purpose modeling language in the field of object-oriented software engineering. The standard is managed, and was created, by the Object Management Group...
(UML) and the Rational Unified Process
Rational Unified Process
The Rational Unified Process is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003...
(RUP), first formulated the textual, structural and visual modeling
Visual modeling
Visual modeling is the graphic representation of objects and systems of interest using graphical languages. Visual modeling languages may be General-Purpose Modeling languages or Domain-Specific Modeling languages...
techniques for specifying use cases. The use case technique became popular through Jacobson's 1992 book Object-Oriented Software Engineering - A Use Case Driven Approach, co-authored with Magnus Christerson, Patrik Jonsson and Gunnar Övergaard. Originally he used the terms usage scenarios and usage case, which were the more correct translations of the Swedish word "användningsfall" he used, but found that neither of these terms sounded natural in English, and eventually he settled on the term use case. Since Jacobson originated use case modeling many others have contributed to improving this technique, including Kurt Bittner, Ian Spence, Alistair Cockburn
Alistair Cockburn
Alistair Cockburn is one of the initiators of the agile movement in software development, helping write theManifesto for Agile Software Development in 2001 and the agile PM Declaration of Interdependence in 2005...
, Gunnar Övergaard, Karin Palmkvist, Patrik Jonsson, Magnus Christerson and Geri Schneider.
During the 1990s use cases became one of the most common practices for capturing functional requirements
Functional requirements
In software engineering, a functional requirement defines a function of a software system or its component. A function is described as a set of inputs, the behavior, and outputs ....
. This is especially the case within the object-oriented community where they originated, but their applicability is not restricted to object-oriented systems.
Use cases and the development process
The specific way use cases are used within the development process will depend on which development methodology is being used. In certain development methodologies , a brief use case surveyUse case survey
Use case survey is a list of names and perhaps brief descriptions of use cases associated with a system, component, or other logical or physical entity. This artifact is short and inexpensive to produce early in the analysis or envisioning stages of a software development project.There are a wide...
is all that is required. In other development methodologies , use cases evolve in complexity and change in character as the development process proceeds. Use cases can be a valuable source of usage information and usage testing ideas. In some methodologies, they may begin as brief business use cases, evolve into more detailed system use cases, and then eventually develop into highly detailed and exhaustive test cases...
Use case focus
"Each use case focuses on describing how to achieve a goal or a task. For most software projects, this means that multiple, perhaps dozens of use cases are needed to define the scope of the new system. The degree of formality of a particular software project and the stage of the project will influence the level of detail required in each use case."Use cases should not be confused with the features of the system.
One or more features (a.k.a. "system requirements") describe the functionality needed to meet a stakeholder request or user need (a.k.a. "user requirement"). Each feature can be analyzed into one or more use cases, which detail cases where an actor uses the system. Each use case should be traceable to its originating feature, which in turn should be traceable to its originating stakeholder/user request.
Use cases treat the system as a black box, and the interactions with the system, including system responses, are perceived as from outside the system. This is a deliberate policy, because it forces the author to focus on what the system must do, not how it is to be done, and avoids making assumptions about how the functionality will be accomplished.
A use case should:
- Describe what the system shall do for the actor to achieve a particular goal.
- Include no implementation-specific language.
- Be at the appropriate level of detail.
- Not include detail regarding user interfaces and screens. This is done in user-interface design, which references the use case and its business rules.
Use cases are mostly text documents, and use case modeling is primarily an act of writing text and not drawing diagrams. Use case diagrams are secondary in use case work.
Degree of detail
Alistair CockburnAlistair Cockburn
Alistair Cockburn is one of the initiators of the agile movement in software development, helping write theManifesto for Agile Software Development in 2001 and the agile PM Declaration of Interdependence in 2005...
, in Writing Effective Use Cases, identified three levels of detail in writing use cases:
- Brief use case -- consists of a few sentences summarizing the use case. It can be easily inserted in a spreadsheet cell, and allows the other columns in the spreadsheet to record priority, duration, a method of estimating duration, technical complexity, release number, and so on.
- Casual use case -- consists of a few paragraphs of text, summarizing the use case.
- Fully dressed use case -- a formal document based on a detailed template with fields for various sections; and it is the most common understanding of the meaning of a use case.
Some software development process
Software development process
A software development process, also known as a software development life cycle , is a structure imposed on the development of a software product. Similar terms include software life cycle and software process. It is often considered a subset of systems development life cycle...
es do not require anything more than a simple use case to define requirements. However, some other development processes require detailed use cases to define requirements. The larger and more complex the project, the more likely that it will be necessary to use detailed use cases.
The level of detail in a use case often differs according to the progress of the project. The initial use cases may be brief, but as the development process unfolds the use cases become even more detailed. This reflects the different requirements of the use case. Initially they need only be brief, because they are used to summarize the business requirement from the point of view of users. However, later in the process, software developers need far more specific and detailed guidance.
The Rational Unified Process
Rational Unified Process
The Rational Unified Process is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003...
invites developers to write a brief use case description in the use case diagram
Use case diagram
A use case diagram in the Unified Modeling Language is a type of behavioral diagram defined by and created from a Use-case analysis. Its purpose is to present a graphical overview of the functionality provided by a system in terms of actors, their goals , and any dependencies between those use...
, with a casual description as comments and a detailed description of the flow of events in a textual analysis. All those can usually be input into the use case tool (e.g., a UML Tool
UML tool
A UML tool or UML modeling tool is a software application that supports some or all of the notation and semantics associated with the Unified Modeling Language , which is the industry standard general purpose modeling language for software engineering.UML tool is used broadly here to include...
, SysML Tool), or can be written separately in a text editor.
Actors
A use case defines the interactions between external actors and the system under consideration to accomplish a goal. An actor specifies a role played by a person or thing when interacting with the system. The same person using the system may be represented as different actors because they are playing different roles. For example, user "Joe" could be playing the role of a Customer when using an Automated Teller Machine to withdraw cash, or playing the role of a Bank Teller when using the system to restock the cash drawer.Types of Actors
- Primary Actor - Fulfills the user goals by using the services of the SuD (System Under Discussion). Ex: 'Cashier' in a Process Sale System.
- Secondary Actor - Provides a service to the SuD. Ex: 'Automated payment authorization service'.
- Offstage Actor - Has an interest in the behavior of the system but is not primary or secondary. Ex: A government tax agency.
Alternate approach:
The reference for this section is a book on object oriented analysis and design. So as such, it does not apply directly to Use Cases. It applies to the analysis and design of a system that would implement a use case. It does not apply to the construction of a use case.
This alternative has worked well in hundreds of use cases. The reason is that the primary consumer of a use case is one or more software developers. It represents the single transaction of one and only one actor. Other systems may be affected, but only one actor initiates this transaction.
If there are other use cases that are associated with a subject use case, they can be referenced in the subject use case appendix. Other documents such as a work-flow map can be used to tie together associated use cases and the actors they represent. A use case diagram may also be used to relate various actors in a system and the use cases with which they are associated.
Business vs. System Use Cases
Use cases may be described at the abstract level (business use case, sometimes called essential use case), or at the system level (system use case). The differences between these is the scope.- A business use case is described in technology-free terminology which treats the system as a black box and describes the business process that is used by its business actors (people or systems external to the process) to achieve their goals (e.g., manual payment processing, expense report approval, manage corporate real estate). The business use case will describe a process that provides value to the business actor, and it describes what the process does. Business Process MappingBusiness Process MappingBusiness process mapping refers to activities involved in defining exactly what a business entity does, who is responsible, to what standard a process should be completed and how the success of a business process can be determined. Once this is done, there can be no uncertainty as to the...
is another method for this level of business description. - A system use case describes a system that automates a business use case or process. It is normally described at the system functionality level (for example, "create voucher") and specifies the function or the service that the system provides for the actor. The system use case details what the system will do in response to an actor's actions. For this reason it is recommended that system use case specification begin with a verb (e.g., create voucher, select payments, exclude payment, cancel voucher). An actor can be a human user or another system/subsystem interacting with the system being defined.
Use case notation
In Unified Modeling LanguageUnified Modeling Language
Unified Modeling Language is a standardized general-purpose modeling language in the field of object-oriented software engineering. The standard is managed, and was created, by the Object Management Group...
, the relationships between all (or a set of) the use cases and actors are represented in a use case diagram
Use case diagram
A use case diagram in the Unified Modeling Language is a type of behavioral diagram defined by and created from a Use-case analysis. Its purpose is to present a graphical overview of the functionality provided by a system in terms of actors, their goals , and any dependencies between those use...
or diagrams, originally based upon Ivar Jacobson
Ivar Jacobson
Ivar Hjalmar Jacobson is a Swedish computer scientist, known as major contributor to UML, Objectory, RUP and aspect-oriented software development.- Biography :...
's Objectory
Objectory
Objectory is an object-oriented methodology mostly created by Ivar Jacobson, who is also responsible for object-oriented software engineering....
notation. SysML, a UML profile
Profile (UML)
A profile in the Unified Modeling Language provides a generic extension mechanism for customizing UML models for particular domains and platforms...
, uses the same notation at the system block level.
Limitations
Use cases have limitations:- Use case flows are not well suited to easily capturing non-interaction based requirements of a system (such as algorithm or mathematical requirements) or non-functional requirementsNon-functional requirementsIn systems engineering and requirements engineering, a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that define specific behavior or...
(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).
- There is a learning curve involved in interpreting use cases correctly, for both end users and developers. As there are no fully standard definitions of use cases, each group must gradually evolve its own interpretation. Some of the relations, such as extends, are ambiguous in interpretation and can be difficult for stakeholders to understand.
- Proponents of Extreme ProgrammingExtreme ProgrammingExtreme programming is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements...
often consider use cases too needlessly document-centric, preferring to use the simpler approach of a user storyUser storyIn computer programming a user story is one or more sentences in the everyday or business language of the end user that captures what the user wants to achieve. User stories are used with Agile software development methodologies for the basis of what features that can be implemented...
. - Use case developers often find it difficult to determine the level of user interfaceUser interfaceThe user interface, in the industrial design field of human–machine interaction, is the space where interaction between humans and machines occurs. The goal of interaction between a human and a machine at the user interface is effective operation and control of the machine, and feedback from the...
(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. Within software engineering, this difficulty is resolved by applying requirements traceabilityRequirements traceabilityRequirements traceability is a sub-discipline of requirements management within software development and systems engineering. Requirements traceability is concerned with documenting the life of a requirement and to provide bi-directional traceability between various associated requirements...
through the use of a traceability matrixTraceability matrixA traceability matrix is a document, usually in the form of a table, that correlates any two baselined documents that require a many to many relationship to determine the completeness of the relationship...
. - Use cases can be over-emphasized. In Object Oriented Software Construction (2nd edition), Bertrand MeyerBertrand MeyerBertrand Meyer is an academic, author, and consultant in the field of computer languages. He created the Eiffel programming language.-Education and academic career:...
discusses issues such as driving the system design too literally from use cases and using use cases to the exclusion of other potentially valuable requirements analysis techniques. - Use cases have received some interest as a starting point for test design. Some use case literature, however, states that use case pre- and postconditions should apply to all scenarios of a use case (i.e., to all possible paths through a use case) which is limiting from a test design standpoint. If the postconditions of a use case are so general as to be valid for all possible use case scenarios, they are likely not to be useful as a basis for specifying expected behavior in test design. For example, the outputs and final state of a failed attempt to withdraw cash from an ATM are not the same as a successful withdrawal: if the postconditions reflect this, they too will differ; if the postconditions don’t reflect this, then they can’t be used to specify the expected behavior of tests. An alternative perspective on use case pre- and postconditions more suitable for test design based on model-based specification is discussed in.
- Some systems are better described in an information/data-driven approach than in a functionality-driven approach of use cases. A good example of this kind of system is data-mining systems used for Business Intelligence. If you were to describe this kind of system in a use case model, it would be quite small and uninteresting (there are not many different functions here) but the set of data that the system handles may nevertheless be large and rich in details.
See also
- Business caseBusiness caseA business case captures the reasoning for initiating a project or task. It is often presented in a well-structured written document, but may also sometimes come in the form of a short verbal argument or presentation. The logic of the business case is that, whenever resources such as money or...
- List of UML tools
- User storyUser storyIn computer programming a user story is one or more sentences in the everyday or business language of the end user that captures what the user wants to achieve. User stories are used with Agile software development methodologies for the basis of what features that can be implemented...
- Use case diagramUse case diagramA use case diagram in the Unified Modeling Language is a type of behavioral diagram defined by and created from a Use-case analysis. Its purpose is to present a graphical overview of the functionality provided by a system in terms of actors, their goals , and any dependencies between those use...
- Misuse caseMisuse caseMisuse Case is a business process modeling tool used in the software development business. The term "Misuse case" or "mis-use case" has derived from use case, meaning it is the inverse of a use case. The concept was created in the 1990s by Guttorm Sindre of the Norwegian University of Science and...
Further reading
- Jacobson I., Christerson M., Jonsson P., Övergaard G., Object-Oriented Software Engineering - A Use Case Driven Approach, Addison-Wesley, 1992.
- Alexander I., Maiden N. Scenarios, Stories, Use Cases. Wiley 2004. ISBN 0470861940.
- Aurum A. Cox, K. and Jeffery. An experiment in inspecting the quality of usecase descriptions. Journal of Research and Practice in Information Technology, 36(4):211–229, 2004.
- Phalp K. Cox, K. and M. Shepperd. Comparing use-case writing guidelines. roc. Workshop on Requirements Engineering: Foundation of Software Quality (REFSQ’01), pages 101–112, 2001.
- Colom J.M. Ezpeleta, J. and J. Martinez. Comparing use-case writing guidelines. A Petri net based deadlock prevention policy for flexible manufacturing systems, 11(2):173–184, 1995.
- E. B. Fernandez and J. C. Hawkins. Determining role rights from use cases. In RBAC ’97: Proceedings of the second ACM workshop on Role-based access control, pages 121–125, New York, NY, USA, 1997. ACM Press.
- R. Hurlbut. A survey of approaches for describing and formalizing use-cases. Technical Report 97– 03, Department of Computer Science, Illinois Institute of Technology, USA., 1997.
- Woo Jin Lee, Sung Deok Cha, and Yong Rae Kwon. Integration and analysis of use cases using modular petri nets in requirements engineering. IEEE Trans. Softw. Eng., 24(12):1115–1130, 1998.
- F. Torner, M. Ivarsson, F. Pettersson, and P. Ohman. Defects in automotive use cases. In ISESE ’06: Proceedings of the 2006 ACM/IEEE international symposium on International symposium on empirical software engineering, pages 115–123, New York, NY, USA, 2006. ACM Press.