diff options
Diffstat (limited to 'usth/ICT2.7/P1L2 Life Cycle Models Subtitles/3 - Requirements Engineering - lang_en_vs4.srt')
| -rw-r--r-- | usth/ICT2.7/P1L2 Life Cycle Models Subtitles/3 - Requirements Engineering - lang_en_vs4.srt | 175 |
1 files changed, 0 insertions, 175 deletions
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 deleted file mode 100644 index c541e70..0000000 --- a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/3 - Requirements Engineering - lang_en_vs4.srt +++ /dev/null @@ -1,175 +0,0 @@ -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. |