[usth/ICT2.7] Engineer software

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.