Non-functional requirements

Non-functional requirements, as the name suggests, are requirements that are not
directly concerned with the specific functions delivered by the system. They may
relate to emergent system properties such as reliability, response time and store occupancy.
Alternatively, they may defll1e constraints on the system such as the capabilities
of VO devices and the data representations used in system interfaces.
Non-functional requirements are rarely associated with individual system features.
Rather, these requirements specify or constrain the emergent properties of the system,
. Therefore, they may specify system performance
security, availability, and other emergent properties. This means that they are often
more critical than individual functional requirements. System users can usually find
ways to' work around a system function that doesn't really meet their needs.
However, failing to meet a non-functional requirement can mean that the whole system
is unusable. For example, if an aircraft system does not meet its reliability requirements,
it will not be certified as safe for operation; if a real-time control system
fails to meet its performance requirements, the control functions will not operate
correctly.
Non-functional requirements are not just concerned with the software system to
be developed. Some non-functional requirements may constrain the process that should
be used to develop the system. Examples of process requirements include a specification
of the quality standards that should be used in the process, a specification
that the design must be produced with a particular CASE toolset and a description
of the process that should be followed.
Non-functional requirements arise through user needs, because of budget constraints,
because of organisational policies, because of the need for interoperability
with other software or hardware systems, or because of external factors such as safety
regulations or privacy legislation. Figure 6.3 is a classification of non-functional
requirements. You can see from this diagram that the non-functional requirements
may come from required characteristics of the software (product requirements), the
organization developing the software (organizational requirements) or from external
sources.

Non Functional requirements

-Product requirements
-Usability requirements
-Efficiancy requirements
-Performance requirements
-Space requirements
-Reliablity requirements
-Portability requirements
-Organisational requirements
-Delivery requirements
-Implementation requirements
-Standards requirements
-External requirements
-Interportability requirements
-Standards requirements
-Legislative requirements
-Privacy requirements
-Safty requirements

The types of non-functional requirements are:
1. Product requirements These~ requirements specify product behaviour.
Examples include performance requirements on how fast the system must execute
and how much memory it requires; reliability requirements that set out the
acceptable failure rate; portability requirements; and usability requirements.
2. Organisational requirements These requirements are derived from policies and
procedures in the customer s and developer s organisation. Examples include
pro<;ess standards that must be used; implementation requirements such as the
programming language or design method usedl; and delivery requirements that
spedfy when the product and :Its documentation are to be delivered.
3. External requirements This broad heading covers all requirements that are derived
from factors external to the system and its development process. These may
include interoperability requirements that define how the system interacts with
systems in other organisations: legislative requirements that must be followed
to ensure that the system operates within the law; and ethical requirements. Ethical
requirements are requirements placed on a system to ensure that it will be acceptable
to its users and the general public.

A system goal
The system should be easy to use by experienced controllers and should be
organised in such a way that user errors are minimised.
Averifiable non-functional requirement
Experienced controllers shall be able to use all the system functions after a total of
two hours' training. After this training, the average number of errors made by
experienced users shall not exceed two per day.

A common problem with non-functional requirements is that they can be difficult
to verify. Users or customers often state these requirements as general goals
such as ease of use, the ability of the system to recover from failure or rapid user
response. These vague goals cause problems for system developers as they leave
scope for interpretation and subsequent dispute once the system is delivered. As an
illustration of this problem, consider Figure 6.5. This shows a system goal relating
to the usability of a traffic control system and is typical of how a user might express
usability requirements. I have rewritten it to show how the goal can be expressed
as a 'testable' non-functional requirement. While it is impossible to objectively verify
the system goal, you can design system tests to count the errors made by controllers
using a system simulator.
Whenever possible, you should write non-functional requirements quantitatively
so that they can be objectively tested. Figure 6.6 shows a number of possible metrics
that you can use to specify non-functional system properties. You can measure
these characteristics when the system is being tested to check whether or not the
system has met its non-functional requirements.
In practice, however, customers for a system may find it practically impossible
to translate their goals into quantitative requirements. For some goals, such as maintainability,
there are no metrics that can be used. In other cases, even when quantitative
specification is possible, customers may not be able to relate their needs to
these specifications. They don't understand what some number defining the
required reliability (say) means in terms of their everyday experience with computer
systems. Furthermore, the cost of objectively verifying quantitative nonfunctional
requirements may be very high, and the customers paying for the system
may not think these costs are justified.
Therefore, requirements documents often include statements of goals mixed with
requirements. These goals may be useful to developers because they give indications
of customer priorities. However, you should always tell customers that they
are open to misinterpretation and cannot be objectively verified.
Non-functional requirements often conflict and interact with other functional or
non-functional requirements. For example, it may be a requirement that the
maximum memory used by a system should be no more than 4 Mbytes. Memory
constraints are common for embedded systems where space or weight is limited
and the number ofROM chips storing the system software must be minimised. Another
requirement might be that the system should be written using Ada, a programming
language for critical, real-time software developmt:nt. However, it may not be possible
to compile an Ada program with the required functionality into less that 4 Mbytes.
There therefore has to be a trade-off between these l1::quirements: an alternative development
language or increased memory added to the system.
It is helpful if you can differentiate functional :and non-functional requirements
in the w..quirements document. In practice, this is difficult to do. If the non-functional
requirements are stated separately from the functional requirements, it is sometimes
dlfficult to see the relationships between them. If they are stated with the
functional requirements, you may find it difficult to separate functional and nonfunctional
considerations and to identify requirements that relate to the system as
a whole, However, you should explicitly highlight requirements that are clearly related
to emergent system properties, such as performanc;e or reliability. You can do this
by putting them in a separate sectlon of the requirements docUment or by distinguishing
them, in some way, from other system n:quirements.