Our Process
Use Cases
Software deployment is a challenge not only because of technical difficulties. If software is to make any sense at all, it is important for it to be tailored to users needs.
Then, the key question here is: “What will the users do with our software?”
User- and use-focused solutions can be of assistance in answering this question.
They will enable us to implement key features as well as protect us against adding functionalities that will be of no interest to the users.
Keep in mind that user requirements do not only apply to the functional aspect. They are also related to business requirements.
A person with no experience in digital business is faced with a difficult question about how to know the user intentions.
One of the most popular techniques enabling you to do that are Use Cases. With their help, we can understand user requirements in relation to many types of projects.
Use Case as a description of sequence of interactions
Use Cases describe the sequence of interactions between a system and an actor, where it is important for the actor to reach a defined goal, e.g. change profile data in an online store.
Let’s consider a simple example. Picture this: you enter an online bookstore website and you find out that your profile data are no longer up-to-date because you changed your residence address. So, the change of profile data will be a Use Case here.
Use Case – example
Use Case will be as follows:
‘Bookstore: Update your customer profile’.
Use Case is often confused with User Stories. The difference is simple: User Stories go beyond defining a goal to be reached by a user. They also describe motivation behind the goal.
For example:
“I want to update my customer profile in order for my future purchases to be delivered to my new address.”
Use Cases vs User Story
When dealing with Use Cases, a business analyst teams up with users.
He or she can then find out how they imagine a dialog with a system designed for a specific purpose. The collected data enable you to structure it in line with use template.
A Use Case will enable you to determine what functional requirements should be considered by developers. A tester’s task will be to check if a specific case has been implemented correctly.
However, remember that a Use Case should not specify details of a project, as its aim is to focus on user ideas. Use Cases will allow us to show the project participants the structure and context.
For acceptance tests, Agile teams focus on the development of User Stories. Such tests allow you to learn to what extent the user requirements have been met.
A major advantage of these tests is that they are conducted at an early stage of work.
But when we’re talking about common features of Use Cases and User Stories, it is worth to note that Use Cases and User Stories focus on what the users want to achieve, and not on their ideas of what a system should do.
As regards these two methods, our job is to describe the tasks the users will need to perform in a system (or to identify the user-system interactions).
What can Use Cases be helpful with?
The developers do not implement business or user requirements. They code functional and extra-functional requirements of a program.
It is equally impossible to create functional requirements without knowing the users needs and business requirements.
Use Cases describe software user interactions from the perspective of the user, i.e. from the side of visible system behavior. While functional requirements result from the requirements of Use Cases, and describe specific components of system behavior.
Correctly formulated Use Cases are necessary to develop Software Requirement Specification which as a result includes both functional and extra-functional requirements.
Furthermore, Use Cases provide guidelines for user interface design. In addition, every Use Case is helpful in acceptance tests.
A list of Use Cases allows you to preliminarily estimate the time needed for software deployment, as their description allows you to understand the system complexity.
Work on Use Cases
We have already mentioned Use Case diagrams. It is worth to look at them in more detail, as they enable you to present system functionalities and its surroundings.
A diagram allows you to create a graphical depiction of system features including the functionalities visible on the user side. It enables you to present the services visible outside the system.
A diagram is composed of functional requirements and system surroundings. It is a kind of aggregate of system service functions.
In addition to the presentation of the specification, it also allows you to identify functionalities and to verify modeling and implementation progress.
Its advantage also lies in the fact that it supports the communication between the project participants.
A diagram enables you to define the requirements for the system, i.e. what the system should do from the point of view of its surroundings. It also defines the boundaries of a system, i.e. of its surroundings and components interacting with it.
Basic applications of a diagram are, first of all, definition and clarification of system functions. Usually, Use Cases necessitate new requirements.
Secondly, communication with customers. Naming simplicity and intuitiveness make Use Case diagrams a good way of communication between designers and future system users.
Plus, test cases are generated. A description of a specific Use Case can suggest testing methods as well as specific test data and better understanding of different system use scenarios.
Diagrams enables system designers and its future users to communicate more effectively.
When both, Use Cases and User Stories work well?
Both, Use Cases and User Stories form an important part of every software design process. They are indispensable in web applications, mobile applications or subscription services.
They will assist you in creating websites. Wherever software is used, you need to find out what a program is supposed to do to fulfill the users needs.
Actor is important in Use Cases
When talking about Use Cases, the term ‘actor’ frequently pops up. It concerns a role that a user plays in relation to a system and Use Cases as well. It has to do with the fact that every user carries out a specific use scenario.
A Use Case is a set of interconnected use scenarios, and a scenario is a specific execution of a Use Case.
An actor should also be understood as a set of roles played by the users. These roles are played by Use Case users when interacting with this Case.
It is crucial for the actor to perform a specific function in relation to the system and Use Case he/she is using. Importantly, actor is not a part of a system, but is situated ‘outside’ so to speak, and must interact with at least one Use Case.
Actor and system in Use Cases
- An actor is a particular role in relation to a system.
- An actor does not always mean a specific individual. One person can log into the system as a user, and at other time as an administrator.
- An actor can represent an entire group of individual system users.
- Actors are not always active, e.g. an actor approving a bank transfer.
How to write Use Cases?
You should be careful not to write too many Use Cases. Better not to write a separate Use Case for every possible scenario.
A minimalistic approach is also important when describing a Use Case. We are talking about a description several pages long. The flow should not include more than 10 to 15 steps.
A simple example: you should write “System allows you to choose” instead of “System displays drop down list”.
So, the idea is for the Use Cases to focus on what the users want to achieve, and not on the screen design. Also, avoid including data definitions in Use Cases.
Last tip you should keep in mind concerns the Use Cases which are not understood by the users. It is important to write Use Cases from the perspective of a user, and not from the point of view of a system.
Use Cases should be as simple as possible. That is why you can ask the users to assess them.
Use Case — history and conclusion
Use Case is a sequence of operations performed by a system. They are initiated by an actor who is an abstraction, a user assigned a specific role at a given point in time.
On the one hand, a Use Case models the expected system behavior towards an actor. On the other hand, it does not specify how to implement this behavior.
A Use Case entails a goal, and usually a Use Case itself describes a longer process.
Let us add that the name of a Use Case usually includes a noun defining the purpose of case activation, preceded by a verb describing the type of activity.
As a result of work on a Use Case, you define its documentation. Drawings or a mockup of a user interface are very helpful, as they allow you to create a specific case description more easily.
You can also offer the above mentioned activity diagram which in UML serves to model activities and scope of responsibility of the system components or users.
UML (Unified Modeling Language) is a semi-formal language used for modeling systems of various types. It was created by Grady Booch, James Rumbaugh and Ivar Jacobson. Currently, it is developed by Object Management Group.
It is worth to mention here the origins of Use Cases, which date back to 1986. It was then that Ivar Jacobson, a computer scientist involved in the creation of Unified Modeling Language (UML) and Rational Unified Process (RUP), described the technique for specifying Use Cases.
Although you should bear in mind that initially he used the terms ‘usage scenarios’ and ‘usage cases’. Already in the 1990s, Use Cases became a widely used method for the description of functional requirements.
Use Cases (similarly to User Stories) are the basis for the deployment of software which will meet the users needs.
The use of Use Cases protects us against developing software which will not meet the user expectations.
Without necessary knowledge, you can easily ignore the implementation of the most important functions as well as add useless functionalities. Also, with Use Cases business requirements can be fulfilled.
In the process of working on product design and Use Cases we need to get to know our user well. It is facilitated by the use of personas.
By persona we mean a user (customer) representation.
This enables you to create a digital product not only for your own company, but in response to a market need. Consequently, it allows you to acquire traffic and create a Sales Funnel. You can read more about Sales Funnel in our article.