So at this point, we have talked quite a bit about
requirements engineering, but we haven't
really discussed what are requirements exactly.
So what is a requirement? To define that I am going
to use this diagram which is a classical one. So you might
have seen it before. So, discussing this diagram allows me to
point out a few interesting things about requirements and define them
in a better way. At a high level this diagram contains
two main parts, the domain of the machine, which is the hardware,
operating system, libraries and so on, on which the
software will run. And the domain of the application, which
is a world in which the software will operate.
And the machine domain is characterized by computers, which are
the hardware devices, and programs, which is the software
that runs on these devices. The application domain, conversely, is
characterized by domain properties, which are things that are true
of the world anyways, whether I'm building my system or
not, and requirements, which are things in the world we
would like to achieve by delivering the system that we are
building. Basically, to put it in a different way, the former,
the domain properties, represents the assumptions that we make on the
domain. And the latter, the requirements, are the actual requirements
that we aim to collect. So we have something here, right,
at the intersection of this application domain and this machine domain.
And what is that? And this is what we normally call
the specification, which is a description, often a formal description,
of what the system that we are building should do to
meet the requirements. So this is a bridge between these two
domains. And as the graphical depiction shows, the specification is written
in terms of shared phenomena. Things that are observable in both
the machine domain and the application domain. And just to make
things a little more concrete, I want to give you a
couple of examples of what these phenomena, these shared phenomena, are.
And we can think about two main kinds of phenomena.
The first one are events in the real world that the
machine can directly sense. For example, a button being pushed or
a sensor being activated. These are events that happen here, but
that the machine can detect. So they're events that can
be used to define the specification. And the second type of
phenomena are actions in the real world that the machine can
directly cause. For example, an image appearing on a screen or
a device being turned on and off. Again, this is something
that the machine can make happen and then can have manifestation in
the real world. And again this is therefore something on which
the specification can predicate, something that
we can describe in our specification.
And this is sort of a philosophical discussion, but even if
you don't care about the philosophical discussion, the one take away point
that I would like for you to get from this discussion is
the fact that when writing a specification you have to be aware
of the fact that you're talking about shared phenomena. Events in the real
world that the machine can sense and actions in the real world that the
machine can cause. So this is what the specification is about, a bridge between
these two worlds that define what the
system should do to satisfy the requirements.