Introduction to Use case. Difference between Business and System use case.

Introduction to Use case.
An organization has different departments in it and the people here are from different educational backgrounds. Based on this, their work also differs from that of people working in other departments. But, all these departments are trying to achieve a common goal (micro goals differs from each other’s). To achieve this, they all need to work together in one direction by employing their unique skill sets. So how does one convey the message or an idea such that all these people shall understand it in same way without any gaps/misunderstandings/disagreements? This is where use case comes to rescue. They assist in communicating the message to diverse group of people to make them understand it as intended.

Use cases are high-level UML diagrams and considered as mother of all diagrams; these helps in understanding how a user or a system interacts with the solution to achieve a desired goal. Hence, it is drawn from an end user’s perspective. They describe the flow of events which are performed by the user to achieve the desired goal. In use case diagrams we model only Basic flow (series of direct actions performed by the user to achieve the desired goal without facing any challenges), there are alternative flows and exceptional flow which are not modeled but are written as use case specifications in textual manner.

In alternate flow, the alternative options those are available to a user to achieve the desired goal when they’re finding difficulties to achieve the goal by following basic flow will be written in textual manner.

In exceptional flow, the response by the system when the user is not able to achieve their desired goal is specified. The reasons could be many factors such as system error, disrupted network connection, system maintenance and alike. This will explain the scenarios which would prevent a user from achieving their desired goal.

Elements of use cases?

Use case diagrams are comprised of-
1. Primary actor- the user who triggers the solution to perform a process.
2. Secondary actor- the user or organization on which the solution is dependent for supporting its functionalities.
3. Association- a straight line that expresses relationship between actors and the solution. Association lines indicate that the user has access to the functions in the solution.
4. Use case- function that the solution should’ve which will be accessed by the actors.
5. System boundary- is the solution itself, anything and everything happening within that system.

Notes:
1. The actors are always outside the system boundary.
2. Database, servers, brand names, technologies will not be modeled in the use case.
3. Existence of secondary actor is solution dependent and not mandatory to exist in all the solutions.
4. Physical actions by actors are not modeled in the system use case diagram.

Business use case vs. System use case.

Business use case.

I. Business use case is written at high level. How a user outside to the organization interacts with respect to particular business process or functions to achieve their desired goal.
II. How the actor interacts with the business and the basic flows involved in it to achieve the desired are modeled.
III. The organization will have no control on the user’s behavior.
IV. Defines the user requirements specification.
V. Business processes are more of a paper based. Meaning, no technology is required to achieve the goal. However, with digitalization all business processes are evolving from paper model to e-model.

Example for business use case:
In a car dealership- customer visit dealership at his scheduled time, question sales people, test different models and then book the one he likes.

System use case.
I. This involves use case for solutions developed on computer systems.
II. It is written in low level. How the user interacts with the solution to achieve their desired goal.
III. Detailed functional specification is elaborated in the diagram. Their dependencies, the internal supporting features and internal optional features will be modeled.
IV. Involvement of a human actor is dependent on the solution and the scope of the solution. Meaning, an automated solution doesn’t need a human actor.
V. Design scope of the solution is described.
VI. Details about different features and integration of the solution functionalities are modeled.
VII. Unlike business use case, control over user’s behavior lies with the solution.

Example for system use case:
In a car dealership- how customer schedules his appointment through a web app, makes online payment for the model he likes.