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