1
00:00:00,100 --> 00:00:02,510
As I mentioned when we started talking about use cases, use

2
00:00:02,510 --> 00:00:06,040
cases are fundamental in UML, and in general. So, now I

3
00:00:06,040 --> 00:00:08,510
would like to discuss why they're so important and what are

4
00:00:08,510 --> 00:00:11,900
the different roles that use cases can play. The first obvious one

5
00:00:11,900 --> 00:00:15,510
is for requirements elicitation. It is much easier to describe what

6
00:00:15,510 --> 00:00:17,650
the system should do if we think about the system in

7
00:00:17,650 --> 00:00:21,070
terms of scenarios of usage. Rather than trying to describe the

8
00:00:21,070 --> 00:00:25,450
whole functionality of the system at once. So, use cases can help

9
00:00:25,450 --> 00:00:28,890
performing a more effective requirement solicitation. As we will

10
00:00:28,890 --> 00:00:31,700
see when we discuss the unified software process, they can

11
00:00:31,700 --> 00:00:34,980
be used for architectural analysis. So, use cases are the

12
00:00:34,980 --> 00:00:38,165
starting point for the analysis of the architecture of the

13
00:00:38,165 --> 00:00:40,765
system that can help identify the main blocks of

14
00:00:40,765 --> 00:00:44,016
the system. And therefore, can help define in the initial

15
00:00:44,016 --> 00:00:47,360
architecture. And as I said, we'll talk more extensively about

16
00:00:47,360 --> 00:00:50,460
that. They can be used for user prioritization. For example,

17
00:00:50,460 --> 00:00:53,230
imagine to have multiple actors in the system, and you

18
00:00:53,230 --> 00:00:56,160
might want to prioritize some of them. For instance, using

19
00:00:56,160 --> 00:00:59,810
again the banking system example, we might want to first

20
00:00:59,810 --> 00:01:03,477
provide functionality for the administrators of the bank. And only

21
00:01:03,477 --> 00:01:06,384
in a second time provide functionality for the customers, because

22
00:01:06,384 --> 00:01:09,342
of course, if the administrator cannot perform any operation, the

23
00:01:09,342 --> 00:01:12,030
customers cannot use the system. So again, they can be

24
00:01:12,030 --> 00:01:15,980
used to prioritize the users. Or the actors, and therefore

25
00:01:15,980 --> 00:01:19,390
define which part of the system should be built in which order.

26
00:01:19,390 --> 00:01:22,120
Related to this point, they can be used for planning. If I

27
00:01:22,120 --> 00:01:25,000
know which pieces of functionality I need to build and in which

28
00:01:25,000 --> 00:01:27,980
order, I can better plan the development of my system. And again,

29
00:01:27,980 --> 00:01:31,280
we will see how this becomes very important in many different software

30
00:01:31,280 --> 00:01:35,037
life cycles. So, both in the unified software process, for instance, but

31
00:01:35,037 --> 00:01:38,570
also in more agile development processes. And finally, use cases can be

32
00:01:38,570 --> 00:01:40,980
used for testing. If I have an early description of what the

33
00:01:40,980 --> 00:01:44,290
system should do, what are the main pieces of functionality of the system. And I

34
00:01:44,290 --> 00:01:46,700
know how the interaction between the actors and

35
00:01:46,700 --> 00:01:49,510
the system is, I can easily define test

36
00:01:49,510 --> 00:01:52,010
cases, even before writing the code, even before

37
00:01:52,010 --> 00:01:54,180
defining my system. And when we discuss testing,

38
00:01:54,180 --> 00:01:57,590
we will get back to this and talk a little more extensively about this, as well.