Non-functional Requirements

Contents
Introduction
Classification of NFRs
 Some NFRs
 Deriving NFRs
 Stakeholder Concerns
 Goal-based derivation
 Testable NFRs

1
 Introduction
Non-functional requirements (NFR) define the overall
qualities of the resulting system that enhance its functionality;
 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 than other stakeholders
2
 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)
3
 NFR-Definitions

4
 Classification of NFRS

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

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

7
 Classification of NFRs…
 McCall factor model is derived from user concerns

8
 Classification of NFRs…
McCall factor model is user centred classification

9 McCall [1977]
 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
10
 Management - Verifiability, Manageability
 Classification of NFRs…
A more general classification distinguishes between product, process and
external requirements is recently proposed by Sommerville [2007]
 Product requirements
 Requirements which specify that the delivered product must
behave in a particular way e.g. execution speed, reliability, etc.
 Organisational/process requirements
 Requirements which are a consequence of organisational policies
and procedures e.g. process standards used, implementation
requirements, etc.
 External requirements
 Requirements which arise from factors which are external to the
system and its development process e.g. interoperability
requirements, legislative requirements, etc.
11
 Classification of NFRs…
Non-functional
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
12
etc…
Examples of nonfunctional requirements in the Mental Health Care- Patient
Management System (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 5 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.
13
 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 (use fit-criterion): e.g. Usability
 Examples
 The System service X shall have an availability of 999/1000 or 99%.
 SystemY shall process a minimum of 8 transactions per second.
 The executable code of System Z shall be limited to 512Kbytes.
 The system shall be user friendly.
14  New users shall be able to view their grades within 5 minutes of their first attempt at using
the system.
 Conflicts in product requirements
 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

15
 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
16  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.
17
 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
18
time.
 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.
19
  Reliability
 Definition - the extent to which the software system
consistently performs the specified functions without
failure.
 Example - The software shall have no more than X bugs per
thousand lines of code.
 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
20 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
21 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 to an extent
noticeable by any users.
22
  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.
23
 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
24 necessary.
 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
25
 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
26
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 (e.g. Mean Time To Failure-
MTTF)
 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.
27
 Contd…
 In spite of the fact, two different ways of deriving
NFRs are discussed here: Stakeholder concerns & goal-
based derivation
Stakeholder concerns
Stakeholders normally have a number of ‘concerns’
 Concerns are typically non-functional.
Examples include:
 Critical business objectives
 Essential system characteristics (e.g. security, Safety,
performance, functionality and maintainability
Vaguely defined user concerns may be related to NFRs

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

29
 Stakeholder concerns…
Relationships between user needs, concerns and NFRs

To illustrate this approach the following figure shows the

decomposition of safety & compatibility concerns for train
30 protection system
 Concern decomposition

31
 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
32
 Example of goal-based derivation

33
 Testable NFRs: Making Requirements Measurable
 Stakeholders may have vague goals which cannot be expressed
precisely - Vague and imprecise ‘requirements’ are problematic.
 We have to turn our vague ideas about quality into measurables.
 NFRs should satisfy two attributes; must be objective and testable
(Use measurable metrics)

34
 Testable NFRs: Making Requirements Measurable
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
35