1
00:00:00,250 --> 00:00:01,940
Now we are at the point in which we

2
00:00:01,940 --> 00:00:05,590
have collected and modeled our requirements. So the next thing

3
00:00:05,590 --> 00:00:08,310
that we can do is to analyze the requirements to

4
00:00:08,310 --> 00:00:11,720
identify possible problems, and specifically there are three types of

5
00:00:11,720 --> 00:00:14,646
analysis that we can perform. The first type of analysis

6
00:00:14,646 --> 00:00:16,820
is verification. So in this case we're talking about the

7
00:00:16,820 --> 00:00:19,700
requirements verification. And in verification

8
00:00:19,700 --> 00:00:21,990
developers will study the requirements

9
00:00:21,990 --> 00:00:25,270
to check whether they're correct, whether they accurately reflect the

10
00:00:25,270 --> 00:00:28,710
customer needs as perceived by the developer. Developers can

11
00:00:28,710 --> 00:00:32,170
also check the completeness of the requirements, check whether there

12
00:00:32,170 --> 00:00:34,510
are any missing pieces in the requirements as we

13
00:00:34,510 --> 00:00:37,710
discussed earlier. They can check whether the requirements are pertinent,

14
00:00:37,710 --> 00:00:41,260
or contain irrelevant information, like the one shown here.

15
00:00:41,260 --> 00:00:44,670
And they can also check whether they're consistent, unambiguous, testable

16
00:00:44,670 --> 00:00:46,920
and so on, so all those properties that should

17
00:00:46,920 --> 00:00:50,380
be satisfied for the requirements. A second type of analysis

18
00:00:50,380 --> 00:00:53,670
that is typically performed on requirements is validation. And

19
00:00:53,670 --> 00:00:56,290
the goal of validation is to assess whether the collected

20
00:00:56,290 --> 00:00:59,870
requirements define the system that the stakeholders really want.

21
00:00:59,870 --> 00:01:02,330
So the focus here is on the stakeholders. And in

22
00:01:02,330 --> 00:01:05,670
some cases, stakeholders can check the requirements directly if

23
00:01:05,670 --> 00:01:08,910
the requirements are expressed in a notation that they understand.

24
00:01:08,910 --> 00:01:11,120
Or they might check them by discussing them with the

25
00:01:11,120 --> 00:01:15,490
developers. Another possibility is that stakeholders asses the requirements by

26
00:01:15,490 --> 00:01:18,400
interacting with a prototype of the system, in case

27
00:01:18,400 --> 00:01:21,690
the requirements engineering process that is being used involves

28
00:01:21,690 --> 00:01:25,300
early prototyping. And finally surveys, testing, and other techniques

29
00:01:25,300 --> 00:01:28,400
can also be used to validate requirements. A final type

30
00:01:28,400 --> 00:01:30,780
of analysis that we can perform on requirements is

31
00:01:30,780 --> 00:01:34,430
risk analysis. And risk analysis aims to identify and

32
00:01:34,430 --> 00:01:37,680
analyze the main risks involved with the development of

33
00:01:37,680 --> 00:01:40,560
the system being considered. And if some requirements are deemed

34
00:01:40,560 --> 00:01:43,320
to be too risky, like in this case, this might result in

35
00:01:43,320 --> 00:01:47,880
changes in the requirements model to eliminate or address those risks. And note

36
00:01:47,880 --> 00:01:49,950
that all these analysis activities can

37
00:01:49,950 --> 00:01:52,390
be performed in many different ways depending

38
00:01:52,390 --> 00:01:53,990
on the modeling languages chosen to

39
00:01:53,990 --> 00:01:56,150
represent the requirements and on the context.