.png)
Use cases are a widely used method for capturing and specifying requirements. The concept of use cases is not new and has been around since at least 1999 (Jacobson, I., Booch, G., & Rumbaugh, J. (1999). The Unified Software Development Process).
Despite its established position in the market, the term "use case" is often misused in the business analyst community within the IT industry, deviating from its defined meaning. Some confuse use cases with business process descriptions, while others associate them with user stories. There are also those who equate the concept with the UML language, which is somewhat correct since UML includes the use case diagram, but use cases exist beyond UML as well.
Different sources, such as Cockburn, Jacobson, Fowler, and the UML (Unified Modeling Language), provide varying perspectives on the concept of use cases in software development. While these sources share commonalities, they also have unique interpretations and approaches.
Below I present an abbreviated explanation of the use case concept according to authors considered experts in the field.
Alistair Cockburn
According to Cockburn, a use case is a sequence of interactions between a system (software, hardware, or both) and one or more actors (individuals, systems, or devices). Use cases describe the functionality of a system from the user's perspective and capture how users interact with the system to achieve specific goals. Cockburn emphasizes the importance of focusing on user goals and intentions when defining use cases.
Source: Cockburn, A. (2000). Writing Effective Use Cases.
Ivar Jacobson
Jacobson's approach to use cases involves capturing the functional requirements of a system by describing its interactions with users. Jacobson introduced the concept of use case diagrams, which visually represent the relationships between actors and use cases. He also emphasizes the use of use cases throughout the entire software development lifecycle. Ivar Jacobson is also one of the authors of the UML language.
Source: Jacobson, I., Booch, G., & Rumbaugh, J. (1999). The Unified Software Development Process.
Martin Fowler
Fowler defines use cases as a textual description of interactions between actors and a system to achieve a specific goal. He emphasizes the collaborative nature of use cases, where actors and systems work together to accomplish tasks. Fowler also highlights the importance of keeping use cases concise and focused.
Source: Fowler, M. (2004). UML Distilled: A Brief Guide to the Standard Object Modeling Language.
It is worth noting that most (if not all) experts defines a use case as an interaction between an actor and a system. The definitions also commonly state that a use case is a way to capture functional requirements.
How does this relate to the belief held in some environments that a use case is used to describe a business process? By definition, a use case does not describe a business process understood as a series of interconnected activities, tasks, or steps performed within an organization to achieve a specific business objective.
There are, of course, many sources defining the concept of a process. Below are definitions according to OMG, BABOK, and BMM:
Object Management Group (OMG)
The OMG defines a business process as a collection of related, structured activities that involve a combination of people, systems, and information. It aims to achieve specific business objectives, such as providing a product or service, managing resources, or satisfying customer needs. Business processes often cross organizational boundaries and can be modeled, analyzed, and optimized to improve efficiency and effectiveness.
Source: Object Management Group (OMG). (2011). Business Process Model and Notation (BPMN) Version 2.0.
Business Analysis Body of Knowledge (BABOK)
BABOK defines a business process as a set of interrelated activities that transform inputs into outputs, with the goal of achieving specific business objectives. It encompasses the sequence of steps, decision points, and control flow necessary to accomplish a business outcome. Business processes are essential for understanding and improving how organizations operate.
Source: International Institute of Business Analysis (IIBA). (2015). A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3.
Business Motivation Model (BMM)
According to the BMM, a business process represents a series of related activities, events, and decisions that organizations undertake to achieve their strategic goals. Business processes are an integral part of the overall business architecture and contribute to the realization of the organization's vision and mission. They can be documented, analyzed, and refined to align with the strategic direction of the organization.
Source: OMG Business Architecture Working Group. (2010). Business Motivation Model (BMM) Version 1.3.
BPMN (Business Process Model and Notation)
In BPMN, a business process is defined as set of business activities that represent the steps required to achieve a business objective. It includes the flow and use of information and resources.
Source: Object Management Group (OMG). (2014). Business Process Model and Notation (BPMN) Version 2.0.
All these definitions highlight the common understanding that business processes involve a series of activities aimed at achieving specific business goals or outcomes.
The concept of a business process pertains to the business layer, not the technological layer. So, how can a use case - an interaction between an actor and a system - represent a BUSINESS process?
While a traditional use case, defined as an actor-system interaction, may not directly represent a business process, there is an approach that bridges this gap: the concept of a business use case. This idea is often employed, for instance, in the Rational Unified Process (RUP).
A business use-case instance is a sequence of actions performed in a business that produces a result of observable value to an individual actor of the business.
According to Rational Unified Process (RUP), a business use case refers to a specific type of use case that focuses on the business aspect of a system. It captures the interactions between business actors and the system to achieve business-related objectives and deliver value to the organization.
A business use case in RUP typically emphasizes the business processes, activities, and outcomes rather than technical system details. It helps in understanding how the system supports and enables the business processes and how it contributes to achieving the organization's goals.
In this sense, a business use case can be used to express a business activity (whether it's a good method for documenting business processes - that's another topic entirely).
By introducing the notion of a business use case, we can connect the actor-system interaction (traditional use case) to the broader context of a business process. It provides a means to explicitly model and analyze the system's role in supporting and enabling business processes.
Use cases can therefore be divided into system use case and business use case. The system use case deals with the solution layer and describes the interaction of an actor (to simplify the system user) with the system. A business use case describes the business layer and depicts the interaction of a business actor with a business function, for example. The business actor does not have to be a user of the target solution at all.
What can be inferred from the above analysis is that use cases were conceived for presenting interactions with the system and describing functional requirements.
They can be applied to modeling the business layer as well, but in such cases, it is beneficial to adjust the naming convention and instead of simply referring to use cases, use the term "business use cases" to better align with the business context and ensure proper understanding.
Comments