NON-FUNCTIONAL REQUIRMENTS

In requirements engineering, a non-functional requirement is a requirement that specifies the

standards that can be used to judge a system’s operation, rather than specific behaviors.
Basically, non-functional requirements define how a system is supposed to be as opposed to what
it is supposed to do. They are generally informally stated, often contradictory, and difficult to
enforce during development and evaluate for the customer prior to delivery. They are usually
specified or constrained by the characteristic behavior of the required software, system
requirements derived from policies and procedures in the customer’s and developer’s
organization, or from external sources––which includes all requirements that are derived from
factors external to the system and its development process.
Non-functional requirements define system properties and constraints (for example reliability,
response time and storage requirements), and requirements instructing a specific IDE,
programming language or development method may be detailed. They may be more critical than
functional requirements in the sense that if non-functional requirements are not met, the system
may be rendered practically useless.
Non-functional requirements drive the technical architecture of a system, which means that they
tend to affect the whole architecture of a system, as opposed to only the separate specific
components. For instance, to ensure that optimum performance requirements are met, the
system might need to be arranged in such a way that communications amid components are
lessened, eliminating unnecessary communications. A single non-functional requirement may
spawn several related functional requirements that define the required system services, and may
also generate requirements that restrict existing requirements.
In order to specify efficient non-functional requirements, there are a few merits that must be
considered. These include the system's availability or "uptime" (the amount of time that it is
operational and available for use), efficiency (specifies how well the software utilizes scarce
resources), flexibility (enables the organization to extend the functionality of the software after
it is deployed), portability (specifies the ease with which the software can be installed on all
necessary platforms, and the platforms on which it is expected to run), integrity (defines the
security attributes of the system, restricting access to features or data to certain users and
protecting the privacy of data entered into the software), performance (specifies the timing
characteristics of the software), reliability (specifies the capability of the software to maintain its
performance over time), reusability (indicates the extent to which software components should
be designed in such a way that they can be used in applications other than the ones for which
they were initially developed), robustness (enables the system to handle error conditions
gracefully, without failure).
EXAMPLE
The extent to which the system is safeguarded against deliberate and intrusive faults from internal and
external sources. Examples a. Employees shall be forced to change their password the next time they log
in if they have not changed it within the length of time established as “password expiration duration.” b.
Users must change the initially assigned login authentication information (password) immediately after the
first successful login. The initial password may never be reused. c. The payroll system shall ensure that the
employee salary data can be accessed only by authorized users. The payroll system shall distinguish
between authorized and non‐authorized users. d. Employees shall not be allowed to update their own salary
information, and any such attempt shall be reported to the security administrator.
NON-FUNCTIONAL CLASSIFIACTION
PRODUCT REQUIRMENT

Requirements must specify the delivered product must behave in a particular way .

ORGANIZATIONAL REQUIRMENT

Requirements which are the consequence of organizational polices and procedure.

EXTRENAL REQUIRMENTS

Requirements which arise from the factors which are external to the system.

EXAMPALS

Accuracy
Every phone call initiated by the auto-dialer must have all the digits exactly correct, including area code.
Computed grades must be accurate to .01% (NM - compared to what?)
The system will notify the system administrator if the input data source is corrupted.
Every video must have an unique identification.
The displayed clock rate must be within 5 Hz of the actual clock rate.
If the mail list is used for a mailing, < 10% of the letters will be returned as undeliverable.
Adaptability
The finished software must support new employee types without needing to be rewritten or recompiled.
The software must be flexible.
The software must be adaptable.
The Mean Time to Change (MTTC) data presentation (no new data entities) will be < 1 person-month for
a senior system developer.
Compatibility
All web client programs must interact with the server without any changes to the server code.
The system must be compatibility with MacIntosh OS 10.
Avilibality
The degree to which users can depend on the system to be up (able to function) during “normal operating
times”.
The Online Payment System shall be available for use between the hours of 6:00 a.m. and 11:00 p.m.
CST.
The Online Payment System shall achieve 100 hours MTBF (mean time between failure).
The CIF system shall achieve 99.5% up time