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