For many years Use Cases are used to capture functional requirements of a system. Use Cases describe how "actors" (your system users) use a system to get things done and how the system behaves. Use Cases describe this system-actor interaction in a scenario-based manner where the "basic path" (happy day scenario) is the most common path the actor takes to achieve the required functionality and the error and exceptions paths are possible sideways of the basic path. You have multiple options of detailing these Use Case scenarios: they can be written in pure text (system-actor interaction) or they can be modelled via different modelling techniques: at TVH Parts we are using UML Activity Diagrams and/or UML Sequence Diagrams to model the Use Case scenarios instead of writing them down in plain text.
UML Activity Diagram
UML Sequence Diagram
Whatever technique you choose (textual description or a more diagram-/flow-based technique), the most important thing here is: be consistent. When you choose a specific way of Use Case Scenario modelling, try to use the same chosen technique over and over so that your business audience doesn't get confused. At TVH Parts, the modelled Use Case scenario diagrams are the starting point for more in-depth technical analyses (technical models/diagrams are linked to the Use Case Scenario diagrams) and to split the Use Case scenario up in different User Stories, the so-called Use Case "slices". The Use Case slices (which are in fact fragments of one or more Use Case scenarios) are then linked to User Stories in Jira. The Jira User Stories are the work items for our Development Scrum Teams.
Now that we know something more about Use Cases, let's bring them together in a Use Case Diagram. This diagram helps you to determine the core functions of a system: they offer a blueprint of the system functions, which actors use these functions and how the system functions (Use Cases) are related to each other. As the Use Case Diagram is represented in a graphical manner, it is an easy but effective way to discuss functionalities with various stakeholders (business, developers, end users ...).
So far so good, but where do Use Cases come from? Do they come straight from the business users as they will be the actors that will use the system functionality? The reality is that most users have difficulties in explaining what functions they want from a system. Often users have a "vague idea", but many of them have difficulties in explaining what they really want in a structured/abstract manner. Creating Use Cases "out of the blue" is difficult for most business users. Here's where our business process models can help out: they form a good starting point for "harvesting" Use Cases straight from the business process model.
Back to Use Cases and their correlation to Business Processes: does this mean that all the tasks/activities modelled on a business process model are Use Cases? No, some of these modelled tasks/activities "can" be candidates for automation (software systems) or even some tasks grouped together can be candidates for a single Use Case. It is not as simple as just mapping business activities/tasks one-to-one to Use Cases. As a rule of thumb, we can say that activities/tasks on a business process model that can be automated are good candidates for Use Cases, but Use Cases should yield an observable result (business goal/value) for the actor executing the Use Case. So for example: "Place Order" is likely to be a valid Use Case candidate, "Input Customer Number" is not because there’s no business value in inputting the customer number. Inputting the Customer Number is part of a scenario of another Use Case (e.g. Place Order where in the last order step the Customer Number should be inputted).
Keep in mind: there's an important difference between Business Processes and Use Cases: Business processes are seen from a business perspective; they describe business activities and are technology independent. Use Cases are seen from an actor (use) perspective, they describe software functions and behaviour and are system (technology) specific. Use Cases can be seen as the "missing" link between the pure business process description and the system (software) realisation of the business process. Take this example: the business process of "Placing an Order" just describes the activities the business is doing in order to get the order placed without considering system implementations, technology ..., while a similar Use Case describes the interactions the actor has with the software system and how the software system behaves when placing an Order.