diff options
Diffstat (limited to 'usth/ICT2.7/P2L1 Requirements Engineering Subtitles/16 - Defining Requirements - lang_en_vs4.srt')
-rw-r--r-- | usth/ICT2.7/P2L1 Requirements Engineering Subtitles/16 - Defining Requirements - lang_en_vs4.srt | 219 |
1 files changed, 0 insertions, 219 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 deleted file mode 100644 index 2c8dde2..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/16 - Defining Requirements - lang_en_vs4.srt +++ /dev/null @@ -1,219 +0,0 @@ -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. |