But how can we do that? How can we identify the purpose
of the system and collect good requirements? To answer that question, let me
give you another definition of requirements
engineering. And this one is a classical
one, one that summarizes what we discussed so far, and then we can
use as some sort of reference. And it is a little long.
Definitely longer than the one that we saw at the beginning. But it's
an important one and it contains a lot of very relevant points. So,
we're going to go through it and highlight these points. So the definition says,
that the requirements engineering is a set of activities concerned
with identifying and communicating the purpose of a software intensive
system and the context in which it will be used.
And this is exactly what we said at the beginning. But
something we can highlight in here, is the fact that
we're talking about a set of activities. So, what that means
is that requirements engineering is not just a phase or
a stage. It also says that it's about identifying and communicating.
And what that is telling us is that communication is
as important as the analysis. So, it's important to be
able to communicate these requirements not only to collect them.
And we will discuss many reasons why that is the
case. It explicitly talks about purpose. So that allows me
to stress, once more, that quality means fitness-for-purpose. We cannot
say anything about quality unless we understand the purpose. And
the last thing I want to point out in this first
part of the definition is the use of the term
context. This is also something else that we mentioned at
the beginning, that designers, analysts, need to know how and
where the system will be used. Without this information, you
cannot really understand what the system should do and you
cannot really build the system. So now, let's continue and
read the second part of the definition that says, hence.
Requirements engineering acts as the bridge between the real-world needs of
users, customers, and other constituencies affected by a
software system and the capabilities and opportunities afforded
by software-intensive technologies. This is a long sentence,
but also here, we can point out a
few interesting and relevant points. Let me start
by highlighting two parts. Real-world needs, and the
capabilities, and opportunities. So, what are these two
parts telling us? They are telling us that requirements
are partly about what is needed, the real-world needs
of all these stakeholders. But they're also partly about what
is possible, what we can actually build. We need
to compromise between these two things. And, finally, I would
like to point out this term constituencies, which indicates
that we need to identify all of the stakeholders, not
just the customer and the users, so anybody who is
affected by a software system. It is very important to
consider all of these actors. Otherwise, again,
we'll be missing requirements, we'll be missing
part of the purpose of the system and we will build a suboptimal system.