Requirements Engineering - Georgia Tech - Software Development Process
Udacity
https://www.youtube.com/watch?v=miuUIfpaC40

Transkript (automatisch erstellt)

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