Chapter 1

Non-functional Requirements

By Esubalew A.
 Contents
Introduction
Classification of NFPs
 Boehm[1977]
 McCall[1977]
 Evans and Marciniak (1987)
 Deutsch & Willis [1988]
 Sommerville [2007]

Some NFRs
Deriving NFRs
 Stakeholder Concerns
 Goal-based derivation

Testable NFRs
 Introduction
Non-functional requirements (NFR) define the overall
qualities of the resulting system;
 They are global constraints on a software system , on the
development process or external constrains outside the
enterprise
Importance
All functional requirements may be satisfied, but if
nonfunctional requirements are overlooked, the system will
fail.
Non-functional properties may be the difference between an
accepted, well-liked product & unused one.
Though all NFRs are important their relative importance
differs from stakeholder to stakeholder and from system to
system.
Reliability, Performance, Security, Usability, Safety NFRs are
more important than others for critical systems
Non-functional requirements like Usability, efficiency, accuracy,
… are more important for end users then other stakeholders
 Introduction…
The challenge of NFRs
 Hard to model
Usually stated informally, and so are:
often contradictory,
difficult to enforce during development
difficult to evaluate for the customer prior to
delivery
Hard to make them measurable requirements
We’d like to state them in a way that we can
measure how well they’ve been met
Different people and organizations use
different terminologies and different definition
(though basically the definitions have the
same meaning)
NFR-Definitions
Classification of NFRS
 Classification of NFRS..
The ‘IEEE-Std 830 - 1993’ lists 13 non-
functional requirements to be included in a
Software Requirements Document.
Performance requirements
Security
Interface requirements requirements
Operational requirements
Portability
Resource requirements requirements
Quality
Verification requirements
Acceptance requirements requirements
Reliability
Documentation requirements
requirements
Maintainability
 Classification of NFRs…
Different ways classifying NFRs have been
proposed
NFRs may be classified in terms of qualities that a
software must exhibit (Boehm)
 Classification of NFRs…
McCall factor model is user centred classification

McCall [1977]
 Classification of NFRs…
McCall factor model is derived from user
concerns
 Classification of NFRs…
Evans and Marciniak (1987) – defined 12 factors
 Correctness, Reliability, Integrity, Usability, Efficiency,
Maintainability, Flexibility, Portability, Reusability,
Expandability, Interoperability, Verifiability
Deutsch & Willis(1988) factor model consists of 15
factors that are classified into four categories

 Functional- Reliability, Integrity, Usability, Survivability

 Performance - Correctness, Efficiency, Interoperability,
Safety
 Change - Maintainability, Flexibility, Portability,
Reusability, Expandability
 Management - Verifiability, Manageability
 Classification of NFRs…
A more general classification distinguishes between
product, process and external requirements is
recently proposed by Non-functional
Sommerville [2007]
requirements

Process Product requirements External

requirements requirements
Usability requirements
Delivery Legal
requirements Reliability requirements constraints
implementation Safety requirements Economic
requirements constraints
standards Efficiency requirements
Interoperability
requirements requirements
Performance requirements
Capacity requirements
 Product requirements
Specify the desired characteristics that a system or
subsystem must possess.
Most NFRs are concerned with specifying constraints on
the behaviour of the executing system.
Some product requirements can be formulated precisely,
and thus easily quantified: e.g. Performance, Capacity
Others are more difficult to quantify and, consequently,
are often stated informally: e.g. Usability
 Examples
 The System service X shall have an availability of 999/1000 or
99%.
 System Y shall process a minimum of 8 transactions per second.
 The executable code of System Z shall be limited to 512Kbytes.
 Conflicts in product requirements
 The system shall be developed for PC and Macintosh
platforms.
 The system must encrypt all external communications using
the RSA algorithm.
Product requirements often conflict.
 For example, a requirement for a certain level of
performance may be contradicted by reliability and
security requirements which use processor capacity to
carry out dynamic system checking
The process of arriving at a trade-off in these
conflicts depends on:
 The level of importance attached to the requirement
 The consequence of the change on the other requirements
 The wider business goals
 Process requirements
