Among the requirement that we can collect from the application
domain, we need to distinguish between two main types. And you've
probably heard about these ones.
Functional requirments and non-functional requiremnts. Functional
requiremetns have to do with the functionality of the system, with
what the system does with the computation. For example the elevator
shall take people to the floor they select. That's a functional
requirement, that has to do with the functionality of the system.
Or for a very simple one, the system has to output
the square root of the number past as
an input. So these kind of requirements have in
general well defined satisfaction criteria. So, for example, if
for the latter one that we mentioned it is
pretty clear how to check whether the output
is actually the square root of the number passed
in input. Non-functional requirements, conversely, refer to a system's
non-functional properties, systems qualities.
Such as security, accuracy, performance,
cost. Or, you know, usability,
adaptability, interoperability, reusability and so
on. So, all these qualities the don't necessarily have to
do with the functionality. And, unlike functional requirements, non functional
requirements Do not always have clear satisfaction criteria. For example,
if we say that the elevator must be fast, that's
a non-functional requrement. Right? It has to do with the
speed of the elevator, which is a quality of the
elevator. But, it, it's not clear how such a requirement
could be satisfied. How could we tell whether the elevator
is fast or not. So, what we need to do
in these cases Is that we need to refine these
requirements so that they become verifiable. For the example that
I just mentioned, for instance, we might say that the
elevator must reach the requested floor in less than 30
seconds from the moment when the floor button is pushed.
This is still a non-functional requirment, but is a verifiable one.