1 files changed, 139 insertions, 0 deletions
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/19 - Functional and Nonfunctional Requirements - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/19 - Functional and Nonfunctional Requirements - lang_en_vs4.srt
new file mode 100644
index 0000000..1cff519
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/19 - Functional and Nonfunctional Requirements - lang_en_vs4.srt
@@ -0,0 +1,139 @@
+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.