Process requirements are constraints placed upon the
development process of the system
Process requirements include:
 Requirements on development standards and methods
which must be followed
 CASE tools which should be used
 The management reports which must be provided
Examples
The development process to be used must be explicitly
defined and must be conformant with ISO 9000 standards
The system must be developed using the XYZ suite of
CASE tools
Management reports setting out the effort expended on
each identified system component must be produced every
two weeks
A disaster recovery plan for the system development must
be specified
 External requirements
These types of requirements may be placed on both
the product and the process and they are derived
from the environment in which the system is
developed
External requirements are based on:
 application domain information
 organisational considerations
 the need for the system to work with other systems
 health and safety or data protection regulations
 or even basic natural laws such as the laws of physics
Examples
 Medical data system - The organisation’s data protection
officer must certify that all data is maintained according
to data protection legislation before the system is put
into operation
 Some NFRs
Access Security
Definition - The extent to which the system is safeguarded
against deliberate and intrusive faults from internal and
external sources.
Example - 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.”
Availability
Definition - the degree to which users can depend on the
system to be up (able to function) during “normal operating
times.”
Example - The Automated Teller Machine shall be at least
99.5 percent available on weekdays between 6:00 a.m. and
midnight local time. The machine shall be at least 99.95
percent available on weekdays between 3:00 p.m. and 7:00
p.m. local time.
 Some NFRs…
Efficiency
Definition - the extent to which the software system
handles capacity, throughput, and response time.
Example - The system must download the new rate
parameters within ten minutes of a non-scheduled rate
change.
Integrity
Definition - the degree to which the data maintained
by the software system is accurate, authentic, and
without corruption.
Example - The integrity of the system data area must
be checked by the internal audit system twice per
second; if inconsistencies in the data are detected, the
system operation should be disabled.
 Some NFRs…
Reliability
Definition - the extent to which the software system
consistently performs the specified functions without
failure.
Example - No more than 10 claim assignments out of
5000 can be “unassigned” because of system failures.
Survivability
Definition - the extent to which the software system
continues to function and recovers in the presence of a
system failure.
Example - All policy statement parameters shall have
default values specified, which the Report Writer
system shall use if a parameter’s input data is missing
or invalid.
 Some NFRs…
Usability
Definition - the ease in which the user is able to
learn, operate, prepare inputs and interpret outputs
through interaction with a system.
Example - A trained order-entry clerk shall be able to
submit a complete order for a product chosen from a
supplier catalog in a maximum of 7 minutes, and an
average order entry time of 4 minutes.
Flexibility
Definition — the ease in which the software can be
modified to adapt to different environments.
Example - It shall be possible to add a new delivery
option for customer mailing method by developing and
“plugging in” the functionality necessary to support
that delivery option.
 Some NFRs…
Maintainability
Definition — the ease in finding and fixing faults
in the software system.
Example - The application development process
must have a regression test procedure that allows
complete re-testing within 2 business days.
Scalability
Definition — the degree in which the software
system is able to expand its processing
capabilities upward and outward to support
business growth.
Example - Any increase in the number of
customers shall not degrade system availability to
an extent noticeable by any users.
 Some NFRs…
Verifiability
Definition — the extent to which tests, analysis,
and demonstrations are needed to prove that the
software system will function as intended.
Example - The maximum number of test cases to
cover testing of any particular source code module
shall be 20.
Interoperability
Definition — the extent to which the software
system is able to couple or facilitate the interface
with other systems.
Example - The system must be able to interface
with any HTML (HyperText Markup Language)
browser.
 Some NFRs…
Portability
Definition — the ease in which a software system
from its current hardware or software environment
can be transferred to another environment.
Example - The system is designed to run in business
offices, but the intent is to have a version which will
run in manufacturing assembly plants.
Reusability
Definition — the extent to which a portion of the
software system can be converted for use in another.
Example - The payment subsystem design is based
on the payment module from the ALPHA product line.
The ePAYZ system should not be modified unless
absolutely necessary.
 Some NFRs…
