diff options
Diffstat (limited to 'usth/ICT2.7/P2L1 Requirements Engineering Subtitles/15 - RE Definition Breakdown - lang_en_vs4.srt')
| -rw-r--r-- | usth/ICT2.7/P2L1 Requirements Engineering Subtitles/15 - RE Definition Breakdown - lang_en_vs4.srt | 207 |
1 files changed, 0 insertions, 207 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 deleted file mode 100644 index bcc06a5..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/15 - RE Definition Breakdown - lang_en_vs4.srt +++ /dev/null @@ -1,207 +0,0 @@ -1 -00:00:00,130 --> 00:00:02,540 -But how can we do that? How can we identify the purpose - -2 -00:00:02,540 --> 00:00:06,080 -of the system and collect good requirements? To answer that question, let me - -3 -00:00:06,080 --> 00:00:07,800 -give you another definition of requirements - -4 -00:00:07,800 --> 00:00:09,590 -engineering. And this one is a classical - -5 -00:00:09,590 --> 00:00:13,010 -one, one that summarizes what we discussed so far, and then we can - -6 -00:00:13,010 --> 00:00:16,180 -use as some sort of reference. And it is a little long. - -7 -00:00:16,180 --> 00:00:18,710 -Definitely longer than the one that we saw at the beginning. But it's - -8 -00:00:18,710 --> 00:00:21,840 -an important one and it contains a lot of very relevant points. So, - -9 -00:00:21,840 --> 00:00:25,210 -we're going to go through it and highlight these points. So the definition says, - -10 -00:00:25,210 --> 00:00:28,970 -that the requirements engineering is a set of activities concerned - -11 -00:00:28,970 --> 00:00:32,990 -with identifying and communicating the purpose of a software intensive - -12 -00:00:32,990 --> 00:00:35,770 -system and the context in which it will be used. - -13 -00:00:35,770 --> 00:00:38,570 -And this is exactly what we said at the beginning. But - -14 -00:00:38,570 --> 00:00:40,940 -something we can highlight in here, is the fact that - -15 -00:00:40,940 --> 00:00:44,210 -we're talking about a set of activities. So, what that means - -16 -00:00:44,210 --> 00:00:46,800 -is that requirements engineering is not just a phase or - -17 -00:00:46,800 --> 00:00:51,050 -a stage. It also says that it's about identifying and communicating. - -18 -00:00:51,050 --> 00:00:53,720 -And what that is telling us is that communication is - -19 -00:00:53,720 --> 00:00:56,670 -as important as the analysis. So, it's important to be - -20 -00:00:56,670 --> 00:00:59,990 -able to communicate these requirements not only to collect them. - -21 -00:00:59,990 --> 00:01:02,018 -And we will discuss many reasons why that is the - -22 -00:01:02,018 --> 00:01:05,880 -case. It explicitly talks about purpose. So that allows me - -23 -00:01:05,880 --> 00:01:10,310 -to stress, once more, that quality means fitness-for-purpose. We cannot - -24 -00:01:10,310 --> 00:01:14,410 -say anything about quality unless we understand the purpose. And - -25 -00:01:14,410 --> 00:01:16,210 -the last thing I want to point out in this first - -26 -00:01:16,210 --> 00:01:18,420 -part of the definition is the use of the term - -27 -00:01:18,420 --> 00:01:21,060 -context. This is also something else that we mentioned at - -28 -00:01:21,060 --> 00:01:24,890 -the beginning, that designers, analysts, need to know how and - -29 -00:01:24,890 --> 00:01:28,015 -where the system will be used. Without this information, you - -30 -00:01:28,015 --> 00:01:30,455 -cannot really understand what the system should do and you - -31 -00:01:30,455 --> 00:01:33,280 -cannot really build the system. So now, let's continue and - -32 -00:01:33,280 --> 00:01:35,755 -read the second part of the definition that says, hence. - -33 -00:01:35,755 --> 00:01:41,550 -Requirements engineering acts as the bridge between the real-world needs of - -34 -00:01:41,550 --> 00:01:45,315 -users, customers, and other constituencies affected by a - -35 -00:01:45,315 --> 00:01:49,440 -software system and the capabilities and opportunities afforded - -36 -00:01:49,440 --> 00:01:52,870 -by software-intensive technologies. This is a long sentence, - -37 -00:01:52,870 --> 00:01:55,030 -but also here, we can point out a - -38 -00:01:55,030 --> 00:01:57,670 -few interesting and relevant points. Let me start - -39 -00:01:57,670 --> 00:02:00,612 -by highlighting two parts. Real-world needs, and the - -40 -00:02:00,612 --> 00:02:04,150 -capabilities, and opportunities. So, what are these two - -41 -00:02:04,150 --> 00:02:07,000 -parts telling us? They are telling us that requirements - -42 -00:02:07,000 --> 00:02:09,949 -are partly about what is needed, the real-world needs - -43 -00:02:09,949 --> 00:02:13,520 -of all these stakeholders. But they're also partly about what - -44 -00:02:13,520 --> 00:02:16,100 -is possible, what we can actually build. We need - -45 -00:02:16,100 --> 00:02:19,260 -to compromise between these two things. And, finally, I would - -46 -00:02:19,260 --> 00:02:23,000 -like to point out this term constituencies, which indicates - -47 -00:02:23,000 --> 00:02:26,220 -that we need to identify all of the stakeholders, not - -48 -00:02:26,220 --> 00:02:29,130 -just the customer and the users, so anybody who is - -49 -00:02:29,130 --> 00:02:32,040 -affected by a software system. It is very important to - -50 -00:02:32,040 --> 00:02:35,130 -consider all of these actors. Otherwise, again, - -51 -00:02:35,130 --> 00:02:37,530 -we'll be missing requirements, we'll be missing - -52 -00:02:37,530 --> 00:02:41,120 -part of the purpose of the system and we will build a suboptimal system. |