Page 104 -

4.1 Functional and non-functional requirements 87

definitions. In practice, for large, complex systems, it is practically impossible to
achieve requirements consistency and completeness. One reason for this is that it is easy
to make mistakes and omissions when writing specifications for complex systems.
Another reason is that there are many stakeholders in a large system. A stakeholder is a
person or role that is affected by the system in some way. Stakeholders have different—
and often inconsistent—needs. These inconsistencies may not be obvious when the
requirements are first specified, so inconsistent requirements are included in the specifi-
cation. The problems may only emerge after deeper analysis or after the system has
been delivered to the customer.

4.1.2 Non-functional requirements

Non-functional requirements, as the name suggests, are requirements that are not
directly concerned with the specific services delivered by the system to its users.
They may relate to emergent system properties such as reliability, response time, and
store occupancy. Alternatively, they may define constraints on the system implemen-
tation such as the capabilities of I/O devices or the data representations used in inter-
faces with other systems.
Non-functional requirements, such as performance, security, or availability, usually
specify or constrain characteristics of the system as a whole. Non-functional require-
ments 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 an embedded control system fails to meet
its performance requirements, the control functions will not operate correctly.
Although it is often possible to identify which system components implement
specific functional requirements (e.g., there may be formatting components that
implement reporting requirements), it is often more difficult to relate components to
non-functional requirements. The implementation of these requirements may be dif-
fused throughout the system. There are two reasons for this:

1. Non-functional requirements may affect the overall architecture of a system
rather than the individual components. For example, to ensure that performance
requirements are met, you may have to organize the system to minimize com-
munications between components.
2. A single non-functional requirement, such as a security requirement, may generate
a number of related functional requirements that define new system services that
are required. In addition, it may also generate requirements that restrict existing
requirements.

Non-functional requirements arise through user needs, because of budget con-
straints, organizational policies, the need for interoperability with other software or