diff options
Diffstat (limited to 'usth/ICT2.7/P2L1 Requirements Engineering Subtitles')
33 files changed, 0 insertions, 3747 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 deleted file mode 100644 index 27581a6..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/1 - Lesson Overview - lang_en_vs4.srt +++ /dev/null @@ -1,55 +0,0 @@ -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 deleted file mode 100644 index 1ab5b4a..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/10 - Completeness Quiz - lang_en_vs4.srt +++ /dev/null @@ -1,15 +0,0 @@ -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 deleted file mode 100644 index 2ddc7e9..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/11 - Completeness Quiz Solution - lang_en_vs4.srt +++ /dev/null @@ -1,23 +0,0 @@ -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 deleted file mode 100644 index 5b5fe86..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/12 - Irrelevant Requirements Quiz - lang_en_vs4.srt +++ /dev/null @@ -1,43 +0,0 @@ -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 deleted file mode 100644 index f1c51c1..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/13 - Irrelevant Requirements Quiz Solution - lang_en_vs5.srt +++ /dev/null @@ -1,63 +0,0 @@ -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 deleted file mode 100644 index 7497280..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/14 - Best Practices - lang_en_vs5.srt +++ /dev/null @@ -1,83 +0,0 @@ -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 deleted file mode 100644 index bcc06a5..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/15 - RE Definition Breakdown - lang_en_vs4.srt +++ /dev/null @@ -1,207 +0,0 @@ -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 deleted file mode 100644 index 2c8dde2..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/16 - Defining Requirements - lang_en_vs4.srt +++ /dev/null @@ -1,219 +0,0 @@ -1 -00:00:00,220 --> 00:00:02,120 -So at this point, we have talked quite a bit about - -2 -00:00:02,120 --> 00:00:03,800 -requirements engineering, but we haven't - -3 -00:00:03,800 --> 00:00:06,450 -really discussed what are requirements exactly. - -4 -00:00:06,450 --> 00:00:08,880 -So what is a requirement? To define that I am going - -5 -00:00:08,880 --> 00:00:11,860 -to use this diagram which is a classical one. So you might - -6 -00:00:11,860 --> 00:00:14,980 -have seen it before. So, discussing this diagram allows me to - -7 -00:00:14,980 --> 00:00:18,720 -point out a few interesting things about requirements and define them - -8 -00:00:18,720 --> 00:00:21,660 -in a better way. At a high level this diagram contains - -9 -00:00:21,660 --> 00:00:24,780 -two main parts, the domain of the machine, which is the hardware, - -10 -00:00:24,780 --> 00:00:27,670 -operating system, libraries and so on, on which the - -11 -00:00:27,670 --> 00:00:30,860 -software will run. And the domain of the application, which - -12 -00:00:30,860 --> 00:00:33,510 -is a world in which the software will operate. - -13 -00:00:33,510 --> 00:00:36,690 -And the machine domain is characterized by computers, which are - -14 -00:00:36,690 --> 00:00:39,980 -the hardware devices, and programs, which is the software - -15 -00:00:39,980 --> 00:00:43,430 -that runs on these devices. The application domain, conversely, is - -16 -00:00:43,430 --> 00:00:47,370 -characterized by domain properties, which are things that are true - -17 -00:00:47,370 --> 00:00:50,330 -of the world anyways, whether I'm building my system or - -18 -00:00:50,330 --> 00:00:53,510 -not, and requirements, which are things in the world we - -19 -00:00:53,510 --> 00:00:56,220 -would like to achieve by delivering the system that we are - -20 -00:00:56,220 --> 00:00:59,400 -building. Basically, to put it in a different way, the former, - -21 -00:00:59,400 --> 00:01:02,950 -the domain properties, represents the assumptions that we make on the - -22 -00:01:02,950 --> 00:01:06,740 -domain. And the latter, the requirements, are the actual requirements - -23 -00:01:06,740 --> 00:01:09,660 -that we aim to collect. So we have something here, right, - -24 -00:01:09,660 --> 00:01:13,380 -at the intersection of this application domain and this machine domain. - -25 -00:01:13,380 --> 00:01:15,570 -And what is that? And this is what we normally call - -26 -00:01:15,570 --> 00:01:19,225 -the specification, which is a description, often a formal description, - -27 -00:01:19,225 --> 00:01:22,120 -of what the system that we are building should do to - -28 -00:01:22,120 --> 00:01:25,520 -meet the requirements. So this is a bridge between these two - -29 -00:01:25,520 --> 00:01:29,380 -domains. And as the graphical depiction shows, the specification is written - -30 -00:01:29,380 --> 00:01:33,220 -in terms of shared phenomena. Things that are observable in both - -31 -00:01:33,220 --> 00:01:35,980 -the machine domain and the application domain. And just to make - -32 -00:01:35,980 --> 00:01:37,540 -things a little more concrete, I want to give you a - -33 -00:01:37,540 --> 00:01:41,180 -couple of examples of what these phenomena, these shared phenomena, are. - -34 -00:01:41,180 --> 00:01:43,350 -And we can think about two main kinds of phenomena. - -35 -00:01:43,350 --> 00:01:46,080 -The first one are events in the real world that the - -36 -00:01:46,080 --> 00:01:50,140 -machine can directly sense. For example, a button being pushed or - -37 -00:01:50,140 --> 00:01:53,910 -a sensor being activated. These are events that happen here, but - -38 -00:01:53,910 --> 00:01:56,500 -that the machine can detect. So they're events that can - -39 -00:01:56,500 --> 00:01:59,650 -be used to define the specification. And the second type of - -40 -00:01:59,650 --> 00:02:02,890 -phenomena are actions in the real world that the machine can - -41 -00:02:02,890 --> 00:02:06,380 -directly cause. For example, an image appearing on a screen or - -42 -00:02:06,380 --> 00:02:09,300 -a device being turned on and off. Again, this is something - -43 -00:02:09,300 --> 00:02:12,460 -that the machine can make happen and then can have manifestation in - -44 -00:02:12,460 --> 00:02:15,520 -the real world. And again this is therefore something on which - -45 -00:02:15,520 --> 00:02:17,720 -the specification can predicate, something that - -46 -00:02:17,720 --> 00:02:19,750 -we can describe in our specification. - -47 -00:02:19,750 --> 00:02:22,860 -And this is sort of a philosophical discussion, but even if - -48 -00:02:22,860 --> 00:02:26,210 -you don't care about the philosophical discussion, the one take away point - -49 -00:02:26,210 --> 00:02:28,800 -that I would like for you to get from this discussion is - -50 -00:02:28,800 --> 00:02:31,392 -the fact that when writing a specification you have to be aware - -51 -00:02:31,392 --> 00:02:34,860 -of the fact that you're talking about shared phenomena. Events in the real - -52 -00:02:34,860 --> 00:02:39,100 -world that the machine can sense and actions in the real world that the - -53 -00:02:39,100 --> 00:02:43,048 -machine can cause. So this is what the specification is about, a bridge between - -54 -00:02:43,048 --> 00:02:44,760 -these two worlds that define what the - -55 -00:02:44,760 --> 00:02:47,170 -system should do to satisfy the requirements. 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 deleted file mode 100644 index 343e3cb..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/17 - Defining Requirements Quiz - lang_en_vs4.srt +++ /dev/null @@ -1,79 +0,0 @@ -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 deleted file mode 100644 index 7fcbd53..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/18 - Defining Requirements Quiz Solution - lang_en_vs5.srt +++ /dev/null @@ -1,103 +0,0 @@ -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 deleted file mode 100644 index 1cff519..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/19 - Functional and Nonfunctional Requirements - lang_en_vs4.srt +++ /dev/null @@ -1,139 +0,0 @@ -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 deleted file mode 100644 index 2a1bc1c..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/2 - Interview with Jane Cleland-Huang - lang_en_vs5.srt +++ /dev/null @@ -1,411 +0,0 @@ -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 ->> Fine. Thank you Alex. - -11 -00:00:27,990 --> 00:00:29,480 ->> 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 ->> 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 ->> 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 ->> 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 ->> 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 ->> 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 ->> Okay. So that's critical. I mean, we better get our requirements right. - -93 -00:04:56,441 --> 00:04:56,987 ->> Yeah. - -94 -00:04:56,987 --> 00:04:57,733 ->> That's, that's the message. - -95 -00:04:57,733 --> 00:04:57,743 ->> Yeah. - -96 -00:04:57,743 --> 00:05:00,822 ->> 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 ->> Bye Alex, thank you. - -100 -00:05:08,480 --> 00:05:10,890 ->> 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 deleted file mode 100644 index 2da3f58..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/20 - User and System Requirements - lang_en_vs4.srt +++ /dev/null @@ -1,111 +0,0 @@ -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 deleted file mode 100644 index 4b416e8..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/21 - Requirements Quiz - lang_en_vs4.srt +++ /dev/null @@ -1,43 +0,0 @@ -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 deleted file mode 100644 index e957484..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/22 - Requirements Quiz Solution - lang_en_vs4.srt +++ /dev/null @@ -1,63 +0,0 @@ -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 deleted file mode 100644 index 6fe4931..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/23 - Requirement Origins - lang_en_vs4.srt +++ /dev/null @@ -1,71 +0,0 @@ -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 deleted file mode 100644 index 2d81db7..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/24 - Elicitation Problems - lang_en_vs4.srt +++ /dev/null @@ -1,179 +0,0 @@ -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 deleted file mode 100644 index cc58665..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/25 - Traditional Techniques - lang_en_vs5.srt +++ /dev/null @@ -1,207 +0,0 @@ -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 deleted file mode 100644 index f29fb9c..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/26 - Other Techniques - lang_en_vs5.srt +++ /dev/null @@ -1,71 +0,0 @@ -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 deleted file mode 100644 index d4ade17..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/27 - Modeling Requirements - lang_en_vs4.srt +++ /dev/null @@ -1,223 +0,0 @@ -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 deleted file mode 100644 index c7d4899..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/28 - Analyzing Requirements - lang_en_vs4.srt +++ /dev/null @@ -1,155 +0,0 @@ -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 deleted file mode 100644 index 09978d7..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/29 - Requirements Prioritization - lang_en_vs5.srt +++ /dev/null @@ -1,59 +0,0 @@ -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 deleted file mode 100644 index 34ec511..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/3 - General RE Definition - lang_en_vs4.srt +++ /dev/null @@ -1,103 +0,0 @@ -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 deleted file mode 100644 index 9415793..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/30 - Requirements Prioritization Quiz - lang_en_vs4.srt +++ /dev/null @@ -1,79 +0,0 @@ -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 deleted file mode 100644 index e2fd768..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/31 - Requirements Prioritization Quiz Solution - lang_en_vs5.srt +++ /dev/null @@ -1,119 +0,0 @@ -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 deleted file mode 100644 index aa1ab28..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/32 - Requirements Engineering Process - lang_en_vs4.srt +++ /dev/null @@ -1,99 +0,0 @@ -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 deleted file mode 100644 index 44076db..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/33 - SRS - lang_en_vs5.srt +++ /dev/null @@ -1,183 +0,0 @@ -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 deleted file mode 100644 index 28c70ad..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/4 - Software Intensive Systems - lang_en_vs5.srt +++ /dev/null @@ -1,111 +0,0 @@ -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 deleted file mode 100644 index 86db606..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/5 - Software Quality - lang_en_vs4.srt +++ /dev/null @@ -1,111 +0,0 @@ -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 deleted file mode 100644 index 0accc39..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/6 - Identifying Purpose - lang_en_vs4.srt +++ /dev/null @@ -1,107 +0,0 @@ -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 deleted file mode 100644 index c0ce159..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/7 - Completeness and Pertinence - lang_en_vs5.srt +++ /dev/null @@ -1,103 +0,0 @@ -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 deleted file mode 100644 index a04a9a9..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/8 - Pertinence Quiz - lang_en_vs5.srt +++ /dev/null @@ -1,35 +0,0 @@ -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 deleted file mode 100644 index ee4f04f..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/9 - Pertinence Quiz Solution - lang_en_vs4.srt +++ /dev/null @@ -1,75 +0,0 @@ -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. |