1 files changed, 155 insertions, 0 deletions
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/28 - Analyzing Requirements - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/28 - Analyzing Requirements - lang_en_vs4.srt
new file mode 100644
index 0000000..c7d4899
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/28 - Analyzing Requirements - lang_en_vs4.srt
@@ -0,0 +1,155 @@
+1
+00:00:00,250 --> 00:00:01,940
+Now we are at the point in which we
+
+2
+00:00:01,940 --> 00:00:05,590
+have collected and modeled our requirements. So the next thing
+
+3
+00:00:05,590 --> 00:00:08,310
+that we can do is to analyze the requirements to
+
+4
+00:00:08,310 --> 00:00:11,720
+identify possible problems, and specifically there are three types of
+
+5
+00:00:11,720 --> 00:00:14,646
+analysis that we can perform. The first type of analysis
+
+6
+00:00:14,646 --> 00:00:16,820
+is verification. So in this case we're talking about the
+
+7
+00:00:16,820 --> 00:00:19,700
+requirements verification. And in verification
+
+8
+00:00:19,700 --> 00:00:21,990
+developers will study the requirements
+
+9
+00:00:21,990 --> 00:00:25,270
+to check whether they're correct, whether they accurately reflect the
+
+10
+00:00:25,270 --> 00:00:28,710
+customer needs as perceived by the developer. Developers can
+
+11
+00:00:28,710 --> 00:00:32,170
+also check the completeness of the requirements, check whether there
+
+12
+00:00:32,170 --> 00:00:34,510
+are any missing pieces in the requirements as we
+
+13
+00:00:34,510 --> 00:00:37,710
+discussed earlier. They can check whether the requirements are pertinent,
+
+14
+00:00:37,710 --> 00:00:41,260
+or contain irrelevant information, like the one shown here.
+
+15
+00:00:41,260 --> 00:00:44,670
+And they can also check whether they're consistent, unambiguous, testable
+
+16
+00:00:44,670 --> 00:00:46,920
+and so on, so all those properties that should
+
+17
+00:00:46,920 --> 00:00:50,380
+be satisfied for the requirements. A second type of analysis
+
+18
+00:00:50,380 --> 00:00:53,670
+that is typically performed on requirements is validation. And
+
+19
+00:00:53,670 --> 00:00:56,290
+the goal of validation is to assess whether the collected
+
+20
+00:00:56,290 --> 00:00:59,870
+requirements define the system that the stakeholders really want.
+
+21
+00:00:59,870 --> 00:01:02,330
+So the focus here is on the stakeholders. And in
+
+22
+00:01:02,330 --> 00:01:05,670
+some cases, stakeholders can check the requirements directly if
+
+23
+00:01:05,670 --> 00:01:08,910
+the requirements are expressed in a notation that they understand.
+
+24
+00:01:08,910 --> 00:01:11,120
+Or they might check them by discussing them with the
+
+25
+00:01:11,120 --> 00:01:15,490
+developers. Another possibility is that stakeholders asses the requirements by
+
+26
+00:01:15,490 --> 00:01:18,400
+interacting with a prototype of the system, in case
+
+27
+00:01:18,400 --> 00:01:21,690
+the requirements engineering process that is being used involves
+
+28
+00:01:21,690 --> 00:01:25,300
+early prototyping. And finally surveys, testing, and other techniques
+
+29
+00:01:25,300 --> 00:01:28,400
+can also be used to validate requirements. A final type
+
+30
+00:01:28,400 --> 00:01:30,780
+of analysis that we can perform on requirements is
+
+31
+00:01:30,780 --> 00:01:34,430
+risk analysis. And risk analysis aims to identify and
+
+32
+00:01:34,430 --> 00:01:37,680
+analyze the main risks involved with the development of
+
+33
+00:01:37,680 --> 00:01:40,560
+the system being considered. And if some requirements are deemed
+
+34
+00:01:40,560 --> 00:01:43,320
+to be too risky, like in this case, this might result in
+
+35
+00:01:43,320 --> 00:01:47,880
+changes in the requirements model to eliminate or address those risks. And note
+
+36
+00:01:47,880 --> 00:01:49,950
+that all these analysis activities can
+
+37
+00:01:49,950 --> 00:01:52,390
+be performed in many different ways depending
+
+38
+00:01:52,390 --> 00:01:53,990
+on the modeling languages chosen to
+
+39
+00:01:53,990 --> 00:01:56,150
+represent the requirements and on the context.