Chapter 1part2

Non-functional Requirements

By Software dpt.
Non-functional Requirements
Contents
 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
2
 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 than other stakeholders

3
 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)
4
NFR-Definitions

5
Classification of NFRS

6
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
 Security requirements
• Operational requirements
 Portability requirements
• Resource requirements
 Quality requirements
• Verification requirements
• Acceptance requirements  Reliability requirements
• Documentation requirements  Maintainability
requirements
 Safety requirements

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

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

McCall [1977]
9
Classification of NFRs…
• McCall factor model is derived from user concerns

10
 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

11
Classification of NFRs…
A more general classification distinguishes between product, process and external
requirements is recently proposed by Sommerville [2007]

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
 Classification of NFRs…
• 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.

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

14
nonfunctional requirements

• 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.
• The system shall be developed for PC and Macintosh platforms.
• The system must encrypt all external communications using the RSA
algorithm.
• How often the system performs without failure.
• How easy it is for users to interact with the system.
• How easily the system can be updated, modified, or fixed.
• How well the system works with other existing applications or hardware.
• The system's ability to handle unexpected or erroneous inputs and recover from
errors.
• The system's ability to protect data from unauthorized access and threats.

15
 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

16
 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
time.
18
• 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 - 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.

20
• 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.
21
• 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
necessary.
24
• 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
failure and recovery
26
Driving NFRs
 "Driving NFRs" means establishing the non-functional
requirements (NFRs) for a system, which are the
quality attributes and constraints.
 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’
Examples include:
• Critical business objectives
• Essential system characteristics (e.g. security)
• Safety, performance, functionality and
maintainability
27
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 protection system.

28
 Concern decomposition

29
Goal-based derivation
• 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.

30
Example of goal-based derivation

31
 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 and 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
2. Number of errors made by users in a given time
period
Robustness Time to restart after system failure
Portability Number of target systems 32
Have you any question?
33