diff options
Diffstat (limited to 'usth/ICT2.7/P2L1 Requirements Engineering Subtitles/28 - Analyzing Requirements - lang_en_vs4.srt')
| -rw-r--r-- | usth/ICT2.7/P2L1 Requirements Engineering Subtitles/28 - Analyzing Requirements - lang_en_vs4.srt | 155 |
1 files changed, 0 insertions, 155 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 deleted file mode 100644 index c7d4899..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/28 - Analyzing Requirements - lang_en_vs4.srt +++ /dev/null @@ -1,155 +0,0 @@ -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. |