There are various requirements that belong to the group “non-functional
requirements”. My team keeps talking about “IT requirements”, e.g.,
browser support. I’m trying to figure out if this is a commonly used
term, and how best to elicit these kinds of requirements?
———————————————————————————
The Functional requirements scope the project, while the Performance- or
Quality- requirements are the real reason for running the project.
Furthermore, the Constraints, defining limits in our options, are the
most restrictive requirements. They go above the other requirements..
Because the Performance- or Quality- requirements are the real reason
for running the project, calling them by what they are not
(“non-functional”) is a strange habit.
The Functional requirements scope the project, because they define which
set of functions we are going to improve in this project, because
improving this set of functions is apparently more rewarding than to
improve an other set.
After all, the Goal of a project is to deliver to the customer:
– What he needs (which usually is different from what he asks)
– At the time he needs it (which may be earlier or later than he asks)
– To be satisfied (then he wants to pay)
– And more successful than without the result of our project (if he’s
not successful, he cannot pay. If he’s not more successful than before,
why would he pay).
Examples of Performance- or Quality- requirements for IT projects are
(see also ISO9126/QUINT):
Functionality: suitability, accuracy, interoperability, compliance,
security, traceability
Reliability: maturity, fault tolerance, recoverability, availability,
degradability
Usability: understandability, learnability, operability, explicitness,
customizability, attractivity, clarity, helpfulness, user-friendliness
Efficiency: time behavior (real time behavior, response time), resource
behavior
Maintainability: analyzability, changeability, stability, testability,
manageability, reusability
Portability: adaptability, installability, conformance, replaceability
safety, size, etc: there may be many more -ilities.
Rule: “All quality requirements shall be quantified”. That is defined by
a scale (the dimension of the requirements, e.g. degree Celsius) and a
meter (how to measure it, e.g. mercury thermometer) and points on the
scale.
If a requirement cannot be quantified (like user-friendliness), it shall
be decomposed into quantifiable elements. Like “time to learn to
accomplish a defined operation” or “response-time”, or “max number of
clicks”.
Even if you don’t succeed in quantifying all the quality requirements,
the effort to do so will enhance your understanding of the consequences
of such a requirement. By the way, if you cannot quantify and cannot
measure, you wouldn’t know whether you achieved the required quality
level or not. You wouldn’t know when you’d be ready.
Niels Malotaux, Project Coach
World - As I see it 