Zum Inhalt springen
L

Das Video kommt von YouTube: erst beim Abspielen verbindet sich die Seite mit YouTube (Google).

Requirements Engineering - Georgia Tech - Software Development Process

Udacity2:16 35.016 Aufrufe veröffentlicht Auf YouTube

Das Wichtigste aus dem Video

Tipp auf eine Zeit – das Video springt genau dorthin.

Transkriptautomatisch erstellt · 22 Zeilen
Herunterladen
  1. So, let's start with requirements engineering, which is the field within software engineering that deals with establishing the
  2. needs of stakeholders that are to be solved by the software. So why is this phase so important?
  3. In general, the cost of correcting an error depends on the number of subsequent decisions that are based
  4. on it. Therefore, errors made in understanding requirements have the potential for greatest cost because many other design decisions
  5. depend on them and many other follow up decisions depend on them. In fact, if we look at this diagram, which is again a
  6. 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
  7. 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
  8. 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
  9. if we discover a problem here we're left to undo a lot of the decision that we had made before to correct the
  10. 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
  11. we collect the right requirements. Traditional requirements in engineering does so through
  12. a set of steps. The first step is elicitation which is the collection of requirements from stake holders and other sources and can be
  13. done in a variety of ways, we will discuss some of them. The second is requirement analysis which involved the study and
  14. deeper understanding of the collective requirements. The third step is this specification of requirements, in which the collective requirements are suitably
  15. represented, organized and save so that they can be shared. Also in his case, there are many ways to do this,
  16. and we will see some of this ways when we talk about the requirements engineering in the dedicated lesson. Once the
  17. requirements have been specified, they can be validated to make sure that they're complete, consistent, no redundant and so on. So
  18. that they've satisfied a set of importance properties, for requirements. Finally, the fifth step is requirements management which accounts for
  19. changes to requirements during the lifetime of the project. And here I talked about steps, kind of giving the impression that
  20. we're just going from the first step to the fifth one and that this is sort of a linear process. In
  21. reality, as we will see, this is more of an iterative process in which will go and cover the different phases in an
  22. iterative fashion. We will discuss extensively requirements engineering in our second mini-course.

Zum Nachlesen