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