1 files changed, 0 insertions, 83 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
deleted file mode 100644
index 7497280..0000000
--- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/14 - Best Practices - lang_en_vs5.srt
+++ /dev/null
@@ -1,83 +0,0 @@
-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.