-So, let's start with requirements engineering, which is the - -2
-field within software engineering that deals with establishing the - -3
-needs of stakeholders that are to be solved by - -4
-the software. So why is this phase so important? - -5
-In general, the cost of correcting an error depends - -6
-on the number of subsequent decisions that are based - -7
-on it. Therefore, errors made in understanding requirements have - -8
-the potential for greatest cost because many other design decisions - -9
-depend on them and many other follow up decisions depend on them. - -10
-In fact, if we look at this diagram, which is again a - -11
-qualitative diagram, where we have the cost of error correction over the - -12
-phase in which the error is discovered. We can see that if we - -13
-discover an error in requirements it's going to cost us one. If - -14
-we find it in in design it's going to cost us five and - -15
-so on and so forth. And the cost grows dramatically as we - -16
-go from the requirements phase to the maintenance phase. Why? Because of course - -17
-if we discover a problem here we're left to undo a - -18
-lot of the decision that we had made before to correct the - -19
-error. Whereas if we find an error here we can correct it - -20
-right away and we don't affect the subsequent phases. So how can - -21
-we collect the right requirements. Traditional - -22
-requirements in engineering does so through - -23
-a set of steps. The first step is elicitation which is the - -24
-collection of requirements from stake holders and other sources and can be - -25
-done in a variety of ways, we will discuss some of them. - -26
-The second is requirement analysis which involved the study and - -27
-deeper understanding of the collective requirements. The third step is this - -28
-specification of requirements, in which the collective requirements are suitably - -29
-represented, organized and save so that they can be shared. Also - -30
-in his case, there are many ways to do this, - -31
-and we will see some of this ways when we talk - -32
-about the requirements engineering in the dedicated lesson. Once the - -33
-requirements have been specified, they can be validated to make sure - -34
-that they're complete, consistent, no redundant and so on. So - -35
-that they've satisfied a set of importance properties, for requirements. - -36
-Finally, the fifth step is requirements management which accounts for - -37
-changes to requirements during the lifetime of the project. And here - -38
-I talked about steps, kind of giving the impression that - -39
-we're just going from the first step to the fifth one - -40
-and that this is sort of a linear process. In - -41
-reality, as we will see, this is more of an iterative - -42
-process in which will go and cover the different phases in an - -43
-iterative fashion. We will discuss extensively - -44
-requirements engineering in our second mini-course. -- cgit 1.4.1