1 files changed, 219 insertions, 0 deletions
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/16 - Defining Requirements - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/16 - Defining Requirements - lang_en_vs4.srt
new file mode 100644
index 0000000..2c8dde2
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/16 - Defining Requirements - lang_en_vs4.srt
@@ -0,0 +1,219 @@
+1
+00:00:00,220 --> 00:00:02,120
+So at this point, we have talked quite a bit about
+
+2
+00:00:02,120 --> 00:00:03,800
+requirements engineering, but we haven't
+
+3
+00:00:03,800 --> 00:00:06,450
+really discussed what are requirements exactly.
+
+4
+00:00:06,450 --> 00:00:08,880
+So what is a requirement? To define that I am going
+
+5
+00:00:08,880 --> 00:00:11,860
+to use this diagram which is a classical one. So you might
+
+6
+00:00:11,860 --> 00:00:14,980
+have seen it before. So, discussing this diagram allows me to
+
+7
+00:00:14,980 --> 00:00:18,720
+point out a few interesting things about requirements and define them
+
+8
+00:00:18,720 --> 00:00:21,660
+in a better way. At a high level this diagram contains
+
+9
+00:00:21,660 --> 00:00:24,780
+two main parts, the domain of the machine, which is the hardware,
+
+10
+00:00:24,780 --> 00:00:27,670
+operating system, libraries and so on, on which the
+
+11
+00:00:27,670 --> 00:00:30,860
+software will run. And the domain of the application, which
+
+12
+00:00:30,860 --> 00:00:33,510
+is a world in which the software will operate.
+
+13
+00:00:33,510 --> 00:00:36,690
+And the machine domain is characterized by computers, which are
+
+14
+00:00:36,690 --> 00:00:39,980
+the hardware devices, and programs, which is the software
+
+15
+00:00:39,980 --> 00:00:43,430
+that runs on these devices. The application domain, conversely, is
+
+16
+00:00:43,430 --> 00:00:47,370
+characterized by domain properties, which are things that are true
+
+17
+00:00:47,370 --> 00:00:50,330
+of the world anyways, whether I'm building my system or
+
+18
+00:00:50,330 --> 00:00:53,510
+not, and requirements, which are things in the world we
+
+19
+00:00:53,510 --> 00:00:56,220
+would like to achieve by delivering the system that we are
+
+20
+00:00:56,220 --> 00:00:59,400
+building. Basically, to put it in a different way, the former,
+
+21
+00:00:59,400 --> 00:01:02,950
+the domain properties, represents the assumptions that we make on the
+
+22
+00:01:02,950 --> 00:01:06,740
+domain. And the latter, the requirements, are the actual requirements
+
+23
+00:01:06,740 --> 00:01:09,660
+that we aim to collect. So we have something here, right,
+
+24
+00:01:09,660 --> 00:01:13,380
+at the intersection of this application domain and this machine domain.
+
+25
+00:01:13,380 --> 00:01:15,570
+And what is that? And this is what we normally call
+
+26
+00:01:15,570 --> 00:01:19,225
+the specification, which is a description, often a formal description,
+
+27
+00:01:19,225 --> 00:01:22,120
+of what the system that we are building should do to
+
+28
+00:01:22,120 --> 00:01:25,520
+meet the requirements. So this is a bridge between these two
+
+29
+00:01:25,520 --> 00:01:29,380
+domains. And as the graphical depiction shows, the specification is written
+
+30
+00:01:29,380 --> 00:01:33,220
+in terms of shared phenomena. Things that are observable in both
+
+31
+00:01:33,220 --> 00:01:35,980
+the machine domain and the application domain. And just to make
+
+32
+00:01:35,980 --> 00:01:37,540
+things a little more concrete, I want to give you a
+
+33
+00:01:37,540 --> 00:01:41,180
+couple of examples of what these phenomena, these shared phenomena, are.
+
+34
+00:01:41,180 --> 00:01:43,350
+And we can think about two main kinds of phenomena.
+
+35
+00:01:43,350 --> 00:01:46,080
+The first one are events in the real world that the
+
+36
+00:01:46,080 --> 00:01:50,140
+machine can directly sense. For example, a button being pushed or
+
+37
+00:01:50,140 --> 00:01:53,910
+a sensor being activated. These are events that happen here, but
+
+38
+00:01:53,910 --> 00:01:56,500
+that the machine can detect. So they're events that can
+
+39
+00:01:56,500 --> 00:01:59,650
+be used to define the specification. And the second type of
+
+40
+00:01:59,650 --> 00:02:02,890
+phenomena are actions in the real world that the machine can
+
+41
+00:02:02,890 --> 00:02:06,380
+directly cause. For example, an image appearing on a screen or
+
+42
+00:02:06,380 --> 00:02:09,300
+a device being turned on and off. Again, this is something
+
+43
+00:02:09,300 --> 00:02:12,460
+that the machine can make happen and then can have manifestation in
+
+44
+00:02:12,460 --> 00:02:15,520
+the real world. And again this is therefore something on which
+
+45
+00:02:15,520 --> 00:02:17,720
+the specification can predicate, something that
+
+46
+00:02:17,720 --> 00:02:19,750
+we can describe in our specification.
+
+47
+00:02:19,750 --> 00:02:22,860
+And this is sort of a philosophical discussion, but even if
+
+48
+00:02:22,860 --> 00:02:26,210
+you don't care about the philosophical discussion, the one take away point
+
+49
+00:02:26,210 --> 00:02:28,800
+that I would like for you to get from this discussion is
+
+50
+00:02:28,800 --> 00:02:31,392
+the fact that when writing a specification you have to be aware
+
+51
+00:02:31,392 --> 00:02:34,860
+of the fact that you're talking about shared phenomena. Events in the real
+
+52
+00:02:34,860 --> 00:02:39,100
+world that the machine can sense and actions in the real world that the
+
+53
+00:02:39,100 --> 00:02:43,048
+machine can cause. So this is what the specification is about, a bridge between
+
+54
+00:02:43,048 --> 00:02:44,760
+these two worlds that define what the
+
+55
+00:02:44,760 --> 00:02:47,170
+system should do to satisfy the requirements.