Hello. I am Alejandro Rodríguez Ascaso,
lecturer at the Department of Artificial Intelligence at UNED.
In this video, we are going to look at how to develop a use case,
which is part of a broader task: the creation of user requirements.
As part of this creation of user requirements,
we need to describe
the functional requirements of the system;
that is, what the user does with the system.
We do not utilise use cases to describe how the interaction
between the user and the system takes place.
We describe the function,
but to explain how that interaction occurs,
we will prepare the non-functional requirements.
A use case represents the vision the system has
of a user who is external to it.
It expresses a transaction,
an interaction between the user and the system.
For example, a user calling a lift,
a peripheral requesting data from a central computer,
as in the case we are about to see,
a person who uses speech recognition to use their computer,
and, specifically, to edit a text document.
(CLAUDIA) I am going to show you the speech-recognition system that I use:
Dragon NaturallySpeaking.
This software must be purchased.
You install the software like any other,
and once that's done, you automatically begin training it.
To improve voice recognition,
Dragon NaturallySpeaking gives us an option to train it.
So let's begin.
"Wisdom pursues me, but I am faster"
a phrase written on a Spanish university desk.
"Nothing is so stupid as to vanquish; the real glory is to convince."
Victor Hugo.
One of the most useful tools that speech recognition software provides,
especially at first, is its support feature.
Once you install it, it takes you
on a walkthrough of the Dragon Speaking software
that helps you see all the different configuration options
and clears up any doubts.
And for new users, it is very advisable to read this help page carefully.
Dragon allows you to create different profiles,
meaning not only can I use this speech-recognition system,
but also the people around me, which can be much more productive.
Now I am going to start the speech-recognition system
to write a document.
I have opened the Word processor and turned it on.
"Dear Margarita, comma."
"Everything’s going great." "Start new line."
"We are..."
"Undo."
With this command, I delete the previous word.
"Go to sleep."
With this command, I tell the speech-recognition system
to stop recognising my voice
so that I can speak to the person next to me.
This is useful when we want to write an acronym
or add a word that does not appear in the Spanish vocabulary.
We will activate the spelling command: "Spell."
O...
N...
U.
A use case contains several elements.
On one hand, the use cases themselves
consist of a sequence of actions and possible variants of these
between the system and the actors.
And then the actors, the people or sets of roles
performed by users when they interact with the use cases.
In our case, we have several actions,
for example, requesting help to learn how to use the system;
selecting one of the users configured to use the system;
training the system so that it recognises my voice better over time;
activating the speech-recognition system to dictate or edit a text;
and deactivating speech recognition.
The type of user we are talking about is the client, the end user:
the person who uses the speech recogniser and the text editor.
But there might be other roles or actors,
for example, an installer, the person who may assist a user
to sell them the product, install it, or repair it.
There are many roles concerning ICT products.
The parts of the use case are the following.
On one hand, the diagram, the one we have just seen,
a UML diagram,
and on the other hand, the description of the use case.
In that description of the use case,
we provide slightly more complete information
that is not included in the diagram,
such as the general description of the use case.
Here we see that the user can, in general, request help,
configure the user, train the system,
and use voice recognition to edit texts.
The version, the date, which actors participate in the use case,
and then we can include a brief description
to define the basic course of action,
that is, the steps that are necessary
to provide this set of functions that our system offers.
There may be an alternative course.
It may happen that this basic course of action
suffers a small modification on some occasions.
It is also necessary to state a series of preconditions,
what we assume has happened beforehand,
so that this use case can take place.
In our case, in which the user is using the voice-recognition system,
we say that we assume that the user has approached the computer,
that it is switched on,
that the voice-recognition and word-processing programmes
have been previously installed and executed,
there is a microphone that is correctly installed,
connected to the sound card,
and that the sound card is configured
so that the microphone signal reaches the computer properly
and the voice recogniser can do its job.
There may also be a series of postconditions,
conditions that arise after this use case ends
and which may in turn become preconditions
for another use case to take place.
Two tools can help us generate our UML use-case diagrams:
extends and include.
"Include" is used to add a sub-function within a step of a use case.
We are talking about a subset of the functionality
established by that more general use case.
In the video we have just seen,
we could describe "Edit text" as a sequence or iteration
of "Enter paragraph", "Start new line", and "Undo".
On the other hand, we have "Extends".
"Extends" allows us to add a sub-function
that does not always occur, only occasionally,
in exceptional situations.
For example, spelling a word when entering text.
We only do that when, for instance,
that word is unknown to our voice recognition software.
Let us stop for a moment to reflect on all this.
Let us remember that "Edit text" was a step within a previous use case,
the general one,
but it has acquired a complexity of its own
that makes it deserving of creating a new use case.
To create this use case, we will generate a specific table
in which we will record a description,
the basic course of action, preconditions, etc.
Well, as the saying goes, everyone has their own way of doing things,
and there are multiple ways of defining a task through use cases.
The important thing is that whichever we choose,
the system’s functionality is described fully and coherently
with the objective of preparing user requirements.
For example, here we have our user,
who, in order to edit texts,
we can think of dividing it into entering words,
entering punctuation marks, starting a new line, and undo,
another decomposition of functionality,
but one that can still serve our purpose.
In summary, we can say that we utilise use cases to describe functionality.
It is important to emphasise
that we do not include aspects of accessibility or usability.
A single use case should generally apply
to two people with different accessibility needs,
because it refers exclusively to the system’s functionality.
Furthermore, we have seen that the elements of the use case
are the use cases themselves and the actors.
We have also seen that use cases consist of a UML diagram
and a textual description
that provides some information not contained in the UML diagram.
We have also seen the use of "include" and "extends".
And that is all.
Here we finish this video on developing use cases
as part of user requirements.
Until the next video.