The following guidelines have been found to be useful when producing quality requirements:
A quality requirement should be specified in terms of the components of a standardized quality model:
Although quality requirements are often termed “non-funtional” requirements to differentiate
them from the functional requirements, this is actually a
misnomer because the non-functional requirements include data
requirements, external API requirements, and constraints as well as the quality requirements.
Quality requirements are often characterized by adjectives, whereas functional requirements are often
characterized by verbs.
Quality requirements often have major impacts on architectures, effort, costs, and schedules.
In practice, requirements teams typically concentrate on functional requirements
and therefore spend too little time on quality requirements.
Whereas requirements engineers (and architects) often understandt the critical nature of quality requirements, they
often are not adquately trained in how to properly analyze and specify them.
Many quality requirements are difficult to quantify and
are too often documented as goals rather than validatable requirements.
Most quality requirements are really system-level requirements rather than software requirements because they
can only be achieved via the collaboration of data, hardware, software, and (potentially) personnel components.
A quality requirement may be specified indirectly in the
standard constraints section of the system requirements
specification if the standard specifies quality requirements.