Correctness
Definition - Deals with the extent to which the
software design and implementation conform to
the stated requirements
Example - The requirements can be e.g. time
limits, effort constraints, development techniques
to be used etc.
Safety
Definition - meant to eliminate conditions
hazardous to equipment as a result of errors in
process control software.
Example - The system shall not operate if the
external temperature is below 4 degrees Celsius
 Some NFRs…
Expandability
Definition - refer to future efforts that will be needed to
serve larger populations, improve services, or add new
applications in order to improve usability.
Example - The Automated Money Machine (AMM) System
shall be designed in such a manner as to allow for
future addition of 4 user buttons and 4 additional
banking services.
Manageability
Definition - refer to the administrator tools that support
software modification during the software development
and maintenance periods.
Example - the system must be self-configure with
respect to load and data distribution and self-heal with
respect to failure and recovery
 Deriving NFRs
Non-functional requirements are difficult to express
A number of important issues contribute to the problem of
expressing non-functional requirements:
Certain constraints are related to the design solution that is
unknown at the requirements stage (response time to failure)
Certain constraints, are highly subjective and can only be
determined through complex empirical evaluations
(associated with human beings)
Non-functional requirements tend to be related to one or more
functional requirements
Non-functional requirements tend to conflict and contradict
There are no ‘universal’ rules and guidelines for determining
when non-functional requirements are optimally met.
In spite of the fact, two different ways of driving NFRs are
discussed here: Stakeholder concerns & goal-based derivation
 Stakeholder concerns
Stakeholders normally have a number of ‘concerns’
 Concerns are typically non-functional
Vaguely defined user concerns may be related to
NFRs
What are Concerns?
A way of expressing critical ‘holistic’ requirements
which apply to the system as a whole rather than any
specific sub-set of its service or functionality.
Concerns may be broken down into sub-concerns and
finally into specific questions
Questions act as a check list to ensure that specific
requirements do not conflict with global priorities
The concerns may lead directly to system requirements
or to questions which must be answered during the
requirements engineering process.
 Stakeholder concerns…
Relationships between user needs, concerns
and NFRs

To illustrate this approach the following figure shows

the decomposition of safety & compatibility concerns
 Concern decomposition
Safety Compatibility

Personal Software Physical

Collision Derailment Hardware
accident

Execution Timing Interface

Excess speed
Track damage Environment
for track conditions

What information about Will a requirement affect

System must be able to
track damage is required by the performance of the
detect and avoid excess
the system? How is this existing software?
speed
provided?
Does a requirement need
System must execute in the trusted
Under what conditions data that isn't available
Ada execution environment
can excess speed cause through the HST interface?
derailment?

What does 'excess speed' mean in reality? Can this function be

provided on the existng
execution environment?
 Goal-based derivation
Relates non-functional requirements to the goals of
the enterprise
Goal-based NFR derivation is a 3 step approach:
Identify the enterprise goals
Decompose the goals into sub-goals
Identify non-functional requirements.
One advantage of this approach is that it provides a
means of tracing non-functional requirements to
originally stated , vague expressions in the
enterprise domain

The approach is illustrated using a requirement

drawn from the air traffic domain, on the next slide
Example of goal-based derivation
 Testable NFRs
Stakeholders may have vague goals which cannot be expressed
precisely - Vague and imprecise ‘requirements’ are problematic
NFRs should satisfy two attributes; must be objective (doesn’t
express a wish, a goal, or a personal opinion) and Must be
testable (Use measurable metrics)

Property Metric
Performance 1. Processed transactions per second
2. Response time to user input
Reliability 1. Rate of occurrence of failure
2. Mean time to failure
Availability Probability of failure on demand
Size Kbytes
Usability 1. Time taken to learn 80% of the facilities
It is not always possible to express
2. Number NFRs
of errors made by usersobjectively
in a given time
period
Robustness Time to restart after system failure
Portability Number of target systems