From b2d80610db6beda38573890ed169815e495bc663 Mon Sep 17 00:00:00 2001
From: Nguyễn Gia Phong <mcsinyx@disroot.org>
Date: Sun, 24 May 2020 16:34:31 +0700
Subject: [usth/ICT2.7] Engineer software

---
 .../3 - Requirements Engineering - lang_en_vs4.srt | 175 +++++++++++++++++++++
 1 file changed, 175 insertions(+)
 create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/3 - Requirements Engineering - lang_en_vs4.srt

(limited to 'usth/ICT2.7/P1L2 Life Cycle Models Subtitles/3 - Requirements Engineering - lang_en_vs4.srt')

diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/3 - Requirements Engineering - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/3 - Requirements Engineering - lang_en_vs4.srt
new file mode 100644
index 0000000..c541e70
--- /dev/null
+++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/3 - Requirements Engineering - lang_en_vs4.srt	
@@ -0,0 +1,175 @@
+1
+00:00:00,230 --> 00:00:03,200
+So, let's start with requirements engineering, which is the
+
+2
+00:00:03,200 --> 00:00:06,560
+field within software engineering that deals with establishing the
+
+3
+00:00:06,560 --> 00:00:09,400
+needs of stakeholders that are to be solved by
+
+4
+00:00:09,400 --> 00:00:13,480
+the software. So why is this phase so important?
+
+5
+00:00:13,480 --> 00:00:16,350
+In general, the cost of correcting an error depends
+
+6
+00:00:16,350 --> 00:00:19,060
+on the number of subsequent decisions that are based
+
+7
+00:00:19,060 --> 00:00:22,160
+on it. Therefore, errors made in understanding requirements have
+
+8
+00:00:22,160 --> 00:00:25,670
+the potential for greatest cost because many other design decisions
+
+9
+00:00:25,670 --> 00:00:29,020
+depend on them and many other follow up decisions depend on them.
+
+10
+00:00:29,020 --> 00:00:31,510
+In fact, if we look at this diagram, which is again a
+
+11
+00:00:31,510 --> 00:00:35,210
+qualitative diagram, where we have the cost of error correction over the
+
+12
+00:00:35,210 --> 00:00:38,780
+phase in which the error is discovered. We can see that if we
+
+13
+00:00:38,780 --> 00:00:42,420
+discover an error in requirements it's going to cost us one. If
+
+14
+00:00:42,420 --> 00:00:45,020
+we find it in in design it's going to cost us five and
+
+15
+00:00:45,020 --> 00:00:47,410
+so on and so forth. And the cost grows dramatically as we
+
+16
+00:00:47,410 --> 00:00:50,960
+go from the requirements phase to the maintenance phase. Why? Because of course
+
+17
+00:00:50,960 --> 00:00:53,092
+if we discover a problem here we're left to undo a
+
+18
+00:00:53,092 --> 00:00:55,536
+lot of the decision that we had made before to correct the
+
+19
+00:00:55,536 --> 00:00:58,019
+error. Whereas if we find an error here we can correct it
+
+20
+00:00:58,019 --> 00:01:01,380
+right away and we don't affect the subsequent phases. So how can
+
+21
+00:01:01,380 --> 00:01:03,540
+we collect the right requirements. Traditional
+
+22
+00:01:03,540 --> 00:01:05,310
+requirements in engineering does so through
+
+23
+00:01:05,310 --> 00:01:08,930
+a set of steps. The first step is elicitation which is the
+
+24
+00:01:08,930 --> 00:01:12,840
+collection of requirements from stake holders and other sources and can be
+
+25
+00:01:12,840 --> 00:01:15,890
+done in a variety of ways, we will discuss some of them.
+
+26
+00:01:15,890 --> 00:01:19,280
+The second is requirement analysis which involved the study and
+
+27
+00:01:19,280 --> 00:01:23,200
+deeper understanding of the collective requirements. The third step is this
+
+28
+00:01:23,200 --> 00:01:26,760
+specification of requirements, in which the collective requirements are suitably
+
+29
+00:01:26,760 --> 00:01:30,730
+represented, organized and save so that they can be shared. Also
+
+30
+00:01:30,730 --> 00:01:32,530
+in his case, there are many ways to do this,
+
+31
+00:01:32,530 --> 00:01:34,350
+and we will see some of this ways when we talk
+
+32
+00:01:34,350 --> 00:01:37,550
+about the requirements engineering in the dedicated lesson. Once the
+
+33
+00:01:37,550 --> 00:01:40,970
+requirements have been specified, they can be validated to make sure
+
+34
+00:01:40,970 --> 00:01:44,420
+that they're complete, consistent, no redundant and so on. So
+
+35
+00:01:44,420 --> 00:01:48,460
+that they've satisfied a set of importance properties, for requirements.
+
+36
+00:01:48,460 --> 00:01:52,410
+Finally, the fifth step is requirements management which accounts for
+
+37
+00:01:52,410 --> 00:01:56,100
+changes to requirements during the lifetime of the project. And here
+
+38
+00:01:56,100 --> 00:01:58,330
+I talked about steps, kind of giving the impression that
+
+39
+00:01:58,330 --> 00:02:01,310
+we're just going from the first step to the fifth one
+
+40
+00:02:01,310 --> 00:02:03,300
+and that this is sort of a linear process. In
+
+41
+00:02:03,300 --> 00:02:05,990
+reality, as we will see, this is more of an iterative
+
+42
+00:02:05,990 --> 00:02:09,690
+process in which will go and cover the different phases in an
+
+43
+00:02:09,690 --> 00:02:12,560
+iterative fashion. We will discuss extensively
+
+44
+00:02:12,560 --> 00:02:15,453
+requirements engineering in our second mini-course.
-- 
cgit 1.4.1