1 files changed, 207 insertions, 0 deletions
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.