[usth/ICT2.7] Engineer software

author: Nguyễn Gia Phong <mcsinyx@disroot.org> 2020-05-24 16:34:31 +0700
committer: Nguyễn Gia Phong <mcsinyx@disroot.org> 2020-05-24 16:34:31 +0700
commit: b2d80610db6beda38573890ed169815e495bc663 (patch)
tree: 176e1bca6fe644c619d53cf1c24682c244b79cf6 /usth/ICT2.7/P2L1 Requirements Engineering Subtitles
parent: 49376ab97c7427f1c1eca64072d1a934c2e52f50 (diff)
download: cp-b2d80610db6beda38573890ed169815e495bc663.tar.gz
33 files changed, 3747 insertions, 0 deletions
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/1 - Lesson Overview - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/1 - Lesson Overview - lang_en_vs4.srt
new file mode 100644
index 0000000..27581a6
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/1 - Lesson Overview - lang_en_vs4.srt
@@ -0,0 +1,55 @@
+1
+00:00:00,340 --> 00:00:05,670
+Hello and welcome to the second part of our software engineering course. In the
+
+2
+00:00:05,670 --> 00:00:09,030
+previous mini-course, we discussed some basic principles
+
+3
+00:00:09,030 --> 00:00:12,430
+behind software engineering. We provided an overview of
+
+4
+00:00:12,430 --> 00:00:15,790
+several software process models and we introduced
+
+5
+00:00:15,790 --> 00:00:18,530
+some important tools that can help developers
+
+6
+00:00:18,530 --> 00:00:21,363
+increase their productivity. In this mini-course, we
+
+7
+00:00:21,363 --> 00:00:25,740
+will focus on requirement and prototyping. More precisely,
+
+8
+00:00:25,740 --> 00:00:28,840
+we will discuss in depth requirements
+
+9
+00:00:28,840 --> 00:00:32,400
+engineering activities. We will also discuss
+
+10
+00:00:32,400 --> 00:00:34,950
+techniques to perform a system analysis
+
+11
+00:00:34,950 --> 00:00:38,720
+and design in an object-oriented fashion. So,
+
+12
+00:00:38,720 --> 00:00:42,250
+let's start the first lesson of this mini-course, which is about the use
+
+13
+00:00:42,250 --> 00:00:45,230
+of engineering techniques to understand and
+
+14
+00:00:45,230 --> 00:00:48,450
+specify the purpose of a software system.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/10 - Completeness Quiz - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/10 - Completeness Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..1ab5b4a
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/10 - Completeness Quiz - lang_en_vs4.srt
@@ -0,0 +1,15 @@
+1
+00:00:00,130 --> 00:00:03,060
+So now that we saw which of these requirements are pertinent and
+
+2
+00:00:03,060 --> 00:00:06,520
+which ones are not, can we consider the above list of requirements
+
+3
+00:00:06,520 --> 00:00:09,710
+of the list of these requirements marked here as a complete list
+
+4
+00:00:09,710 --> 00:00:13,254
+of requirements for a gym? And you have two options, yes or no.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/11 - Completeness Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/11 - Completeness Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..2ddc7e9
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/11 - Completeness Quiz Solution - lang_en_vs4.srt
@@ -0,0 +1,23 @@
+1
+00:00:00,160 --> 00:00:02,060
+And the answer is clearly no.
+
+2
+00:00:02,060 --> 00:00:05,060
+Obviously, there are many missing requirements here.
+
+3
+00:00:05,060 --> 00:00:07,910
+For example, requirements about registration for the
+
+4
+00:00:07,910 --> 00:00:11,560
+customers, requirements about fitness program creation, membership
+
+5
+00:00:11,560 --> 00:00:15,481
+types, and so on. Plus, we are also missing all of the nonfunctional
+
+6
+00:00:15,481 --> 00:00:19,270
+requirements, which we haven't seen yet, but that we will discuss in a bit.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/12 - Irrelevant Requirements Quiz - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/12 - Irrelevant Requirements Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..5b5fe86
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/12 - Irrelevant Requirements Quiz - lang_en_vs4.srt
@@ -0,0 +1,43 @@
+1
+00:00:00,140 --> 00:00:02,400
+In the previous quiz, we saw that some of the requirements
+
+2
+00:00:02,400 --> 00:00:04,920
+that they put in the list were not pertinent. They were
+
+3
+00:00:04,920 --> 00:00:08,590
+irrelevant. So let me ask you. Why can irrelevant requirements be
+
+4
+00:00:08,590 --> 00:00:12,170
+harmful? Why is that a problem to have irrelevant requirements? So
+
+5
+00:00:12,170 --> 00:00:15,060
+here, I'm giving you four possible answers. And I'd like for
+
+6
+00:00:15,060 --> 00:00:18,150
+you to mark all that apply. Can irrelevant requirements be harmful
+
+7
+00:00:18,150 --> 00:00:21,210
+because they may lead to missing functionality in the final product.
+
+8
+00:00:21,210 --> 00:00:23,390
+Because they can introduce inconsistency. Because
+
+9
+00:00:23,390 --> 00:00:25,410
+they can waste the project resources.
+
+10
+00:00:25,410 --> 00:00:28,170
+Or because they may introduce bugs in the software system. And
+
+11
+00:00:28,170 --> 00:00:30,680
+as I said, more than one can be a valid reason.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/13 - Irrelevant Requirements Quiz Solution - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/13 - Irrelevant Requirements Quiz Solution - lang_en_vs5.srt
new file mode 100644
index 0000000..f1c51c1
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/13 - Irrelevant Requirements Quiz Solution - lang_en_vs5.srt
@@ -0,0 +1,63 @@
+1
+00:00:00,200 --> 00:00:02,920
+So let's go through the list. Definitely irrelevant requirements
+
+2
+00:00:02,920 --> 00:00:06,370
+cannot lead to missing functionality in the final product, because
+
+3
+00:00:06,370 --> 00:00:10,730
+irrelevant requirements actually refer to unneeded functionality in the system.
+
+4
+00:00:10,730 --> 00:00:13,030
+So functionality that is put in the requirements, but it
+
+5
+00:00:13,030 --> 00:00:15,120
+is not really needed. So we're not going to mark
+
+6
+00:00:15,120 --> 00:00:19,400
+this one. Indeed, irrelevant requirements can introduce inconsistencies. So they
+
+7
+00:00:19,400 --> 00:00:22,490
+could be irrelevant requirements that not only are not pertinent
+
+8
+00:00:22,490 --> 00:00:25,620
+but they are inconsistent with some of the pertinent requirements.
+
+9
+00:00:25,620 --> 00:00:29,220
+They can also waste project resources, because if we spend time
+
+10
+00:00:29,220 --> 00:00:31,920
+designing and then implementing the parts of the system that we
+
+11
+00:00:31,920 --> 00:00:35,410
+refer to these irrelevant requirements, of course, we are wasting project
+
+12
+00:00:35,410 --> 00:00:38,570
+resources. And I will not mark the last one because there's really
+
+13
+00:00:38,570 --> 00:00:42,220
+no correlation between any irrelevant requirements and bugs in the software
+
+14
+00:00:42,220 --> 00:00:45,350
+system. Of course, by implementing the part of the system that refers
+
+15
+00:00:45,350 --> 00:00:47,960
+to an irrelevant requirement you might introduce a bug. But that's
+
+16
+00:00:47,960 --> 00:00:51,020
+not necessarily the case, and there really no correlation between the two.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/14 - Best Practices - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/14 - Best Practices - lang_en_vs5.srt
new file mode 100644
index 0000000..7497280
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/14 - Best Practices - lang_en_vs5.srt
@@ -0,0 +1,83 @@
+1
+00:00:00,150 --> 00:00:02,290
+But we collect requirements all the time, right? Every
+
+2
+00:00:02,290 --> 00:00:04,960
+time we build a software system. So how do people
+
+3
+00:00:04,960 --> 00:00:08,320
+cope with these difficulties? What are the best practices?
+
+4
+00:00:08,320 --> 00:00:12,950
+In practice, developers or analysts usually identify a whole bunch
+
+5
+00:00:12,950 --> 00:00:16,590
+of requirements. Sometimes the easiest and most obvious ones. They
+
+6
+00:00:16,590 --> 00:00:19,370
+bring those to the stakeholders, and the stakeholders have to
+
+7
+00:00:19,370 --> 00:00:23,100
+read the requirements, understand them, and if they agree, sign
+
+8
+00:00:23,100 --> 00:00:25,580
+off on them. And the problem is that in general,
+
+9
+00:00:25,580 --> 00:00:28,910
+these requirements documents are difficult to read. They are long, they
+
+10
+00:00:28,910 --> 00:00:32,470
+are often unstructured. They typically contain a lot of information. And
+
+11
+00:00:32,470 --> 00:00:35,310
+in general, they are not exactly a pleasant read. So what
+
+12
+00:00:35,310 --> 00:00:39,710
+happens is that often the stakeholders are short on time, overwhelmed
+
+13
+00:00:39,710 --> 00:00:42,380
+by the amount of information they're given and so they give
+
+14
+00:00:42,380 --> 00:00:44,800
+in to the pressure and sign. And this is a bit
+
+15
+00:00:44,800 --> 00:00:47,300
+of a dramatization clearly but it's clear that what we are
+
+16
+00:00:47,300 --> 00:00:50,640
+looking at is not an ideal scenario. Clearly this is not
+
+17
+00:00:50,640 --> 00:00:53,810
+the way to identify the real purpose of a software system to
+
+18
+00:00:53,810 --> 00:00:57,920
+collect good requirements. And since one of the major causes for project
+
+19
+00:00:57,920 --> 00:01:02,130
+failure is the inadequacy of requirements, we should really avoid this kind
+
+20
+00:01:02,130 --> 00:01:03,590
+of scenario. We should follow a
+
+21
+00:01:03,590 --> 00:01:06,810
+rigorous and effective requirements engineering process instead.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/15 - RE Definition Breakdown - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/15 - RE Definition Breakdown - lang_en_vs4.srt
new file mode 100644
index 0000000..bcc06a5
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/15 - RE Definition Breakdown - lang_en_vs4.srt
@@ -0,0 +1,207 @@
+1
+00:00:00,130 --> 00:00:02,540
+But how can we do that? How can we identify the purpose
+
+2
+00:00:02,540 --> 00:00:06,080
+of the system and collect good requirements? To answer that question, let me
+
+3
+00:00:06,080 --> 00:00:07,800
+give you another definition of requirements
+
+4
+00:00:07,800 --> 00:00:09,590
+engineering. And this one is a classical
+
+5
+00:00:09,590 --> 00:00:13,010
+one, one that summarizes what we discussed so far, and then we can
+
+6
+00:00:13,010 --> 00:00:16,180
+use as some sort of reference. And it is a little long.
+
+7
+00:00:16,180 --> 00:00:18,710
+Definitely longer than the one that we saw at the beginning. But it's
+
+8
+00:00:18,710 --> 00:00:21,840
+an important one and it contains a lot of very relevant points. So,
+
+9
+00:00:21,840 --> 00:00:25,210
+we're going to go through it and highlight these points. So the definition says,
+
+10
+00:00:25,210 --> 00:00:28,970
+that the requirements engineering is a set of activities concerned
+
+11
+00:00:28,970 --> 00:00:32,990
+with identifying and communicating the purpose of a software intensive
+
+12
+00:00:32,990 --> 00:00:35,770
+system and the context in which it will be used.
+
+13
+00:00:35,770 --> 00:00:38,570
+And this is exactly what we said at the beginning. But
+
+14
+00:00:38,570 --> 00:00:40,940
+something we can highlight in here, is the fact that
+
+15
+00:00:40,940 --> 00:00:44,210
+we're talking about a set of activities. So, what that means
+
+16
+00:00:44,210 --> 00:00:46,800
+is that requirements engineering is not just a phase or
+
+17
+00:00:46,800 --> 00:00:51,050
+a stage. It also says that it's about identifying and communicating.
+
+18
+00:00:51,050 --> 00:00:53,720
+And what that is telling us is that communication is
+
+19
+00:00:53,720 --> 00:00:56,670
+as important as the analysis. So, it's important to be
+
+20
+00:00:56,670 --> 00:00:59,990
+able to communicate these requirements not only to collect them.
+
+21
+00:00:59,990 --> 00:01:02,018
+And we will discuss many reasons why that is the
+
+22
+00:01:02,018 --> 00:01:05,880
+case. It explicitly talks about purpose. So that allows me
+
+23
+00:01:05,880 --> 00:01:10,310
+to stress, once more, that quality means fitness-for-purpose. We cannot
+
+24
+00:01:10,310 --> 00:01:14,410
+say anything about quality unless we understand the purpose. And
+
+25
+00:01:14,410 --> 00:01:16,210
+the last thing I want to point out in this first
+
+26
+00:01:16,210 --> 00:01:18,420
+part of the definition is the use of the term
+
+27
+00:01:18,420 --> 00:01:21,060
+context. This is also something else that we mentioned at
+
+28
+00:01:21,060 --> 00:01:24,890
+the beginning, that designers, analysts, need to know how and
+
+29
+00:01:24,890 --> 00:01:28,015
+where the system will be used. Without this information, you
+
+30
+00:01:28,015 --> 00:01:30,455
+cannot really understand what the system should do and you
+
+31
+00:01:30,455 --> 00:01:33,280
+cannot really build the system. So now, let's continue and
+
+32
+00:01:33,280 --> 00:01:35,755
+read the second part of the definition that says, hence.
+
+33
+00:01:35,755 --> 00:01:41,550
+Requirements engineering acts as the bridge between the real-world needs of
+
+34
+00:01:41,550 --> 00:01:45,315
+users, customers, and other constituencies affected by a
+
+35
+00:01:45,315 --> 00:01:49,440
+software system and the capabilities and opportunities afforded
+
+36
+00:01:49,440 --> 00:01:52,870
+by software-intensive technologies. This is a long sentence,
+
+37
+00:01:52,870 --> 00:01:55,030
+but also here, we can point out a
+
+38
+00:01:55,030 --> 00:01:57,670
+few interesting and relevant points. Let me start
+
+39
+00:01:57,670 --> 00:02:00,612
+by highlighting two parts. Real-world needs, and the
+
+40
+00:02:00,612 --> 00:02:04,150
+capabilities, and opportunities. So, what are these two
+
+41
+00:02:04,150 --> 00:02:07,000
+parts telling us? They are telling us that requirements
+
+42
+00:02:07,000 --> 00:02:09,949
+are partly about what is needed, the real-world needs
+
+43
+00:02:09,949 --> 00:02:13,520
+of all these stakeholders. But they're also partly about what
+
+44
+00:02:13,520 --> 00:02:16,100
+is possible, what we can actually build. We need
+
+45
+00:02:16,100 --> 00:02:19,260
+to compromise between these two things. And, finally, I would
+
+46
+00:02:19,260 --> 00:02:23,000
+like to point out this term constituencies, which indicates
+
+47
+00:02:23,000 --> 00:02:26,220
+that we need to identify all of the stakeholders, not
+
+48
+00:02:26,220 --> 00:02:29,130
+just the customer and the users, so anybody who is
+
+49
+00:02:29,130 --> 00:02:32,040
+affected by a software system. It is very important to
+
+50
+00:02:32,040 --> 00:02:35,130
+consider all of these actors. Otherwise, again,
+
+51
+00:02:35,130 --> 00:02:37,530
+we'll be missing requirements, we'll be missing
+
+52
+00:02:37,530 --> 00:02:41,120
+part of the purpose of the system and we will build a suboptimal system.
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.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/17 - Defining Requirements Quiz - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/17 - Defining Requirements Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..343e3cb
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/17 - Defining Requirements Quiz - lang_en_vs4.srt
@@ -0,0 +1,79 @@
+1
+00:00:00,180 --> 00:00:01,780
+Since we just discussed application
+
+2
+00:00:01,780 --> 00:00:04,770
+domain, machine domain, and the specificiation,
+
+3
+00:00:04,770 --> 00:00:07,760
+let's make sure that these concepts are well understood. To do that,
+
+4
+00:00:07,760 --> 00:00:09,740
+I'm going to use a quiz, and I would like for you
+
+5
+00:00:09,740 --> 00:00:12,590
+to refer to the figure that we just discussed that I'm also
+
+6
+00:00:12,590 --> 00:00:16,050
+reproducing here on a small scale on the right. And then
+
+7
+00:00:16,050 --> 00:00:19,080
+referring to the figure, you should indicate for each of the items
+
+8
+00:00:19,080 --> 00:00:22,140
+that I'm going to show you here shortly. Whether they belong to
+
+9
+00:00:22,140 --> 00:00:25,360
+the machine domain. In this case, we're going to put a one next
+
+10
+00:00:25,360 --> 00:00:28,150
+to the icon. The application domain, in this case you should
+
+11
+00:00:28,150 --> 00:00:31,410
+put two. Or their intersection, and in this case you should
+
+12
+00:00:31,410 --> 00:00:34,100
+put three. So this is the lists of items. So let
+
+13
+00:00:34,100 --> 00:00:37,750
+me read it. An algorithm sorts a list of books in alphabetical
+
+14
+00:00:37,750 --> 00:00:41,070
+order by the first author's name. A notification of the arrival
+
+15
+00:00:41,070 --> 00:00:44,380
+of a message appears on a smart watch. An employee wants to
+
+16
+00:00:44,380 --> 00:00:47,150
+organize a meeting with a set of colleagues. And finally, a
+
+17
+00:00:47,150 --> 00:00:50,690
+user clicks a link on a web page. So again, put 1,
+
+18
+00:00:50,690 --> 00:00:55,740
+2, or 3 here in these lots, depending on whether you think that these items
+
+19
+00:00:55,740 --> 00:00:57,840
+belong to the machine domain, the application
+
+20
+00:00:57,840 --> 00:01:00,910
+domain, or their intersection. So, their specification, here.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/18 - Defining Requirements Quiz Solution - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/18 - Defining Requirements Quiz Solution - lang_en_vs5.srt
new file mode 100644
index 0000000..7fcbd53
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/18 - Defining Requirements Quiz Solution - lang_en_vs5.srt
@@ -0,0 +1,103 @@
+1
+00:00:00,200 --> 00:00:03,460
+So let's look at each one of these items individually, starting from
+
+2
+00:00:03,460 --> 00:00:06,260
+the first one. And here this item has to do with how
+
+3
+00:00:06,260 --> 00:00:08,250
+the machine stores the information and
+
+4
+00:00:08,250 --> 00:00:10,240
+how the corresponding algorithm is written.
+
+5
+00:00:10,240 --> 00:00:12,920
+But it has no bearing in the real world. That is, in
+
+6
+00:00:12,920 --> 00:00:15,720
+the application domain. Therefore this. Definitely
+
+7
+00:00:15,720 --> 00:00:17,200
+belongs to the machine domain, and
+
+8
+00:00:17,200 --> 00:00:19,610
+we're going to put a one here. What about a notification of
+
+9
+00:00:19,610 --> 00:00:21,980
+the arrival of a message on a smart watch? This is an
+
+10
+00:00:21,980 --> 00:00:25,170
+event that is generated within the machine, but it has an effect,
+
+11
+00:00:25,170 --> 00:00:28,480
+an observable effect, in this case, in the real world as well.
+
+12
+00:00:28,480 --> 00:00:31,780
+Therefore, we're going to mark this as three. So this is an
+
+13
+00:00:31,780 --> 00:00:33,460
+event. This is something that belongs
+
+14
+00:00:33,460 --> 00:00:35,160
+to the intersection between the application
+
+15
+00:00:35,160 --> 00:00:37,480
+domain and the machine domain. So it's something that could be in
+
+16
+00:00:37,480 --> 00:00:40,730
+the specification. Now what about an employee that wants to organize a
+
+17
+00:00:40,730 --> 00:00:43,850
+meeting with a set of colleagues? This is an event that belongs
+
+18
+00:00:43,850 --> 00:00:46,460
+to the application domain because it is a fact that it's true
+
+19
+00:00:46,460 --> 00:00:50,290
+that exists. In the real world independently from the existence of a machine.
+
+20
+00:00:50,290 --> 00:00:52,380
+Therefore, we're going to mark this as two.
+
+21
+00:00:52,380 --> 00:00:54,890
+Finally, the event of a user clicking on a
+
+22
+00:00:54,890 --> 00:00:58,950
+link on a web page is an event that occurs in the real world but that has an
+
+23
+00:00:58,950 --> 00:01:01,932
+effect also within the machine and, therefore, we're
+
+24
+00:01:01,932 --> 00:01:04,920
+going to mark this as three, something that happens
+
+25
+00:01:04,920 --> 00:01:07,730
+at the intersection. between these two domains, and once
+
+26
+00:01:07,730 --> 00:01:10,060
+more, something that could be in a specification.
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.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/2 - Interview with Jane Cleland-Huang - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/2 - Interview with Jane Cleland-Huang - lang_en_vs5.srt
new file mode 100644
index 0000000..2a1bc1c
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/2 - Interview with Jane Cleland-Huang - lang_en_vs5.srt
@@ -0,0 +1,411 @@
+1
+00:00:00,270 --> 00:00:02,800
+As we did for other lessons, before starting this
+
+2
+00:00:02,800 --> 00:00:06,150
+lesson on requirements engineering, I want to ask a world
+
+3
+00:00:06,150 --> 00:00:10,210
+expert on this topic a few questions. I'm here with
+
+4
+00:00:10,210 --> 00:00:14,150
+Jane Cleland-Huang, a professor at the DePaul University. And Jane
+
+5
+00:00:14,150 --> 00:00:16,500
+is a world expert in the area of requirements
+
+6
+00:00:16,500 --> 00:00:19,830
+engineering, which is the theme of this lesson. So I'm
+
+7
+00:00:19,830 --> 00:00:22,220
+talking to Jane who is currently in Chicago and I
+
+8
+00:00:22,220 --> 00:00:25,380
+want to. Ask her a few questions about requirements engineering.
+
+9
+00:00:25,380 --> 00:00:26,530
+So hi Jane how are you?
+
+10
+00:00:26,530 --> 00:00:27,990
+&gt;&gt; Fine. Thank you Alex.
+
+11
+00:00:27,990 --> 00:00:29,480
+&gt;&gt; And thank you so much for agreeing to
+
+12
+00:00:29,480 --> 00:00:31,960
+be interviewed for our course, I'm sure the students
+
+13
+00:00:31,960 --> 00:00:34,080
+will really benefit from this. And let me start
+
+14
+00:00:34,080 --> 00:00:37,240
+with the first question which is what are software requirements?
+
+15
+00:00:37,240 --> 00:00:40,900
+&gt;&gt; That's an interesting question. And software requirements
+
+16
+00:00:40,900 --> 00:00:44,220
+basically provide us a description of what a
+
+17
+00:00:44,220 --> 00:00:47,520
+system has to do. So, typically they describe
+
+18
+00:00:47,520 --> 00:00:50,550
+the functionality of the features. That the system has
+
+19
+00:00:50,550 --> 00:00:54,420
+to deliver in order to satisfy its stakeholders.
+
+20
+00:00:54,420 --> 00:00:59,010
+And we usually talk about the requirement specification
+
+21
+00:00:59,010 --> 00:01:01,050
+in terms of what the system's going to
+
+22
+00:01:01,050 --> 00:01:04,010
+do. And we describe it sometimes formally in
+
+23
+00:01:04,010 --> 00:01:07,300
+terms of set of shall statements, that the
+
+24
+00:01:07,300 --> 00:01:09,110
+system shall do this or shall do that.
+
+25
+00:01:09,110 --> 00:01:12,330
+Or we can use various templates to specify
+
+26
+00:01:12,330 --> 00:01:16,120
+both textural requirements. But requirements can also be represented
+
+27
+00:01:16,120 --> 00:01:20,790
+informally in, in the form of user stories, or use cases, or more
+
+28
+00:01:20,790 --> 00:01:26,180
+formally in the form of state transition diagrams and even in kind of
+
+29
+00:01:26,180 --> 00:01:32,260
+formal specifications. Especially for critical parts of safety critical systems.
+
+30
+00:01:32,260 --> 00:01:34,180
+&gt;&gt; And another should discuss what the
+
+31
+00:01:34,180 --> 00:01:37,230
+requirements are. What is the requirements engineering?
+
+32
+00:01:37,230 --> 00:01:41,180
+&gt;&gt; So, that's also an interesting question because if you notice
+
+33
+00:01:41,180 --> 00:01:45,330
+it's it's engineering and I'm sure in the
+
+34
+00:01:45,330 --> 00:01:47,750
+other parts of the software engineering process that
+
+35
+00:01:47,750 --> 00:01:51,130
+you're discussing in your course. Parts such as
+
+36
+00:01:51,130 --> 00:01:55,200
+testing or coding. They don't have the word engineering
+
+37
+00:01:55,200 --> 00:01:56,930
+there and I think one of the reasons
+
+38
+00:01:56,930 --> 00:02:00,310
+requirements engineering has that term is because it covers
+
+39
+00:02:00,310 --> 00:02:03,570
+a number of different activities. So it includes
+
+40
+00:02:03,570 --> 00:02:07,390
+things such as working with stakeholders to elicit or
+
+41
+00:02:07,390 --> 00:02:10,620
+to proactively discover what their requirements of the
+
+42
+00:02:10,620 --> 00:02:14,440
+system are. Analyzing those requirements so that we
+
+43
+00:02:14,440 --> 00:02:17,380
+understand the tradeoffs. So you might have different
+
+44
+00:02:17,380 --> 00:02:21,170
+stakeholders that care about different things, and it
+
+45
+00:02:21,170 --> 00:02:26,086
+might not be possible to deliver all of those things, so we have to analyze the
+
+46
+00:02:26,086 --> 00:02:29,140
+feasibility of the requirements, explore the tradeoffs, emerge
+
+47
+00:02:29,140 --> 00:02:32,550
+conflicts. And then of course the specification part,
+
+48
+00:02:32,550 --> 00:02:34,930
+which we talked about a little bit already,
+
+49
+00:02:34,930 --> 00:02:37,340
+and the validation, so did we in fact get
+
+50
+00:02:37,340 --> 00:02:40,480
+the requirements right? Did we build a system
+
+51
+00:02:40,480 --> 00:02:43,490
+that actually matches our, our requirements. And then on
+
+52
+00:02:43,490 --> 00:02:46,960
+into the requirements management process. And the requirements
+
+53
+00:02:46,960 --> 00:02:50,860
+management process. Kind of like goes through things like
+
+54
+00:02:50,860 --> 00:02:55,010
+change management. So what if customer or stakeholders
+
+55
+00:02:55,010 --> 00:02:57,630
+need the system to change? How do we manage
+
+56
+00:02:57,630 --> 00:03:00,180
+changing requirements? And I think this is one of
+
+57
+00:03:00,180 --> 00:03:03,230
+the reasons that we've coined the term engineering because
+
+58
+00:03:03,230 --> 00:03:06,490
+that it's, has to be a systematic process which
+
+59
+00:03:06,490 --> 00:03:09,550
+extends across. The whole of this is life cycle.
+
+60
+00:03:09,550 --> 00:03:12,890
+&gt;&gt; And I guess my last question here is
+
+61
+00:03:12,890 --> 00:03:15,100
+so now that we heard about software requirements and
+
+62
+00:03:15,100 --> 00:03:18,790
+about software requirements engineering, why is requirements engineering so
+
+63
+00:03:18,790 --> 00:03:20,770
+important? So what happens if we don't do it right?
+
+64
+00:03:20,770 --> 00:03:22,620
+&gt;&gt; Well, I'm sure that, you know,
+
+65
+00:03:22,620 --> 00:03:24,880
+many people have probably read the kind of
+
+66
+00:03:24,880 --> 00:03:28,560
+report like Spanish report, and other reports of failed
+
+67
+00:03:28,560 --> 00:03:31,900
+project, and things like that, and are aware that
+
+68
+00:03:31,900 --> 00:03:35,280
+one of the major reasons for projects failing
+
+69
+00:03:35,280 --> 00:03:37,360
+is because we didn't get the requirements right
+
+70
+00:03:37,360 --> 00:03:40,110
+in the first place. So if we don't understand
+
+71
+00:03:40,110 --> 00:03:42,970
+the requirements then we're simply going to build the
+
+72
+00:03:42,970 --> 00:03:47,960
+wrong system. Getting requirements right includes all sorts of
+
+73
+00:03:47,960 --> 00:03:52,900
+things such as finding the right group of stakeholders so we don't exclude major
+
+74
+00:03:52,900 --> 00:03:56,940
+groups of stakeholders. Understanding the requirements correctly.
+
+75
+00:03:56,940 --> 00:03:59,910
+There will be many, many different examples of
+
+76
+00:03:59,910 --> 00:04:02,310
+projects that have failed. For example, in
+
+77
+00:04:02,310 --> 00:04:06,500
+America the healthcare.gov failure, and while we cannot
+
+78
+00:04:06,500 --> 00:04:09,540
+put the blame squarely in the area
+
+79
+00:04:09,540 --> 00:04:13,040
+of requirements, because obviously the project was challenged
+
+80
+00:04:13,040 --> 00:04:15,650
+for a number of different reasons. But
+
+81
+00:04:15,650 --> 00:04:21,070
+clearly it underperformed in many respects related to
+
+82
+00:04:21,070 --> 00:04:25,740
+security, performance, and reliability and these are all
+
+83
+00:04:25,740 --> 00:04:28,300
+parts of the requirements process. Things that should
+
+84
+00:04:28,300 --> 00:04:30,000
+have been discovered and the system should have
+
+85
+00:04:30,000 --> 00:04:32,914
+been built in order to meet those requirements,
+
+86
+00:04:32,914 --> 00:04:36,240
+getting the requirements right in the first place.
+
+87
+00:04:36,240 --> 00:04:38,110
+Puts us, a project on the right foot.
+
+88
+00:04:38,110 --> 00:04:41,430
+And so that gives us a much better chance
+
+89
+00:04:41,430 --> 00:04:44,940
+of delivering to the customer what they need. And
+
+90
+00:04:44,940 --> 00:04:49,130
+designing a solution that really meets those requirements. So,
+
+91
+00:04:49,130 --> 00:04:52,800
+it's a critical part of the overall software engineering success.
+
+92
+00:04:52,800 --> 00:04:56,441
+&gt;&gt; Okay. So that's critical. I mean, we better get our requirements right.
+
+93
+00:04:56,441 --> 00:04:56,987
+&gt;&gt; Yeah.
+
+94
+00:04:56,987 --> 00:04:57,733
+&gt;&gt; That's, that's the message.
+
+95
+00:04:57,733 --> 00:04:57,743
+&gt;&gt; Yeah.
+
+96
+00:04:57,743 --> 00:05:00,822
+&gt;&gt; Okay. Well, thank you so much Jane, for taking
+
+97
+00:05:00,822 --> 00:05:03,435
+the time off your busy schedule to speak with us.
+
+98
+00:05:03,435 --> 00:05:07,150
+I'm sure. The students really appreciate this, and we'll talk to you soon.
+
+99
+00:05:07,150 --> 00:05:08,480
+&gt;&gt; Bye Alex, thank you.
+
+100
+00:05:08,480 --> 00:05:10,890
+&gt;&gt; Bye, Jane, bye bye. Jane gave
+
+101
+00:05:10,890 --> 00:05:13,410
+us an interesting perspective on requirements engineering
+
+102
+00:05:13,410 --> 00:05:15,410
+and its importance. Let's now start our
+
+103
+00:05:15,410 --> 00:05:18,050
+lesson with a general definition of requirements engineering.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/20 - User and System Requirements - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/20 - User and System Requirements - lang_en_vs4.srt
new file mode 100644
index 0000000..2da3f58
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/20 - User and System Requirements - lang_en_vs4.srt
@@ -0,0 +1,111 @@
+1
+00:00:00,180 --> 00:00:03,170
+Another important distinction, when talking about requirements, is that
+
+2
+00:00:03,170 --> 00:00:07,220
+between user and system requirements. So, let's start with defining
+
+3
+00:00:07,220 --> 00:00:10,540
+user requirements. Those are requirements that are written for the
+
+4
+00:00:10,540 --> 00:00:13,400
+customers and they're often in natural language and they don't
+
+5
+00:00:13,400 --> 00:00:16,190
+contain technical details. And the reason for that is
+
+6
+00:00:16,190 --> 00:00:19,740
+that their purpose is to allow customers, stakeholders, to check
+
+7
+00:00:19,740 --> 00:00:22,210
+that the system will do what they intended. So it's
+
+8
+00:00:22,210 --> 00:00:25,470
+a way for the analyst, the developers, to communicate with
+
+9
+00:00:25,470 --> 00:00:28,460
+the customers, with the stakeholders. System requirements, on the
+
+10
+00:00:28,460 --> 00:00:32,560
+other hand, are written for developers. Contain detailed functional and
+
+11
+00:00:32,560 --> 00:00:35,330
+non functional requirements. Which we just discussed, and which
+
+12
+00:00:35,330 --> 00:00:39,860
+are clearly and more rigourously specified than the user requirements.
+
+13
+00:00:39,860 --> 00:00:42,130
+And the reason for this difference is that the
+
+14
+00:00:42,130 --> 00:00:45,410
+purpose of the system requirements is to tell developers what
+
+15
+00:00:45,410 --> 00:00:47,870
+to build. They must contain enough details so the
+
+16
+00:00:47,870 --> 00:00:50,480
+developers can take them and use them to design and
+
+17
+00:00:50,480 --> 00:00:52,530
+then develop a system. Just to give you a concrete
+
+18
+00:00:52,530 --> 00:00:55,750
+example, here I'm showing you a user requirement that just says
+
+19
+00:00:55,750 --> 00:00:59,510
+that the software must provide a means of representing and accessing
+
+20
+00:00:59,510 --> 00:01:03,940
+external files created by other tools, and the corresponding system requirement.
+
+21
+00:01:03,940 --> 00:01:05,700
+And as you can see, even if we don't read the
+
+22
+00:01:05,700 --> 00:01:09,380
+whole requirements. The former is an informal and high level description
+
+23
+00:01:09,380 --> 00:01:12,210
+of a piece of functionality, whereas the latter describes the same
+
+24
+00:01:12,210 --> 00:01:15,940
+functionality but in a much more extensive and rigorous way. As
+
+25
+00:01:15,940 --> 00:01:18,760
+I said, this is something that the developers can use to
+
+26
+00:01:18,760 --> 00:01:21,820
+design and then build a system whereas this is something that
+
+27
+00:01:21,820 --> 00:01:25,590
+can be used to communicate. With the stakeholders, with a non-technical
+
+28
+00:01:25,590 --> 00:01:29,490
+audience. And we need to define both because they serve different purposes.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/21 - Requirements Quiz - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/21 - Requirements Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..4b416e8
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/21 - Requirements Quiz - lang_en_vs4.srt
@@ -0,0 +1,43 @@
+1
+00:00:00,160 --> 00:00:02,940
+After all these talking about requirements, let's have a small quiz, I
+
+2
+00:00:02,940 --> 00:00:04,019
+want to ask you which of the
+
+3
+00:00:04,019 --> 00:00:07,840
+following requirements are non-functional requirements? And here
+
+4
+00:00:07,840 --> 00:00:10,860
+I'm listing the requirements, the first one says at the BowlingAlley program
+
+5
+00:00:10,860 --> 00:00:13,420
+keeps track of the score during a game, the second one is that
+
+6
+00:00:13,420 --> 00:00:16,720
+the WordCount program should be able to process large files. The third
+
+7
+00:00:16,720 --> 00:00:19,580
+one is that the Login program for a website. Should be secure, and
+
+8
+00:00:19,580 --> 00:00:22,880
+finally the last one says that the vending machine program should take coins
+
+9
+00:00:22,880 --> 00:00:25,430
+as an input from the user. So, I want you to mark all
+
+10
+00:00:25,430 --> 00:00:27,590
+the ones that are non-functional requirements, that
+
+11
+00:00:27,590 --> 00:00:29,640
+don't refer to the functionality of the system.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/22 - Requirements Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/22 - Requirements Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..e957484
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/22 - Requirements Quiz Solution - lang_en_vs4.srt
@@ -0,0 +1,63 @@
+1
+00:00:00,120 --> 00:00:03,710
+So, the first requirement clearly refers to some specific functionality of
+
+2
+00:00:03,710 --> 00:00:07,230
+the Bowling Alley system, because it talks about what the system has
+
+3
+00:00:07,230 --> 00:00:10,420
+to do from a functional standpoint. So, it's definitely not a non-functional
+
+4
+00:00:10,420 --> 00:00:13,400
+requirement. On the other hand, the fact that the Word Count system
+
+5
+00:00:13,400 --> 00:00:16,320
+should be able to process large files, is telling us something not
+
+6
+00:00:16,320 --> 00:00:19,580
+about the functionality of the system, but rather about its qualities. The
+
+7
+00:00:19,580 --> 00:00:21,600
+fact that it has to be scalable, that it has to be
+
+8
+00:00:21,600 --> 00:00:25,190
+efficient and so we can consider this to be a non-functional requirement.
+
+9
+00:00:25,190 --> 00:00:27,010
+Similarly, the fact that the Login program for a
+
+10
+00:00:27,010 --> 00:00:29,390
+website should be secure is definitely telling us something
+
+11
+00:00:29,390 --> 00:00:31,800
+about the quality of the system that has little
+
+12
+00:00:31,800 --> 00:00:34,026
+to do with its functionality. And so this is
+
+13
+00:00:34,026 --> 00:00:36,680
+also a non-functional requirement. Finally, the fact that the
+
+14
+00:00:36,680 --> 00:00:38,980
+Vending Machine program should take coins as an input
+
+15
+00:00:38,980 --> 00:00:41,010
+from the user is telling us something about the
+
+16
+00:00:41,010 --> 00:00:44,100
+functionality of the program and therefore, is a functional requirement.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/23 - Requirement Origins - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/23 - Requirement Origins - lang_en_vs4.srt
new file mode 100644
index 0000000..6fe4931
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/23 - Requirement Origins - lang_en_vs4.srt
@@ -0,0 +1,71 @@
+1
+00:00:00,130 --> 00:00:01,880
+Now that we know what the requirements are and
+
+2
+00:00:01,880 --> 00:00:05,520
+their main types, let's discuss where requirements come from and
+
+3
+00:00:05,520 --> 00:00:08,610
+there are many possible sources for requirements so I'm
+
+4
+00:00:08,610 --> 00:00:10,610
+going to list here the main ones. The first one are
+
+5
+00:00:10,610 --> 00:00:14,440
+clearly stakeholders, anybody who is effected by the system
+
+6
+00:00:14,440 --> 00:00:18,830
+and its functionality. Customers, users, and so on. The second
+
+7
+00:00:18,830 --> 00:00:22,610
+typical social requirement is the application domain. For example,
+
+8
+00:00:22,610 --> 00:00:25,380
+the fact that my software is running within a bank,
+
+9
+00:00:25,380 --> 00:00:27,930
+or within a school. Why is the application domain a
+
+10
+00:00:27,930 --> 00:00:31,410
+social requirement? Well, because there are constraints that are characteristics
+
+11
+00:00:31,410 --> 00:00:34,140
+of the application domain that will affect the functionality of
+
+12
+00:00:34,140 --> 00:00:37,130
+the system. For a simple example, just think about regulations.
+
+13
+00:00:37,130 --> 00:00:40,400
+So banking regulations and school regulations in these cases. Those
+
+14
+00:00:40,400 --> 00:00:43,120
+are things that might affect the functionality of my system
+
+15
+00:00:43,120 --> 00:00:45,570
+and, therefore, that may become part of my requirements. And,
+
+16
+00:00:45,570 --> 00:00:50,120
+finally, documentation can be an additional source of requirements. For example,
+
+17
+00:00:50,120 --> 00:00:54,110
+notes, papers, manuals, books. So everything that refers to
+
+18
+00:00:54,110 --> 00:00:56,610
+the functionality of the system that we're going to build.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/24 - Elicitation Problems - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/24 - Elicitation Problems - lang_en_vs4.srt
new file mode 100644
index 0000000..2d81db7
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/24 - Elicitation Problems - lang_en_vs4.srt
@@ -0,0 +1,179 @@
+1
+00:00:00,190 --> 00:00:03,440
+Unfortunately, extracting requirements from these sources is not
+
+2
+00:00:03,440 --> 00:00:06,220
+a straightforward task, as there are many issues involved
+
+3
+00:00:06,220 --> 00:00:09,470
+with the requirements elicitation. One first problem is the
+
+4
+00:00:09,470 --> 00:00:13,930
+thin spread of domain knowledge. Knowledge is rarely available
+
+5
+00:00:13,930 --> 00:00:15,970
+in an explicit form, that is, it is
+
+6
+00:00:15,970 --> 00:00:20,310
+almost never written down. Moreover, knowledge is often distributed
+
+7
+00:00:20,310 --> 00:00:23,410
+across many sources. For example, in the graphical depiction
+
+8
+00:00:23,410 --> 00:00:25,590
+here, to find out that this is the purpose
+
+9
+00:00:25,590 --> 00:00:28,240
+of the project. The developer, the analyist, needs to talk
+
+10
+00:00:28,240 --> 00:00:30,870
+to a lot of different people. And, to make things even
+
+11
+00:00:30,870 --> 00:00:34,400
+worse. There are often conflicts between the knowledge gathered from
+
+12
+00:00:34,400 --> 00:00:37,610
+different sources. A second issue is the fact that the knowledge
+
+13
+00:00:37,610 --> 00:00:41,090
+is often tacit. What is also called the say, do
+
+14
+00:00:41,090 --> 00:00:44,052
+problem. In the example shown here. For instance. We have a
+
+15
+00:00:44,052 --> 00:00:47,650
+customer that is describing to the analyst. The way in which
+
+16
+00:00:47,650 --> 00:00:51,060
+he accomplishes a task. So it performs these three steps and
+
+17
+00:00:51,060 --> 00:00:54,300
+reaches the goal. Whereas in practice, the actual way in
+
+18
+00:00:54,300 --> 00:00:57,530
+which this task accomplished is by going through a larger number
+
+19
+00:00:57,530 --> 00:00:59,880
+of steps to get to the same goal. So the point
+
+20
+00:00:59,880 --> 00:01:02,650
+here is that, even if the knowledge were more concentrated, so
+
+21
+00:01:02,650 --> 00:01:05,660
+not as spread as in this example. People simply find
+
+22
+00:01:05,660 --> 00:01:08,680
+it hard to describe knowledge that they regularly use. So it
+
+23
+00:01:08,680 --> 00:01:11,740
+is hard to make this knowledge explicit, to pass this knowledge
+
+24
+00:01:11,740 --> 00:01:13,130
+to someone else. Yet another
+
+25
+00:01:13,130 --> 00:01:16,690
+problem is limited observability. Identifying requirements
+
+26
+00:01:16,690 --> 00:01:20,570
+through observation is often difficult as the problem owners might be
+
+27
+00:01:20,570 --> 00:01:23,550
+too busy to perform the task that we need to observe.
+
+28
+00:01:23,550 --> 00:01:25,750
+Or they might be doing a lot of other things together
+
+29
+00:01:25,750 --> 00:01:27,980
+with the task that we need to observe, so that becomes
+
+30
+00:01:27,980 --> 00:01:31,530
+confusing. That introduces noise. Moreover, even when this is not the
+
+31
+00:01:31,530 --> 00:01:34,460
+case, the presence of an observer might change their problem. It
+
+32
+00:01:34,460 --> 00:01:38,020
+is very typical for human subjects to improve or modify an
+
+33
+00:01:38,020 --> 00:01:41,760
+aspect of their behavior, which is being experimentally measured in response
+
+34
+00:01:41,760 --> 00:01:44,110
+to the fact that they know that they're being studied. You know
+
+35
+00:01:44,110 --> 00:01:47,110
+that somebody's studying you and you change the way in which you behave.
+
+36
+00:01:47,110 --> 00:01:50,910
+A typical issue. Finally, the information that we collect might be biased.
+
+37
+00:01:50,910 --> 00:01:54,270
+For several reasons. People might not feel free to tell you what you
+
+38
+00:01:54,270 --> 00:01:57,030
+need to know. Or, people might not want to tell you what
+
+39
+00:01:57,030 --> 00:02:00,240
+you need to know. For example, in all the common cases in which
+
+40
+00:02:00,240 --> 00:02:03,870
+the outcome might effect them, people might provide you a different picture
+
+41
+00:02:03,870 --> 00:02:06,770
+from the real one. In order to influence you. So, they might have
+
+42
+00:02:06,770 --> 00:02:08,820
+a hidden agenda, and mislead you, either
+
+43
+00:02:08,820 --> 00:02:11,860
+consciously or unconsciously. So, all these issues
+
+44
+00:02:11,860 --> 00:02:14,370
+add to the complexity of collecting requirements,
+
+45
+00:02:14,370 --> 00:02:16,522
+of identifying the purpose of a system.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/25 - Traditional Techniques - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/25 - Traditional Techniques - lang_en_vs5.srt
new file mode 100644
index 0000000..cc58665
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/25 - Traditional Techniques - lang_en_vs5.srt
@@ -0,0 +1,207 @@
+1
+00:00:00,140 --> 00:00:02,930
+To cover the intrinsic problem of eliciting requirements,
+
+2
+00:00:02,930 --> 00:00:05,670
+many different techniques have been proposed. So here
+
+3
+00:00:05,670 --> 00:00:08,260
+I list some of most traditional techniques for
+
+4
+00:00:08,260 --> 00:00:11,290
+requirement elicitation and as I present those, please keep
+
+5
+00:00:11,290 --> 00:00:13,140
+in mind that these techniques can be used
+
+6
+00:00:13,140 --> 00:00:17,230
+separately or combined. A first technique is called background
+
+7
+00:00:17,230 --> 00:00:20,740
+reading. And, this technique involves collecting information by
+
+8
+00:00:20,740 --> 00:00:24,840
+reading existing documents such as company reports, organizational charts,
+
+9
+00:00:24,840 --> 00:00:29,280
+policy manuals, job descriptions, documentation of existing systems and so
+
+10
+00:00:29,280 --> 00:00:32,400
+on. And, this technique is especially appropriate when one Is
+
+11
+00:00:32,400 --> 00:00:35,370
+not familiar with your organization for which the requirements are
+
+12
+00:00:35,370 --> 00:00:38,950
+being collected. So you want to get some background before interviewing
+
+13
+00:00:38,950 --> 00:00:41,240
+actual people. And one of the main imitations of these
+
+14
+00:00:41,240 --> 00:00:43,930
+kinds of approaches is that written documents might be out
+
+15
+00:00:43,930 --> 00:00:46,320
+of sync and they often are out of sync with
+
+16
+00:00:46,320 --> 00:00:49,970
+reality. Tend to be long winded. It may contain many irrelevant
+
+17
+00:00:49,970 --> 00:00:51,850
+details, so you may have to look at a lot
+
+18
+00:00:51,850 --> 00:00:54,810
+of materials to extract enough information. The hard data and
+
+19
+00:00:54,810 --> 00:00:58,650
+samples techniques consist in deciding which hard data we want
+
+20
+00:00:58,650 --> 00:01:01,680
+to collect and choosing the sample of the population for which
+
+21
+00:01:01,680 --> 00:01:04,750
+to collect such data and hard data includes facts and
+
+22
+00:01:04,750 --> 00:01:09,790
+figures such as forms, invoices, financial information, survey results, marketing
+
+23
+00:01:09,790 --> 00:01:12,300
+data, and so on. And the sampling of this data
+
+24
+00:01:12,300 --> 00:01:15,170
+can be done in different ways. For example, the typical ways
+
+25
+00:01:15,170 --> 00:01:19,200
+to do random selection. Interviews are another typical approach for
+
+26
+00:01:19,200 --> 00:01:21,870
+requirement solicitation, and this is the approach that we use for
+
+27
+00:01:21,870 --> 00:01:24,910
+the first project in this course, for instance. Interviews can be
+
+28
+00:01:24,910 --> 00:01:27,720
+structured in which case there is an agenda of fairly open
+
+29
+00:01:27,720 --> 00:01:30,450
+questions or they can be open ended in which case there
+
+30
+00:01:30,450 --> 00:01:32,770
+is no preset agenda and the interview is more of a
+
+31
+00:01:32,770 --> 00:01:36,500
+conversation. On the positive side, interviews can collect a rich set
+
+32
+00:01:36,500 --> 00:01:40,260
+of information because they allow for uncovering opinions as well as
+
+33
+00:01:40,260 --> 00:01:43,230
+hard facts. Moreover, they can probe in depth through follow
+
+34
+00:01:43,230 --> 00:01:46,790
+up questions. On the more negative side, interviewing requires special
+
+35
+00:01:46,790 --> 00:01:50,400
+skills that are difficult to master and require experience. And
+
+36
+00:01:50,400 --> 00:01:52,890
+it is not enough to collect a lot of information. If
+
+37
+00:01:52,890 --> 00:01:55,520
+this information is hard to analyze or even irrelevant, it
+
+38
+00:01:55,520 --> 00:01:58,250
+might become useless. So you need to know how to conduct
+
+39
+00:01:58,250 --> 00:02:01,180
+an interview in order to take advantage of these techniques.
+
+40
+00:02:01,180 --> 00:02:05,440
+Surveys can also be extremely useful for gathering new requirements because
+
+41
+00:02:05,440 --> 00:02:08,550
+they can quickly collect information from a large number
+
+42
+00:02:08,550 --> 00:02:11,520
+of people. Moreover, they can be administered remotely. For
+
+43
+00:02:11,520 --> 00:02:13,610
+example, by email, through the web. On the other
+
+44
+00:02:13,610 --> 00:02:16,750
+hand, surveys tend to severely constrain the information that
+
+45
+00:02:16,750 --> 00:02:19,430
+the user can provide and might miss opportunities to
+
+46
+00:02:19,430 --> 00:02:24,460
+collect unforeseen, relevant information. Finally, meetings are generally used
+
+47
+00:02:24,460 --> 00:02:27,690
+for summarization of findings and collection of feedback, so as
+
+48
+00:02:27,690 --> 00:02:30,500
+to confirm or refute what has been learned. So the
+
+49
+00:02:30,500 --> 00:02:32,660
+only additional thing I want to mention about meetings
+
+50
+00:02:32,660 --> 00:02:34,920
+is the fact that it is fundamental that have clearly
+
+51
+00:02:34,920 --> 00:02:37,970
+stated objectives and are planned carefully. This is something that
+
+52
+00:02:37,970 --> 00:02:40,730
+should be quite obvious, but doesn't always happen in practice.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/26 - Other Techniques - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/26 - Other Techniques - lang_en_vs5.srt
new file mode 100644
index 0000000..f29fb9c
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/26 - Other Techniques - lang_en_vs5.srt
@@ -0,0 +1,71 @@
+1
+00:00:00,070 --> 00:00:02,370
+So just for completeness, I want to mention some other
+
+2
+00:00:02,370 --> 00:00:05,340
+techniques besides the traditional ones that we just saw that
+
+3
+00:00:05,340 --> 00:00:07,880
+can be used for requirements solicitation. And these other
+
+4
+00:00:07,880 --> 00:00:10,740
+techniques can be divided in three main groups. There are
+
+5
+00:00:10,740 --> 00:00:14,820
+collaborative techniques that were created to support incremental development
+
+6
+00:00:14,820 --> 00:00:18,850
+of complex systems with large diverse user populations. An example
+
+7
+00:00:18,850 --> 00:00:21,130
+of such techniques which is widely used and you
+
+8
+00:00:21,130 --> 00:00:25,120
+might know is brainstorming. There are also social approaches and
+
+9
+00:00:25,120 --> 00:00:28,140
+these are approaches, techniques that exploit the social
+
+10
+00:00:28,140 --> 00:00:31,520
+sciences to better collect information from the stakeholders and
+
+11
+00:00:31,520 --> 00:00:34,310
+the environment. And among those I just want to mention
+
+12
+00:00:34,310 --> 00:00:36,730
+ethnographic techniques which are based on the idea of
+
+13
+00:00:36,730 --> 00:00:40,100
+collecting information on the participants by observing them
+
+14
+00:00:40,100 --> 00:00:44,660
+in their original environment. Finally cognitive techniques, leverage cognitive
+
+15
+00:00:44,660 --> 00:00:48,490
+science approaches to discover expert knowledge for example they
+
+16
+00:00:48,490 --> 00:00:51,260
+can be used to understand the problem solving methods.
+
+17
+00:00:51,260 --> 00:00:54,000
+And in case you're interested in finding out more about this and
+
+18
+00:00:54,000 --> 00:00:57,580
+other techniques, I'm providing some references in the notes for the lesson.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/27 - Modeling Requirements - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/27 - Modeling Requirements - lang_en_vs4.srt
new file mode 100644
index 0000000..d4ade17
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/27 - Modeling Requirements - lang_en_vs4.srt
@@ -0,0 +1,223 @@
+1
+00:00:00,220 --> 00:00:03,550
+Once we collected the required knowledge on the requirements for
+
+2
+00:00:03,550 --> 00:00:06,120
+the system that we're developing, we need to model it in
+
+3
+00:00:06,120 --> 00:00:08,430
+a structured and clear way, so that it can be
+
+4
+00:00:08,430 --> 00:00:12,100
+analyzed and refined. And there are really tons of ways to
+
+5
+00:00:12,100 --> 00:00:15,840
+do that, depending on your focus and objectives. More specifically,
+
+6
+00:00:15,840 --> 00:00:18,940
+when modeling requirements you need to decide what you want to
+
+7
+00:00:18,940 --> 00:00:21,710
+model and how you want to model it. So let's look
+
+8
+00:00:21,710 --> 00:00:25,390
+at these two aspects independently. What you decide to model depends
+
+9
+00:00:25,390 --> 00:00:28,270
+on where your emphasis is. That is on which
+
+10
+00:00:28,270 --> 00:00:31,390
+aspects of the requirements you want to focus. For
+
+11
+00:00:31,390 --> 00:00:34,880
+example if your emphasis is on the characteristics of
+
+12
+00:00:34,880 --> 00:00:37,970
+the enterprise of the company that you are analyzing you
+
+13
+00:00:37,970 --> 00:00:40,240
+may want to model goals and objectives of the
+
+14
+00:00:40,240 --> 00:00:44,380
+company, or its organizational structure, its task and dependencies
+
+15
+00:00:44,380 --> 00:00:47,040
+and so on. Conversely, if your focus is on
+
+16
+00:00:47,040 --> 00:00:50,500
+information and behaviors, you might want to concentrate on aspects
+
+17
+00:00:50,500 --> 00:00:53,800
+such as the structure of information, various behavioral views
+
+18
+00:00:53,800 --> 00:00:55,480
+some of which we will see in the next
+
+19
+00:00:55,480 --> 00:00:59,650
+lesson, or maybe time or sequencing requirements. Finally, if
+
+20
+00:00:59,650 --> 00:01:02,750
+you're mostly interested in the quality aspects of your
+
+21
+00:01:02,750 --> 00:01:06,790
+system, you will focus on the various non-functional properties
+
+22
+00:01:06,790 --> 00:01:09,070
+of the software that are relevant in the context
+
+23
+00:01:09,070 --> 00:01:13,570
+considered. For example reliability, robustness, security, and so on.
+
+24
+00:01:13,570 --> 00:01:15,550
+You will just pick the ones that are relevant for
+
+25
+00:01:15,550 --> 00:01:18,540
+your context. And as we said, there's a second dimension.
+
+26
+00:01:18,540 --> 00:01:21,050
+After you have decided what to model in your system,
+
+27
+00:01:21,050 --> 00:01:23,480
+you have to decide how you want to model it.
+
+28
+00:01:23,480 --> 00:01:25,860
+So I want to show here some options for modeling
+
+29
+00:01:25,860 --> 00:01:30,380
+enterprises, information, and quality aspects. And as you can see
+
+30
+00:01:30,380 --> 00:01:34,100
+here for each type of information there are many possible
+
+31
+00:01:34,100 --> 00:01:36,840
+models that we can use to represent it. And all
+
+32
+00:01:36,840 --> 00:01:38,750
+these models have advantages and
+
+33
+00:01:38,750 --> 00:01:41,400
+disadvantages, different levels of formality and
+
+34
+00:01:41,400 --> 00:01:44,000
+different focus. Something else that I want to point out
+
+35
+00:01:44,000 --> 00:01:47,145
+about these models is the fact that these models are often
+
+36
+00:01:47,145 --> 00:01:50,980
+orthogonal to one another, especially if we consider models in different
+
+37
+00:01:50,980 --> 00:01:54,620
+categories. So what that means is that they're complimentary rather than
+
+38
+00:01:54,620 --> 00:01:58,310
+mutually exclusive. Different models can be used to provide views
+
+39
+00:01:58,310 --> 00:02:01,290
+of the requirements from different perspectives, and we will not see
+
+40
+00:02:01,290 --> 00:02:03,700
+most of these models in this course, but I wanted to
+
+41
+00:02:03,700 --> 00:02:06,550
+list them anyways to give you an idea of how many
+
+42
+00:02:06,550 --> 00:02:09,490
+there are and how vast is this area. As far
+
+43
+00:02:09,490 --> 00:02:11,540
+as we are concerned in the course and for the
+
+44
+00:02:11,540 --> 00:02:14,660
+projects we will express requirements using one of two main
+
+45
+00:02:14,660 --> 00:02:19,010
+ways. Using natural language, that is informal specifications and using
+
+46
+00:02:19,010 --> 00:02:22,600
+UML diagrams, which is graphical models. And we will introduce
+
+47
+00:02:22,600 --> 00:02:25,840
+UML and the most important diagrams in the next lesson.
+
+48
+00:02:25,840 --> 00:02:27,330
+And the only other type of models that I want
+
+49
+00:02:27,330 --> 00:02:31,610
+to mentions explicitly are goal models because they're extremely popular.
+
+50
+00:02:31,610 --> 00:02:34,930
+So the main idea with goal models is it start with the main goal of
+
+51
+00:02:34,930 --> 00:02:36,990
+the system and then keep refining it
+
+52
+00:02:36,990 --> 00:02:39,654
+by decomposing it in sub-goals. So it's kind
+
+53
+00:02:39,654 --> 00:02:41,610
+of a very natural way of progressing.
+
+54
+00:02:41,610 --> 00:02:44,210
+And you continue this refinement until you get
+
+55
+00:02:44,210 --> 00:02:47,150
+to goals that can be operationalized, and represent
+
+56
+00:02:47,150 --> 00:02:49,380
+the basic units of functionality of the system.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/28 - Analyzing Requirements - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/28 - Analyzing Requirements - lang_en_vs4.srt
new file mode 100644
index 0000000..c7d4899
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/28 - Analyzing Requirements - lang_en_vs4.srt
@@ -0,0 +1,155 @@
+1
+00:00:00,250 --> 00:00:01,940
+Now we are at the point in which we
+
+2
+00:00:01,940 --> 00:00:05,590
+have collected and modeled our requirements. So the next thing
+
+3
+00:00:05,590 --> 00:00:08,310
+that we can do is to analyze the requirements to
+
+4
+00:00:08,310 --> 00:00:11,720
+identify possible problems, and specifically there are three types of
+
+5
+00:00:11,720 --> 00:00:14,646
+analysis that we can perform. The first type of analysis
+
+6
+00:00:14,646 --> 00:00:16,820
+is verification. So in this case we're talking about the
+
+7
+00:00:16,820 --> 00:00:19,700
+requirements verification. And in verification
+
+8
+00:00:19,700 --> 00:00:21,990
+developers will study the requirements
+
+9
+00:00:21,990 --> 00:00:25,270
+to check whether they're correct, whether they accurately reflect the
+
+10
+00:00:25,270 --> 00:00:28,710
+customer needs as perceived by the developer. Developers can
+
+11
+00:00:28,710 --> 00:00:32,170
+also check the completeness of the requirements, check whether there
+
+12
+00:00:32,170 --> 00:00:34,510
+are any missing pieces in the requirements as we
+
+13
+00:00:34,510 --> 00:00:37,710
+discussed earlier. They can check whether the requirements are pertinent,
+
+14
+00:00:37,710 --> 00:00:41,260
+or contain irrelevant information, like the one shown here.
+
+15
+00:00:41,260 --> 00:00:44,670
+And they can also check whether they're consistent, unambiguous, testable
+
+16
+00:00:44,670 --> 00:00:46,920
+and so on, so all those properties that should
+
+17
+00:00:46,920 --> 00:00:50,380
+be satisfied for the requirements. A second type of analysis
+
+18
+00:00:50,380 --> 00:00:53,670
+that is typically performed on requirements is validation. And
+
+19
+00:00:53,670 --> 00:00:56,290
+the goal of validation is to assess whether the collected
+
+20
+00:00:56,290 --> 00:00:59,870
+requirements define the system that the stakeholders really want.
+
+21
+00:00:59,870 --> 00:01:02,330
+So the focus here is on the stakeholders. And in
+
+22
+00:01:02,330 --> 00:01:05,670
+some cases, stakeholders can check the requirements directly if
+
+23
+00:01:05,670 --> 00:01:08,910
+the requirements are expressed in a notation that they understand.
+
+24
+00:01:08,910 --> 00:01:11,120
+Or they might check them by discussing them with the
+
+25
+00:01:11,120 --> 00:01:15,490
+developers. Another possibility is that stakeholders asses the requirements by
+
+26
+00:01:15,490 --> 00:01:18,400
+interacting with a prototype of the system, in case
+
+27
+00:01:18,400 --> 00:01:21,690
+the requirements engineering process that is being used involves
+
+28
+00:01:21,690 --> 00:01:25,300
+early prototyping. And finally surveys, testing, and other techniques
+
+29
+00:01:25,300 --> 00:01:28,400
+can also be used to validate requirements. A final type
+
+30
+00:01:28,400 --> 00:01:30,780
+of analysis that we can perform on requirements is
+
+31
+00:01:30,780 --> 00:01:34,430
+risk analysis. And risk analysis aims to identify and
+
+32
+00:01:34,430 --> 00:01:37,680
+analyze the main risks involved with the development of
+
+33
+00:01:37,680 --> 00:01:40,560
+the system being considered. And if some requirements are deemed
+
+34
+00:01:40,560 --> 00:01:43,320
+to be too risky, like in this case, this might result in
+
+35
+00:01:43,320 --> 00:01:47,880
+changes in the requirements model to eliminate or address those risks. And note
+
+36
+00:01:47,880 --> 00:01:49,950
+that all these analysis activities can
+
+37
+00:01:49,950 --> 00:01:52,390
+be performed in many different ways depending
+
+38
+00:01:52,390 --> 00:01:53,990
+on the modeling languages chosen to
+
+39
+00:01:53,990 --> 00:01:56,150
+represent the requirements and on the context.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/29 - Requirements Prioritization - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/29 - Requirements Prioritization - lang_en_vs5.srt
new file mode 100644
index 0000000..09978d7
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/29 - Requirements Prioritization - lang_en_vs5.srt
@@ -0,0 +1,59 @@
+1
+00:00:00,140 --> 00:00:04,010
+Why collecting, modeling, and analyzing requirements? We might realize
+
+2
+00:00:04,010 --> 00:00:07,310
+that the resources available for the project are not enough
+
+3
+00:00:07,310 --> 00:00:10,000
+to satisfy all of them. For example, there's not
+
+4
+00:00:10,000 --> 00:00:13,450
+enough time, not enough money, not enough manpower. And therefore,
+
+5
+00:00:13,450 --> 00:00:15,590
+there are some requirements that we won't be able
+
+6
+00:00:15,590 --> 00:00:19,760
+to satisfy. In these cases, we must prioritize our requirements,
+
+7
+00:00:19,760 --> 00:00:22,310
+by classifying them in one of three classes. The
+
+8
+00:00:22,310 --> 00:00:25,270
+first class is mandatory requirements, and these are the requirements
+
+9
+00:00:25,270 --> 00:00:29,770
+we must satisfy. Then there are the nice to have requirements that are the
+
+10
+00:00:29,770 --> 00:00:32,170
+ones that we will satisfy if resources
+
+11
+00:00:32,170 --> 00:00:34,740
+allow. And finally, there are the superfluous
+
+12
+00:00:34,740 --> 00:00:36,440
+requirements, and those are the requirements that
+
+13
+00:00:36,440 --> 00:00:37,770
+we're going to keep around, but that we're
+
+14
+00:00:37,770 --> 00:00:40,010
+going to postpone. For example, we might decide
+
+15
+00:00:40,010 --> 00:00:41,770
+to satisfy them in the next release.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/3 - General RE Definition - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/3 - General RE Definition - lang_en_vs4.srt
new file mode 100644
index 0000000..34ec511
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/3 - General RE Definition - lang_en_vs4.srt
@@ -0,0 +1,103 @@
+1
+00:00:00,360 --> 00:00:03,900
+Basically, and roughly speaking, requirements engineering, which is
+
+2
+00:00:03,900 --> 00:00:06,630
+also called in short, RE, is the process
+
+3
+00:00:06,630 --> 00:00:10,520
+of establishing the services that the customer requires
+
+4
+00:00:10,520 --> 00:00:13,530
+from the software system. In addition to that, requirements
+
+5
+00:00:13,530 --> 00:00:16,360
+engineering also has to do with the constraints
+
+6
+00:00:16,360 --> 00:00:19,900
+under which the system operates and is developed. Requirements
+
+7
+00:00:19,900 --> 00:00:22,770
+engineering is a very important activity for several
+
+8
+00:00:22,770 --> 00:00:25,450
+reasons. In particular, as we also saw in earlier
+
+9
+00:00:25,450 --> 00:00:29,860
+lessons, many errors are made in requirement specifications. So many
+
+10
+00:00:29,860 --> 00:00:33,100
+errors are made because we don't do requirements engineering in
+
+11
+00:00:33,100 --> 00:00:35,670
+the right way. And many of these errors are not
+
+12
+00:00:35,670 --> 00:00:38,340
+being detected early. But they could be if we were
+
+13
+00:00:38,340 --> 00:00:41,350
+to do RE in the right way. And, unfortunately, not
+
+14
+00:00:41,350 --> 00:00:45,510
+detecting these errors can dramatically increase software costs. So that's
+
+15
+00:00:45,510 --> 00:00:48,250
+the reason why requirements engineering is important, and why it
+
+16
+00:00:48,250 --> 00:00:50,730
+is important to do it in the right way. The final
+
+17
+00:00:50,730 --> 00:00:53,660
+result of the requirements engineering process is a software
+
+18
+00:00:53,660 --> 00:00:58,230
+requirements specification that we also called SRS. We will discuss
+
+19
+00:00:58,230 --> 00:01:01,060
+SRS later in more details and also when we talk
+
+20
+00:01:01,060 --> 00:01:03,740
+about the projects for the course. For now, it is
+
+21
+00:01:03,740 --> 00:01:07,040
+enough to say that the software requirements specification and
+
+22
+00:01:07,040 --> 00:01:10,280
+the requirements engineering, in general, should focus on what the
+
+23
+00:01:10,280 --> 00:01:13,290
+proposed system is intended to do, and not on the
+
+24
+00:01:13,290 --> 00:01:16,280
+how it will do it. In fact, how the system
+
+25
+00:01:16,280 --> 00:01:18,450
+will do what it is required to do is something that we
+
+26
+00:01:18,450 --> 00:01:22,170
+will discuss when we talk about design of a system in later phases.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/30 - Requirements Prioritization Quiz - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/30 - Requirements Prioritization Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..9415793
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/30 - Requirements Prioritization Quiz - lang_en_vs4.srt
@@ -0,0 +1,79 @@
+1
+00:00:00,110 --> 00:00:03,090
+Now that we talked about requirements prioritization, let's try to see
+
+2
+00:00:03,090 --> 00:00:06,110
+how this might work in practice. Imagine that you have collected the
+
+3
+00:00:06,110 --> 00:00:09,560
+folowing set of five requirements for an ATM system, but only
+
+4
+00:00:09,560 --> 00:00:12,680
+have resources to satisfy two of them. Possibly three. I would like
+
+5
+00:00:12,680 --> 00:00:15,550
+for you to look at this list and suitablely prioritize the
+
+6
+00:00:15,550 --> 00:00:19,220
+requirements by marking them as mandatory, in this case you're going to put
+
+7
+00:00:19,220 --> 00:00:21,840
+an M in the space. Nice to have, in this case you're
+
+8
+00:00:21,840 --> 00:00:25,350
+going to put an N. Or superfluous, in this case you're going to put
+
+9
+00:00:25,350 --> 00:00:28,005
+an S. This is the set of requirements, the first one
+
+10
+00:00:28,005 --> 00:00:30,342
+says that the system shall check the PIN of the ATM
+
+11
+00:00:30,342 --> 00:00:33,863
+card before allowing the customer to perform an operation. The second
+
+12
+00:00:33,863 --> 00:00:37,575
+says that the system shall perform an additional biometric verification of
+
+13
+00:00:37,575 --> 00:00:40,881
+the customer identity for example a check of the customer's finger
+
+14
+00:00:40,881 --> 00:00:44,294
+prints before it allows the customer to perform an operation. Then
+
+15
+00:00:44,294 --> 00:00:47,466
+we have that the system shall allow customers to withdraw cash
+
+16
+00:00:47,466 --> 00:00:50,580
+using an ATM card. The system shall allow customer to deposit
+
+17
+00:00:50,580 --> 00:00:53,350
+money using an ATM card. And the system shall allow
+
+18
+00:00:53,350 --> 00:00:56,330
+customers to change the pin of their ATM card. So again,
+
+19
+00:00:56,330 --> 00:01:00,600
+mark those as mandatory, nice to have, or superfluous considering the
+
+20
+00:01:00,600 --> 00:01:04,170
+fact that you can satisfy only two, possibly three of them.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/31 - Requirements Prioritization Quiz Solution - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/31 - Requirements Prioritization Quiz Solution - lang_en_vs5.srt
new file mode 100644
index 0000000..e2fd768
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/31 - Requirements Prioritization Quiz Solution - lang_en_vs5.srt
@@ -0,0 +1,119 @@
+1
+00:00:00,130 --> 00:00:02,640
+Looking at the requirements, and knowing that we have only two
+
+2
+00:00:02,640 --> 00:00:05,630
+that we can satisfy for sure, it makes sense to first mark
+
+3
+00:00:05,630 --> 00:00:09,080
+as mandatory the ability to withdraw cash, which is the most typical
+
+4
+00:00:09,080 --> 00:00:12,650
+use of an ATM machine. We are therefore going to mark this requirement
+
+5
+00:00:12,650 --> 00:00:15,260
+with an M, for mandatory. It also makes sense to mark as
+
+6
+00:00:15,260 --> 00:00:18,390
+mandatory the fact that the ATM system checks the PIN of the
+
+7
+00:00:18,390 --> 00:00:21,480
+card being used by the customer, as that's the typical level of
+
+8
+00:00:21,480 --> 00:00:23,680
+security that the customer would expect,
+
+9
+00:00:23,680 --> 00:00:25,760
+therefore we're going to mark as mandatory
+
+10
+00:00:25,760 --> 00:00:28,320
+also the first requirement here. And of course we
+
+11
+00:00:28,320 --> 00:00:31,930
+could also perform biometric verification, but based on our knowledge
+
+12
+00:00:31,930 --> 00:00:33,640
+of the domain, it seems like that should be
+
+13
+00:00:33,640 --> 00:00:37,410
+an additional verification, rather than the main and only verification
+
+14
+00:00:37,410 --> 00:00:40,170
+for the system. We will therefore mark it superfluous.
+
+15
+00:00:40,170 --> 00:00:42,720
+That is something that we can postpone until a later
+
+16
+00:00:42,720 --> 00:00:45,100
+release, the second requirement. Finally,
+
+17
+00:00:45,100 --> 00:00:46,740
+another typical operation that customers
+
+18
+00:00:46,740 --> 00:00:51,070
+perform at ATM machines is depositing. Whereas changing an ATM
+
+19
+00:00:51,070 --> 00:00:53,850
+card's PIN is not such a common operation. We'll therefore mark
+
+20
+00:00:53,850 --> 00:00:57,710
+it nice to have this fourth requirement and as superfluous, the
+
+21
+00:00:57,710 --> 00:01:00,420
+last one. So at the end, what we have is that
+
+22
+00:01:00,420 --> 00:01:03,540
+we have two mandatory requirements which are the two that we can
+
+23
+00:01:03,540 --> 00:01:06,280
+satisfy for sure. One, nice to have the requirement, which is
+
+24
+00:01:06,280 --> 00:01:09,960
+the possible third requirement which we might have time to satisfy. And
+
+25
+00:01:09,960 --> 00:01:12,980
+the other two that are marked as superfluous, as something that
+
+26
+00:01:12,980 --> 00:01:16,100
+we might do later, for example in a subsequent release. And of
+
+27
+00:01:16,100 --> 00:01:19,060
+course there is something subjective in these answers. But
+
+28
+00:01:19,060 --> 00:01:22,020
+again, based on our knowledge on our understanding of
+
+29
+00:01:22,020 --> 00:01:23,910
+the domain, these are the one that makes more
+
+30
+00:01:23,910 --> 00:01:26,640
+sense for an ATM system as we know it.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/32 - Requirements Engineering Process - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/32 - Requirements Engineering Process - lang_en_vs4.srt
new file mode 100644
index 0000000..aa1ab28
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/32 - Requirements Engineering Process - lang_en_vs4.srt
@@ -0,0 +1,99 @@
+1
+00:00:00,180 --> 00:00:02,580
+Let's now put together all that we have discussed
+
+2
+00:00:02,580 --> 00:00:06,340
+and see how a requirements engineering process actually works.
+
+3
+00:00:06,340 --> 00:00:08,450
+So, first of all, we saw that requirements engineering
+
+4
+00:00:08,450 --> 00:00:12,080
+consists of three main steps. Elicitation of the requirements,
+
+5
+00:00:12,080 --> 00:00:15,450
+in which we extract requirements from various sources. Modeling
+
+6
+00:00:15,450 --> 00:00:17,880
+in which we represent the requirements using one or
+
+7
+00:00:17,880 --> 00:00:21,650
+more notations or formal reasons and analysis, in which
+
+8
+00:00:21,650 --> 00:00:25,230
+we identify possible issues with our requirements and there is
+
+9
+00:00:25,230 --> 00:00:27,870
+actually a 4th step that we kind of mention
+
+10
+00:00:27,870 --> 00:00:30,670
+but not explicitly. And this is the negotiation that can
+
+11
+00:00:30,670 --> 00:00:34,320
+happen between the stakeholders and the developers, during which
+
+12
+00:00:34,320 --> 00:00:38,400
+requirements are discussed and modified until an agreement is reached.
+
+13
+00:00:38,400 --> 00:00:40,000
+So if you want to think of this as a
+
+14
+00:00:40,000 --> 00:00:43,030
+process, so as a sequence of steps, we can see
+
+15
+00:00:43,030 --> 00:00:46,000
+that we start from elicitation. So we start by eliciting
+
+16
+00:00:46,000 --> 00:00:50,450
+an initial setup requirements. We negotiate and refine this set,
+
+17
+00:00:50,450 --> 00:00:53,820
+then we model the resulting requirements. And finally, we
+
+18
+00:00:53,820 --> 00:00:58,190
+analyze such requirements. However, the process doesn't really stop here.
+
+19
+00:00:58,190 --> 00:01:00,620
+Why? Well, because as a result of the analysis,
+
+20
+00:01:00,620 --> 00:01:03,230
+we might have to perform further elicitation. And so this
+
+21
+00:01:03,230 --> 00:01:05,850
+process is not really a sequential one, but rather
+
+22
+00:01:05,850 --> 00:01:09,340
+an iterative process. So, in practice, we continue to iterate
+
+23
+00:01:09,340 --> 00:01:12,700
+over these four steps gathering a better and better understanding
+
+24
+00:01:12,700 --> 00:01:15,560
+of the requirements at every iteration until we are happy
+
+25
+00:01:15,560 --> 00:01:18,080
+with the settle requirement that we gather and stop the process.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/33 - SRS - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/33 - SRS - lang_en_vs5.srt
new file mode 100644
index 0000000..44076db
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/33 - SRS - lang_en_vs5.srt
@@ -0,0 +1,183 @@
+1
+00:00:00,120 --> 00:00:01,800
+Before I conclude this lesson, I want to say
+
+2
+00:00:01,800 --> 00:00:06,150
+a few additional things about the Software Requirement Specification document
+
+3
+00:00:06,150 --> 00:00:08,510
+or the SRS. And I want to do that because this
+
+4
+00:00:08,510 --> 00:00:10,900
+is a very important document and some of the projects
+
+5
+00:00:10,900 --> 00:00:13,160
+actually require you to produce one. So why is
+
+6
+00:00:13,160 --> 00:00:16,760
+the Requirement Specification such an important document? That's because a
+
+7
+00:00:16,760 --> 00:00:20,840
+Software Requirement Specification document is an important fundamental way to
+
+8
+00:00:20,840 --> 00:00:25,310
+communicate. Requirements to others. For example they represent a common
+
+9
+00:00:25,310 --> 00:00:29,490
+ground between analysts and stakeholders. Note however, that different
+
+10
+00:00:29,490 --> 00:00:32,810
+projects might require different software requirement specifications so you
+
+11
+00:00:32,810 --> 00:00:35,560
+need to know your context. For example, the SRS
+
+12
+00:00:35,560 --> 00:00:38,140
+document that you have to create for a small project
+
+13
+00:00:38,140 --> 00:00:40,690
+performed by a few developers can in most cases.
+
+14
+00:00:40,690 --> 00:00:43,570
+Be a concise and informal one. Conversely the software
+
+15
+00:00:43,570 --> 00:00:47,000
+requirement specification for a multi-year project, involving a number
+
+16
+00:00:47,000 --> 00:00:50,480
+of developers can be a fairly complex and extensive document.
+
+17
+00:00:50,480 --> 00:00:52,000
+So again you have to be aware of your
+
+18
+00:00:52,000 --> 00:00:55,520
+context and build your software requirement specification accordingly. In
+
+19
+00:00:55,520 --> 00:00:58,536
+order to have a common format for the SRS
+
+20
+00:00:58,536 --> 00:01:01,380
+document, IEEE defined a standard that divides the document in
+
+21
+00:01:01,380 --> 00:01:04,349
+predefined sections. And in the context of this course,
+
+22
+00:01:04,349 --> 00:01:07,530
+we will use a simplified version of the IEEE
+
+23
+00:01:07,530 --> 00:01:11,400
+SRS format that includes three main sections. An introduction,
+
+24
+00:01:11,400 --> 00:01:15,540
+which discusses the purpose, context, and objectives of the project.
+
+25
+00:01:15,540 --> 00:01:18,500
+A user requirements definition, which contains the user
+
+26
+00:01:18,500 --> 00:01:22,690
+requirements. And the system requirements specification, which includes both
+
+27
+00:01:22,690 --> 00:01:26,800
+functional and non-functional requirements. And we provide more information
+
+28
+00:01:26,800 --> 00:01:29,430
+about this format when we discuss the projects. So
+
+29
+00:01:29,430 --> 00:01:31,140
+to conclude the lesson, I want to point
+
+30
+00:01:31,140 --> 00:01:33,670
+out and in some cases recap a few important
+
+31
+00:01:33,670 --> 00:01:37,150
+characteristics that requirements should have. First of all, requirements
+
+32
+00:01:37,150 --> 00:01:40,740
+should be simple. Not compound. Each requirement should express
+
+33
+00:01:40,740 --> 00:01:43,710
+one specific piece of functionality that the system
+
+34
+00:01:43,710 --> 00:01:47,000
+should provide. Requirements should be testable. We mentioned
+
+35
+00:01:47,000 --> 00:01:48,660
+this before, but I want to stress it
+
+36
+00:01:48,660 --> 00:01:51,820
+because it is a very important point. Untestable requirements
+
+37
+00:01:51,820 --> 00:01:53,850
+such as the system should be fast, are
+
+38
+00:01:53,850 --> 00:01:58,180
+useless. Requirements should be organized. Related requirements should be
+
+39
+00:01:58,180 --> 00:02:01,220
+grouped, more abstract requirements should contain more detailed
+
+40
+00:02:01,220 --> 00:02:05,400
+requirements, and priorities should be clearly indicated when present.
+
+41
+00:02:05,400 --> 00:02:07,532
+Finally, requirements should be numbered, so
+
+42
+00:02:07,532 --> 00:02:09,538
+that they can be traced. For example,
+
+43
+00:02:09,538 --> 00:02:11,430
+numbered requirements will allow you to trace
+
+44
+00:02:11,430 --> 00:02:14,510
+them to design. Implementation and testing elements
+
+45
+00:02:14,510 --> 00:02:17,350
+and items, which is something that you might have to do for one of
+
+46
+00:02:17,350 --> 00:02:20,680
+the projects. And that we will discuss in more detail in a later class.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/4 - Software Intensive Systems - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/4 - Software Intensive Systems - lang_en_vs5.srt
new file mode 100644
index 0000000..28c70ad
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/4 - Software Intensive Systems - lang_en_vs5.srt
@@ -0,0 +1,111 @@
+1
+00:00:00,100 --> 00:00:03,100
+In our initial definition of requirements engineering, we talked about
+
+2
+00:00:03,100 --> 00:00:06,130
+software systems. But what do we really mean when we
+
+3
+00:00:06,130 --> 00:00:09,980
+use the term software? Software is an abstract description of
+
+4
+00:00:09,980 --> 00:00:13,920
+a set of computations that becomes concrete, and therefore useful, only
+
+5
+00:00:13,920 --> 00:00:16,600
+when we run the software on some hardware, and that,
+
+6
+00:00:16,600 --> 00:00:19,310
+in the context of some human activity that it can
+
+7
+00:00:19,310 --> 00:00:22,530
+support. So what does that mean exactly? What that means
+
+8
+00:00:22,530 --> 00:00:25,235
+is that when we say software, what we really mean is
+
+9
+00:00:25,235 --> 00:00:28,790
+a software intensive system. That is, the combination
+
+10
+00:00:28,790 --> 00:00:31,930
+of 3 things, the software, the hardware on which
+
+11
+00:00:31,930 --> 00:00:34,610
+the software runs, and the context in which the
+
+12
+00:00:34,610 --> 00:00:37,470
+software is used. Just to illustrate, let me show
+
+13
+00:00:37,470 --> 00:00:40,010
+you this through a picture. What I'm showing here
+
+14
+00:00:40,010 --> 00:00:42,830
+is a customer, a user, that is using, is
+
+15
+00:00:42,830 --> 00:00:47,000
+accessing, an ATM machine. And this action involves several
+
+16
+00:00:47,000 --> 00:00:50,650
+things. There is the software that drives the logic
+
+17
+00:00:50,650 --> 00:00:53,410
+of the ATM machine. There is the hardware on
+
+18
+00:00:53,410 --> 00:00:57,280
+which the software runs. And there is the context
+
+19
+00:00:57,280 --> 00:00:59,850
+In which the software is used. And in this
+
+20
+00:00:59,850 --> 00:01:02,660
+case, the context is the bank. And only by
+
+21
+00:01:02,660 --> 00:01:06,105
+considering these 3 things together can we really understand
+
+22
+00:01:06,105 --> 00:01:09,510
+the functionality that is represented here. So the bottom
+
+23
+00:01:09,510 --> 00:01:12,690
+line here is that we usually take hardware and
+
+24
+00:01:12,690 --> 00:01:15,750
+context for granted in this equation. But they actually
+
+25
+00:01:15,750 --> 00:01:18,210
+need to be explicitly considered when building a
+
+26
+00:01:18,210 --> 00:01:20,770
+system. Otherwise, we might forget this is all
+
+27
+00:01:20,770 --> 00:01:23,850
+the functionality, and ultimately of the requirements. And
+
+28
+00:01:23,850 --> 00:01:25,640
+we might end up with the wrong system.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/5 - Software Quality - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/5 - Software Quality - lang_en_vs4.srt
new file mode 100644
index 0000000..86db606
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/5 - Software Quality - lang_en_vs4.srt
@@ -0,0 +1,111 @@
+1
+00:00:00,170 --> 00:00:02,920
+So, let's see how this affects the concept of software
+
+2
+00:00:02,920 --> 00:00:05,620
+quality. Another way to express what we just said is
+
+3
+00:00:05,620 --> 00:00:08,220
+to say that the software runs on some hardware and
+
+4
+00:00:08,220 --> 00:00:11,750
+is developed for a purpose that is related to human
+
+5
+00:00:11,750 --> 00:00:14,870
+activities. And given this perspective, we can define what we
+
+6
+00:00:14,870 --> 00:00:18,440
+mean by software quality in this light. Software quality is
+
+7
+00:00:18,440 --> 00:00:22,290
+not just a function of the software. So, the software
+
+8
+00:00:22,290 --> 00:00:25,610
+itself does not define the quality of the overall system.
+
+9
+00:00:25,610 --> 00:00:28,880
+Rather, software quality is a function of both the
+
+10
+00:00:28,880 --> 00:00:32,259
+software and its purpose. Where purpose has to do with
+
+11
+00:00:32,259 --> 00:00:34,840
+the way in which the software will be used. So
+
+12
+00:00:34,840 --> 00:00:37,950
+a software system can be of low quality not only
+
+13
+00:00:37,950 --> 00:00:40,580
+because it does not work well. So, for example, not
+
+14
+00:00:40,580 --> 00:00:43,620
+only because it crashes. Of course, that's an issue. But
+
+15
+00:00:43,620 --> 00:00:47,000
+just as importantly, a software can also be of low
+
+16
+00:00:47,000 --> 00:00:50,720
+quality because it does not fulfill its purpose, and this
+
+17
+00:00:50,720 --> 00:00:53,960
+happens quite often. It is unfortunately not rare for
+
+18
+00:00:53,960 --> 00:00:57,310
+the software producers to have an inadequate understanding, or even
+
+19
+00:00:57,310 --> 00:01:00,450
+a complete misunderstanding of the purpose of the software,
+
+20
+00:01:00,450 --> 00:01:03,200
+of what the users want to do and will do
+
+21
+00:01:03,200 --> 00:01:05,770
+with it. Turning these around, we can therefore define
+
+22
+00:01:05,770 --> 00:01:09,890
+the quality of software in terms of fitness for purpose.
+
+23
+00:01:09,890 --> 00:01:12,990
+The more the software fulfills its purpose, the more
+
+24
+00:01:12,990 --> 00:01:16,040
+the software is on target, the higher is its quality.
+
+25
+00:01:16,040 --> 00:01:19,600
+And identifying the purpose of the software, so hitting
+
+26
+00:01:19,600 --> 00:01:23,550
+this target, is exactly the goal of requirements engineering.
+
+27
+00:01:23,550 --> 00:01:25,970
+And it is the reason why requirements engineering is
+
+28
+00:01:25,970 --> 00:01:29,370
+such a fundamental activity in the context of software engineering.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/6 - Identifying Purpose - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/6 - Identifying Purpose - lang_en_vs4.srt
new file mode 100644
index 0000000..0accc39
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/6 - Identifying Purpose - lang_en_vs4.srt
@@ -0,0 +1,107 @@
+1
+00:00:00,050 --> 00:00:03,480
+And identifying the purpose of a softer system means
+
+2
+00:00:03,480 --> 00:00:06,980
+defining the requirements for the system. And if you have
+
+3
+00:00:06,980 --> 00:00:09,540
+ever done anything like that, for example, we did
+
+4
+00:00:09,540 --> 00:00:12,060
+it for the first project in the previous mini course,
+
+5
+00:00:12,060 --> 00:00:14,720
+you will know that it is an extremely hard
+
+6
+00:00:14,720 --> 00:00:17,760
+task. Identifying the purpose of the software and defining its
+
+7
+00:00:17,760 --> 00:00:21,600
+requirements is very, very hard. Why is it so hard?
+
+8
+00:00:21,600 --> 00:00:25,560
+First of all, the purpose of most systems is inherently,
+
+9
+00:00:25,560 --> 00:00:27,920
+extremely complex, so this has to do with the
+
+10
+00:00:27,920 --> 00:00:31,330
+sheer complexity of the purpose of the requirements. Just think
+
+11
+00:00:31,330 --> 00:00:34,810
+of how complex is the functionality provided by most systems.
+
+12
+00:00:34,810 --> 00:00:38,790
+Second, it is hard, very hard to extract from humans
+
+13
+00:00:38,790 --> 00:00:41,780
+this purpose and make it explicit. So, paraphrasing a
+
+14
+00:00:41,780 --> 00:00:45,130
+famous quote from the late Steve Jobs, often people don't
+
+15
+00:00:45,130 --> 00:00:47,475
+know what they want until you show it to them.
+
+16
+00:00:47,475 --> 00:00:50,490
+It's hard to figure out what people really want. Third,
+
+17
+00:00:50,490 --> 00:00:54,260
+requirements often change over time. Customers change their
+
+18
+00:00:54,260 --> 00:00:57,490
+mind. Designing and building a system raises new requirements.
+
+19
+00:00:57,490 --> 00:01:00,270
+So for many reasons requirements tend not to
+
+20
+00:01:00,270 --> 00:01:02,760
+be stable, tend to evolve. And that, of course,
+
+21
+00:01:02,760 --> 00:01:05,440
+makes it harder to collect them. Finally, for
+
+22
+00:01:05,440 --> 00:01:09,600
+any realistic system, there are many stakeholders and they
+
+23
+00:01:09,600 --> 00:01:12,990
+often have conflicting goals and requirements. And it
+
+24
+00:01:12,990 --> 00:01:15,900
+can be very hard to reconcile the possibly conflicting
+
+25
+00:01:15,900 --> 00:01:19,630
+requirements that might emerge in these cases. So for all these reasons,
+
+26
+00:01:19,630 --> 00:01:21,230
+it is very, very difficult to
+
+27
+00:01:21,230 --> 00:01:23,930
+perform requirements engineering in an effective way.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/7 - Completeness and Pertinence - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/7 - Completeness and Pertinence - lang_en_vs5.srt
new file mode 100644
index 0000000..c0ce159
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/7 - Completeness and Pertinence - lang_en_vs5.srt
@@ -0,0 +1,103 @@
+1
+00:00:00,350 --> 00:00:03,610
+These issues and difficulties can result in requirements
+
+2
+00:00:03,610 --> 00:00:06,780
+that show various problems. Two particularly relevant and
+
+3
+00:00:06,780 --> 00:00:10,880
+common problems are completeness and pertinence. Or better,
+
+4
+00:00:10,880 --> 00:00:14,750
+the lack of completeness and pertinence. Completeness refers to
+
+5
+00:00:14,750 --> 00:00:17,560
+the fact that it is often extremely difficult
+
+6
+00:00:17,560 --> 00:00:20,370
+to identify all of the requirements. That is it
+
+7
+00:00:20,370 --> 00:00:22,890
+is very difficult to have a complete picture
+
+8
+00:00:22,890 --> 00:00:25,780
+of the purpose of the software. So what happens
+
+9
+00:00:25,780 --> 00:00:28,540
+is that incomplete requirements are collected and the software
+
+10
+00:00:28,540 --> 00:00:32,500
+is missing functionality that is important for the user. Pertinence
+
+11
+00:00:32,500 --> 00:00:34,720
+conversely has to do with the relevance of the
+
+12
+00:00:34,720 --> 00:00:38,770
+requirements. To avoid completeness problems developers often end up collecting
+
+13
+00:00:38,770 --> 00:00:42,640
+a lot of irrelevant when not conflicting requirements. In
+
+14
+00:00:42,640 --> 00:00:45,060
+these cases what can happen is that the software could
+
+15
+00:00:45,060 --> 00:00:47,120
+either end up being bloated that is it might
+
+16
+00:00:47,120 --> 00:00:51,290
+contain a needed functionality. The functionality represented by these extra
+
+17
+00:00:51,290 --> 00:00:54,120
+requirements or it might even be impossible to build the
+
+18
+00:00:54,120 --> 00:00:57,480
+software due to the conflicting additional requirements. And to make
+
+19
+00:00:57,480 --> 00:01:00,920
+things even worse collecting all of these requirements sometimes doesn't
+
+20
+00:01:00,920 --> 00:01:03,390
+even solve the completeness issue. So you might end up
+
+21
+00:01:03,390 --> 00:01:05,800
+with a set of requirements that is not only incomplete
+
+22
+00:01:05,800 --> 00:01:08,740
+but it also contains extra information that can be harmful
+
+23
+00:01:08,740 --> 00:01:11,450
+to the system. So again the bottom line is that
+
+24
+00:01:11,450 --> 00:01:14,310
+gathering an adequate, accurate, complete,
+
+25
+00:01:14,310 --> 00:01:16,500
+and pertinent set of requirements that
+
+26
+00:01:16,500 --> 00:01:20,100
+identify the purpose of a software system is an arduous task.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/8 - Pertinence Quiz - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/8 - Pertinence Quiz - lang_en_vs5.srt
new file mode 100644
index 0000000..a04a9a9
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/8 - Pertinence Quiz - lang_en_vs5.srt
@@ -0,0 +1,35 @@
+1
+00:00:00,100 --> 00:00:03,530
+Now that we talked about completeness and pertinence, let's consider an
+
+2
+00:00:03,530 --> 00:00:06,200
+information system for a gym. I'm going to give you a
+
+3
+00:00:06,200 --> 00:00:09,580
+list of possible requirements and I want you to mark in
+
+4
+00:00:09,580 --> 00:00:13,530
+that list all the requirements that you believe are pertinent. So let
+
+5
+00:00:13,530 --> 00:00:16,030
+me read the list. Members of the gym shall be able
+
+6
+00:00:16,030 --> 00:00:18,770
+to access their training programs. The system shall be able to
+
+7
+00:00:18,770 --> 00:00:21,894
+read member cards. The system shall be able to store members'
+
+8
+00:00:21,894 --> 00:00:25,150
+commute time. Personal trainers shall be able to add clients. And the
+
+9
+00:00:25,150 --> 00:00:27,570
+list of members shall be stored as a linked list.
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/9 - Pertinence Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/9 - Pertinence Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..ee4f04f
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/9 - Pertinence Quiz Solution - lang_en_vs4.srt
@@ -0,0 +1,75 @@
+1
+00:00:00,190 --> 00:00:03,620
+So the first requirement is definitely pertinent. Members of the gym shall
+
+2
+00:00:03,620 --> 00:00:06,740
+be able to access their training programs. It's pretty normal for members of
+
+3
+00:00:06,740 --> 00:00:09,710
+the gym to have a training program. And therefore, the system should allow
+
+4
+00:00:09,710 --> 00:00:12,900
+them to access them. Similarly for the second one. The system shall be
+
+5
+00:00:12,900 --> 00:00:15,450
+able to read member cards. Normally when you get into a gym
+
+6
+00:00:15,450 --> 00:00:17,420
+if you have a member card, you'll have to either show it to
+
+7
+00:00:17,420 --> 00:00:21,010
+somebody, or nowadays swipe it, and so the system should be able to
+
+8
+00:00:21,010 --> 00:00:23,410
+recognize the customer given the card.
+
+9
+00:00:23,410 --> 00:00:25,710
+The third requirement is probably not pertinent,
+
+10
+00:00:25,710 --> 00:00:29,090
+because I cannot think of any meaningful case in which the system
+
+11
+00:00:29,090 --> 00:00:32,729
+should know what is the members' commute time. The fourth requirement, personal
+
+12
+00:00:32,729 --> 00:00:36,750
+trainers shall be able to add clients, is also probably pertinent. Assuming
+
+13
+00:00:36,750 --> 00:00:38,870
+that we have personal trainers in the gym, and they should be
+
+14
+00:00:38,870 --> 00:00:41,710
+able to get clients, to work with the clients of the gym,
+
+15
+00:00:41,710 --> 00:00:44,140
+and therefore, they should be able to add them as their clients
+
+16
+00:00:44,140 --> 00:00:47,620
+to the system. And finally, the last requirement, the list of members
+
+17
+00:00:47,620 --> 00:00:50,800
+shall be stores as a linked list. This is really something about
+
+18
+00:00:50,800 --> 00:00:54,130
+the how, more than the what. And therefore, for what we say before
+
+19
+00:00:54,130 --> 00:00:57,720
+is probably not a pertinent requirement, so we're not going to mark this one.
author	Nguyễn Gia Phong <mcsinyx@disroot.org>	2020-05-24 16:34:31 +0700
committer	Nguyễn Gia Phong <mcsinyx@disroot.org>	2020-05-24 16:34:31 +0700
commit	b2d80610db6beda38573890ed169815e495bc663 (patch)
tree	176e1bca6fe644c619d53cf1c24682c244b79cf6 /usth/ICT2.7/P2L1 Requirements Engineering Subtitles
parent	49376ab97c7427f1c1eca64072d1a934c2e52f50 (diff)
download	cp-b2d80610db6beda38573890ed169815e495bc663.tar.gz