Chapter 1…
Non-functional Requirements

 Introduction
 Classification of NFRs
 Boehm[1977]
 McCall[1977]
 Evans and Marciniak (1987)
 Deutsch & Willis [1988]
 Sommerville [2007]
 Some NFRs
 Deriving NFRs
 Stakeholder Concerns
 Goal-based derivation
 Testable NFRs
Contents

 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
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)
Introduction…

NFR-Definitions

Classification of NFRS

 The ‘IEEE-Std 830 - 1993’ lists 13 non-functional
requirements to be included in a Software Requirements
Document.
 Performance requirements
 Interface requirements
 Operational requirements
 Resource requirements
 Verification requirements
 Acceptance requirements
 Documentation requirements
Classification of NFRS..
 Security requirements
 Portability requirements
 Quality requirements
 Reliability requirements
 Maintainability
requirements
 Safety requirements

 Different ways classifying NFRs have been
proposed
 NFRs may be classified in terms of qualities that a
software must exhibit (Boehm)
Classification of NFRs…

Classification of NFRs…
McCall [1977]
McCall factor model is user centred classification

 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…

Non-functional
requirements
Organizational
requirements
Product requirements External
requirements
Delivery
requirements
implementation
requirements
standards
requirements
Usability requirements
Reliability requirements
Safety requirements
Efficiency requirements
Performance requirements
Capacity requirements
Legal
constraints
Economic
constraints
Interoperability
requirements
Classification of NFRs…
A more general classification distinguishes between product,
Organizational and external requirements is recently
proposed by Sommerville [2007]

Non-functional classifications
 Product requirements
 Requirements which specify that the delivered
product must behave in a particular way e.g.
execution speed, reliability, etc.
 Examples
 The system shall allow one hundred thousand hits per
minute on the website
 The system shall not have down time of more than one
second for continuous execution of one thousand hours

 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,Maintainability
 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.
Product requirements

…contd…
 Organisational requirements
 Requirements which are a consequence of
organisational policies and procedures e.g. process
standards used, implementation requirements, etc.
 Examples
 The system development process and deliverable
documents shall conform to the MIL-STD-2167A
 External requirements
 Requirements which arise from factors which are
external to the system and its development process
e.g. interoperability requirements, legislative
requirements, etc.
15

 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.
 The system shall comply with the local and national laws
regarding the use of software tools.
 The system shall not disclose any personal information
about members of the library system to other members
except system administrators

Examples of nonfunctional requirements
in the MHC-PMS
 Product requirement
 The MHC-PMS shall be available to all clinics
during normal working hours (Mon–Fri, 0830–
17.30). Downtime within normal working hours
shall not exceed five seconds in any one day.
 Organizational requirement
Users of the MHC-PMS system shall authenticate
themselves using their health authority identity
card.
 External requirement
The system shall implement patient privacy
provisions as set out in HStan-03-2006-priv.

 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
 In general, chances of conflicts within non-functional
requirements are fairly high, because information is coming
from different stakeholders. For e.g., different stakeholders
can give different response times or failure tolerance levels,
etc.
Conflicts in product requirements

 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
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.

 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.

 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.

 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

 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.

 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

 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

 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

 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
Deriving NFRs

Contd…
 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

 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…
To illustrate this approach the following figure shows the
decomposition of safety & compatibility concerns for train
protection system
Relationships between user needs, concerns and
NFRs

Compatibility
Safety
Collision Derailment
Personal
accident
Hardware Software Physical
Excess speed
for track conditions
Track damage
System must be able to
detect and avoid excess
speed
Under what conditions
can excess speed cause
derailment?
What information about
track damage is required by
the system? How is this
provided?
Interface
Execution
Environment
Timing
Will a requirement affect
the performance of the
existing software?
Does a requirement need
data that isn't available
through the HST interface?
System must execute in the trusted
Ada execution environment
Can this function be
provided on the existng
execution environment?
What does 'excess speed' mean in reality?
Concern decomposition

 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
Goal-based derivation

Example of goal-based derivation

 Stakeholders may have vague goals which cannot be
expressed precisely - Vague and imprecise
‘requirements’ are problematic
 NFRs should satisfy two attributes; must be objective
and testable (Use measurable metrics)
Testable NFRs
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
2. Number of errors made by users in a given time
period
Robustness Time to restart after system failure
Portability Number of target systems