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.