140 lines
3.2 KiB
Plaintext
140 lines
3.2 KiB
Plaintext
1
|
|
00:00:00,188 --> 00:00:02,360
|
|
Among the requirement that we can collect from the application
|
|
|
|
2
|
|
00:00:02,360 --> 00:00:05,030
|
|
domain, we need to distinguish between two main types. And you've
|
|
|
|
3
|
|
00:00:05,030 --> 00:00:06,540
|
|
probably heard about these ones.
|
|
|
|
4
|
|
00:00:06,540 --> 00:00:09,650
|
|
Functional requirments and non-functional requiremnts. Functional
|
|
|
|
5
|
|
00:00:09,650 --> 00:00:13,020
|
|
requiremetns have to do with the functionality of the system, with
|
|
|
|
6
|
|
00:00:13,020 --> 00:00:16,660
|
|
what the system does with the computation. For example the elevator
|
|
|
|
7
|
|
00:00:16,660 --> 00:00:19,660
|
|
shall take people to the floor they select. That's a functional
|
|
|
|
8
|
|
00:00:19,660 --> 00:00:22,650
|
|
requirement, that has to do with the functionality of the system.
|
|
|
|
9
|
|
00:00:22,650 --> 00:00:25,550
|
|
Or for a very simple one, the system has to output
|
|
|
|
10
|
|
00:00:25,550 --> 00:00:27,620
|
|
the square root of the number past as
|
|
|
|
11
|
|
00:00:27,620 --> 00:00:29,910
|
|
an input. So these kind of requirements have in
|
|
|
|
12
|
|
00:00:29,910 --> 00:00:33,630
|
|
general well defined satisfaction criteria. So, for example, if
|
|
|
|
13
|
|
00:00:33,630 --> 00:00:35,420
|
|
for the latter one that we mentioned it is
|
|
|
|
14
|
|
00:00:35,420 --> 00:00:37,560
|
|
pretty clear how to check whether the output
|
|
|
|
15
|
|
00:00:37,560 --> 00:00:39,784
|
|
is actually the square root of the number passed
|
|
|
|
16
|
|
00:00:39,784 --> 00:00:43,535
|
|
in input. Non-functional requirements, conversely, refer to a system's
|
|
|
|
17
|
|
00:00:43,535 --> 00:00:46,800
|
|
non-functional properties, systems qualities.
|
|
|
|
18
|
|
00:00:46,800 --> 00:00:50,120
|
|
Such as security, accuracy, performance,
|
|
|
|
19
|
|
00:00:50,120 --> 00:00:52,220
|
|
cost. Or, you know, usability,
|
|
|
|
20
|
|
00:00:52,220 --> 00:00:55,910
|
|
adaptability, interoperability, reusability and so
|
|
|
|
21
|
|
00:00:55,910 --> 00:00:58,850
|
|
on. So, all these qualities the don't necessarily have to
|
|
|
|
22
|
|
00:00:58,850 --> 00:01:02,520
|
|
do with the functionality. And, unlike functional requirements, non functional
|
|
|
|
23
|
|
00:01:02,520 --> 00:01:06,060
|
|
requirements Do not always have clear satisfaction criteria. For example,
|
|
|
|
24
|
|
00:01:06,060 --> 00:01:08,670
|
|
if we say that the elevator must be fast, that's
|
|
|
|
25
|
|
00:01:08,670 --> 00:01:10,640
|
|
a non-functional requrement. Right? It has to do with the
|
|
|
|
26
|
|
00:01:10,640 --> 00:01:13,030
|
|
speed of the elevator, which is a quality of the
|
|
|
|
27
|
|
00:01:13,030 --> 00:01:15,535
|
|
elevator. But, it, it's not clear how such a requirement
|
|
|
|
28
|
|
00:01:15,535 --> 00:01:17,980
|
|
could be satisfied. How could we tell whether the elevator
|
|
|
|
29
|
|
00:01:17,980 --> 00:01:20,000
|
|
is fast or not. So, what we need to do
|
|
|
|
30
|
|
00:01:20,000 --> 00:01:22,390
|
|
in these cases Is that we need to refine these
|
|
|
|
31
|
|
00:01:22,390 --> 00:01:25,300
|
|
requirements so that they become verifiable. For the example that
|
|
|
|
32
|
|
00:01:25,300 --> 00:01:27,360
|
|
I just mentioned, for instance, we might say that the
|
|
|
|
33
|
|
00:01:27,360 --> 00:01:30,730
|
|
elevator must reach the requested floor in less than 30
|
|
|
|
34
|
|
00:01:30,730 --> 00:01:33,190
|
|
seconds from the moment when the floor button is pushed.
|
|
|
|
35
|
|
00:01:33,190 --> 00:01:36,030
|
|
This is still a non-functional requirment, but is a verifiable one.
|