Chapter 9, Non-functional Requirements

Organizational
Requirements
Engineering
Prof. Dr. Armin B. Cremers
Sascha Alda

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 1

Overview of remaining sessions

z 11.1.2006 Non-functional Requirements

z 18.1.2006 Interactive Systems
z 25.1.2006 Practice Talk “Deutsche Post World Net”
z 1.2.2006 Practice Talk “sd&m”

z 8.2.2006 Written Exam

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 2

Overview on this session

z Introduction and Motivation

z Classification and Presentation of Non-functional Requirements
‹ Excurse: Tailorability
z Derivation of Non-functional Requirements
z Question catalogue

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 3

Non-functional requirements (NFR)

z Non-functional requirements define the overall qualities or

attributes of the resulting system
z Non-functional requirements place restrictions on the product
being developed, the development process, and specify external
constraints that the product must meet.
z Examples of NFR include safety, security, usability, reliability and
performance requirements.

z Project management issues (costs, time, schedule) are often

considered as non-functional requirements as well
Æ not handled in this session

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 4

Functional vs. Non-functional
requirements

z There is no a clear distinction between functional and non-

functional requirements.
z Whether or not a requirement is expressed as a functional or a
non-functional requirement may depend:
‹ on the level of detail to be included in the requirements document
‹ the comprehension of application domain and the desired system
‹ experience of developers

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 5

Functional vs. Non-functional
requirements
z Some properties of a system may be expressed either as a
functional or non-functional property.
z Example. The system shall ensure that data is protected from
unauthorised access.
z Conventionally a non-functional requirement (security) because it
does not specify specific system functionality
z Expressed as functional requirement:
• The system shall include a user authorisation procedure where users
must identify themselves using a login name and password. Only
users who are authorised in this way may access the system data.

Æ Non-functional requirements may result in new functional

requirements statements

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 6

Types of Non-functional requirements

z 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 ‹Quality requirements
‹ Documentation requirements ‹Reliability requirements
‹ Security requirements ‹Maintainability requirements
‹ Portability requirements ‹Safety requirements

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 7

Classification of Non-functional
requirements (Jacobson, 1999)

z The FURPS+ model is proposed for the Unified Process.

‹ Functional Requirements
‹ Usability
‹ Reliability
‹ Performance
‹ Supportability
z The FURPS+ model provides additional requirements typically also
included under the general label of non-functional requirements:
‹ Implementation requirements
‹ Interface requirements
‹ Operations requirements
‹ Packaging requirements
‹ Legal requirements

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 8

Classification of Non-functional
requirements (Sommerville)

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

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 9

Product Requirements

z Specify the desired characteristics that a system or subsystem

must possess.
z Most NFRs are concerned with specifying constraints on the
behaviour of the executing system.
‹ Limit the freedom of the system designers
‹ Limit the free choice of off-the-shelf-components

z Some can be formulated precisely and easily quantified

‹ Performance, Reliability
z Some are difficult to quantify
‹ Usability, Adaptability

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 10

Requirements for critical systems

z Non-functional (product) requirements play an important role for

critical systems
z Systems whose ‘failure’ causes significant economic, physical or
human damage to organisations or people.
z There are three principal types of critical system:
‹ Business critical systems
Î Failure leads to significant economic damage

‹ Mission critical systems

Î Failure leads to the abortion of a mission

‹ Safety critical systems

Î Failure endangers human life

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 11

Requirements for critical systems

z The principal non-functional constraints which are relevant to

critical systems:
‹ Reliability
‹ Performance
‹ Security
‹ Safety
‹ Usability

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 12

Reliability

z Reliability is the ability of a system to perform its required

functions under stated conditions for a specific period of time
z Constraints on the run-time behaviour of the system
z Can be considered under two separate headings:
• Availability - is the system available for service when requested by
end-users.
• Failure rate - how often does the system fail to deliver the service as
expected by end-users.
z Many related items:
• Dependability
• Dependability of a computing system is the ability to deliver service that
can justifiably be trusted by users
• Reputation
• the general opinion (more technically, a social evaluation) of the public
toward a person, a group of people
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 13
Performance

z Performance requirements concern the speed of operation of a

system
z Types of performance requirements:
• Response requirements (how quickly the system reacts to a user
input)
• Throughput requirements (how much the system can accomplish
within a specified amount of time)
• Availability requirements (is the system available for service when
requested by end-users)
z Many related items:
• Scalability
• the capability of a system to increase total throughput under an
increased load when resources (typically hardware) are added

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 14

Product Requirements
Examples

z The System service X shall have an availability of 999/1000 or

99%. This is a reliability requirement which means that out of
every 1000 requests for this service, 999 must be satisfied.

z System Y shall process a minimum of 8 transactions per second.

This is a performance requirement.

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 15

Security

z Security requirements are included in a system to ensure:

‹ Unauthorised access to the system and its data is not allowed
‹ Ensure the integrity of the system from accidental or malicious
damage
z Examples of security requirements are:
‹ The access permissions for system data may only be changed
by the system’s data administrator
‹ All system data must be backed up every 24 hours and the
backup copies stored in a secure location which is not in the
same building as the system
‹ All external communications between the system’s data server
and clients must be encrypted

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 16

Usability

z Usability is the ease with which a user can learn to operate,

prepare inputs for, and interpret outputs of system or component
z Usability requirements include:
‹ Well-structured user manuals
‹ Informative error messages
‹ Help facilities
‹ Well-formed graphical user interfaces

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 17

Usability Metrics

z Measurable attributes of usability requirements include:

‹ Entry requirements Measured in terms of years of experience with
class of applications or simply age
‹ Learning requirements Denotes the time needed to learn the facilities
of the system. This could be measured in terms of speed of learning,
say hours of training required before independent use is possible
‹ Handling requirements Denotes the error rate of the end-users of the
system. This could be measured in terms of the errors made when
working at normal speed
‹ Likeability Denotes ‘niceness’ to use. The most direct to measure user
satisfaction is to survey actual users and record the proportion who
‘like to work with the product’

z … more about Usability see next week

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 18

Safety

z No consensus in the system’s engineering community about what

is meant by the term ‘safety requirement’

z Usage of the term often depends on the culture and practice of

the organisation (often mixed up with security)
z Informal definition:
Safety requirements are the ‘shall not’ requirements which
exclude unsafe situations from the possible solution space of the
system

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 19

Examples of safety requirements

z The violated system shall not permit any further operation unless
the operator guard is in place
z The system shall not operate if the external temperature is below
4 degrees Celsius
z The system should not longer operate in case of fire (e.g. an
elevator)
z The system should no longer operate if security attacks have
become obvious (Æ relation to security requirements)

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 20

Supportability

z Supportability requirements are concerned with the ease of

changes to the system after deployment. Classes:
z Adaptability:
‹ The ability to change the system to deal with additional application domain
concepts (adaptivity = autonomous adaptation)
z Maintainability:
‹ The ability to change the system to deal with new technology or to fix
defects)
z Internationalization:
‹ The ability to change the system to deal with additional international
conventions such as languages, or number formats, styles)
z Portability:
‹ The ease with which a system or component can be transferred from one
environment to another)
z Tailorability:
‹ End-User Adaptation (next slides)
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 21
Excurse: Tailorability

z Fields of application are differentiated and dynamically changing

‹ New tasks and working contexts arise
‹ Individual qualifications

z Tailorability is defined
‹ changing aspects of an application‘s functionality
‹ in a persistent way (by means of tailored artifacts)
‹ during the use of an application (at runtime)
‹ by end-users or local experts

z Technical flexibility beyond

‹ modifications of parameters (e.g. Windows Registry)
‹ (re-)programming

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 22

Tailorability
Challenges

z Flexible Architecture
‹ Rule-based architectures
‹ Component-based architectures (simple and compound components)

z Appropriate Interfaces
‹ Visualizing and manipulating tailored artifacts: 2D and 3D Interfaces
‹ Describing tailored artifacts: Annotations, attaching examples
‹ Understanding tailored artifacts: Exploration Environments
‹ Providing support for tailoring: Integrity checking
‹ Accessing tailoring functions: Direct Activation

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 23

Tailorability
Levels of tailoring strategies (Morch, 1997)

z Problem: User do not have experience with tailoring

z Goal: Provide tailoring routines on different levels of complexity
z End-user with little experience can adopt to less complex routines
z More experienced may use more sophisticated routines
z Proposed Levels:
‹ Customization
Î Modification of presentation objects among a set of pre-defined
configuration options
‹ Integration
Î Creation or the combination of (existing) program behavior that results
in new behavior
‹ Extension
Î Adding completely new behavior (Æ re-implementation)

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 24

Component-Orientation for as basis
for tailorable systems

z Properties of components
Î Independently developed parts of software
Î Independently exchangeable
Î Several components interact as one application or system

My App‘

My App‘

My App
My App

Changing the set of Changing the Re-programming a

Changing components within a connections between component‘s
Parameters composition components functionality

Customization Integration Extension

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 25
Example for 3D tailoring environment
(For client-server-based groupware system)

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 26

Product Requirements
Examples

z There are product requirements which relate to the source code

of the system
z Examples
‹ The system shall be developed for PC and Macintosh platforms. This
is a portability requirement which affects the way in which the
system may be designed
‹ The system must encrypt all external communications using the RSA
algorithm. This is a security requirement which specifies that a
specific algorithm must be used in the product

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 27

Product Requirements
Conflicts

z Product requirements are often conflict. For example:

‹ A requirement for a certain level of performance may be contradicted
by security requirements which use processor capacity to carry out
complex cipher algorithms
‹ A requirement on the memory utilisation of the system may be
contradicted by another requirement which specifies that a standard
compiler which does not generate compact code must be used
‹ Adaptable or tailorable software may lead to software that is unsafe
z The process of arriving at a trade-off in these conflicts depends
on:
‹ The level importance attached to the requirement
‹ The consequence of the change on the other requirements and,
‹ The wider business goals

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 28

Process Requirements

z Process requirements are constraints placed upon the

development process of the system
z 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

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 29

Examples of process requirements

z The development process to be used must be explicitly defined and

must be conformant with ISO 9000 standards
z The system must be developed using the XYZ suite of CASE tools
z Management reports setting out the effort expended on each
identified system component must be produced every two weeks
z A disaster recovery plan for the system development must be
specified

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 30

External requirements

z May be placed on both the product and the process

z Derived from the environment in which the system is developed
z 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

z Legal requirements:
‹ Concerned with licensing, regulation, and certification issue

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 31

External requirements

z Medical data system: The organization's data protection officer

must certify that all data is maintained according to data
protection legislation before the system is put into operation.

z A software is regulated under the GNU General Public License

‹ make sure the software is free for all its users, that is, everybody can
share and change the software
‹ No warranty, no patents

z Web pages developed for federal government of NRW must

comply with the law for equality of treatment of people with
disabilities (obstacle free Internet, from 1/1/2006)
‹ Blind people should be enabled to interpret web pages (tools…)

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 32

Deriving non-functional requirements

z No adequate methods are provided

‹ Functional analysis or object-oriented analysis are limited as soon as non-
functional concerns are regarded
z NFRs are difficult to express. Reasons:
‹ Certain constraints are related to the design solution that is unknown
at the requirements stage
‹ Certain constraints, are highly subjective and can only be determined
through complex empirical evaluations
‹ 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.

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 33

Stakeholder concerns

z Stakeholders normally have a number of ‘concerns’ that come with

their desired system
z Concerns are typically high-level strategic goals and are non-
functional
z Examples include:
‹ Critical business objectives (standards)
‹ Essential system characteristics (e.g. security)
‹ Safety, performance, functionality and maintainability
z Vaguely defined user concerns may be related to NFRs

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 34

Relationships between user needs,
concerns and NFRs

User’s need User’s concern Non-functional

requirement
Function 1. Ease of use 1. Usability
2. Unauthorised access 2. Security
3. Likelihood of failure 3. Reliability
Performance 1. Resource utilisation 1. Efficiency
2. Performance verification 2. Verifiability
3. Ease of interfacing 3. Interoperability
Change 1. Ease of repair 1. Maintainability
2. Ease of change 2. Flexibility
3. Ease of transport ? 3. Portability
4. Ease of expanding or upgrading capacity 4. Expandability
or performance ?

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 35

Goal-based derivation

z Relates non-functional requirements to the goals of the enterprise

z Goal-based NFR derivation is a 3 step approach:
‹ Identify the enterprise goal
‹ Decompose of the goal into sub-goals
‹ Identify non-functional requirements.

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 36

Example of goal-based derivation

Go al IS - g o al
motivates The system should perform in
Visualise air traffic scenarios
real-time
OM
motivates

IS - NFR IS - NFR
Display radar data The display must accommodate
in real-time all data from the scenario

motivates

motivates
IS - NFR
Aircraft position should be displayed in less
than 3/16 sec of the radar sweep period

IS - NFR IS - NFR IS - NFR IS - NFR

Display 100 tracks Display 100 Display 200 vectors Display 500 table
meteorological plots symbols

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 37

Testable NFRs

z Stakeholders may have vague goals which cannot be expressed

precisely
z Vague and imprecise ‘requirements’ are problematic
z NFRs should satisfy two attributes
‹ Must be objective
‹ Must be testable (Use measurable metrics)
z It is not always possible to express NFRs objectively

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 38

Examples of measurable metrics for
Non-functional requirements

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, Mbytes

Usability 1. Time taken to learn the software

2. Number of errors made by user
Robustness Time to restart the system after failure
Portability Number of target systems

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 39

Nonfunctional Requirements:
Trigger Questions (1/4)
z User interface and human factors
‹ What type of user will be using the system?
‹ Will more than one type of user be using the system?
‹ What sort of training will be required for each type of user?
‹ Is it particularly important that the system be easy to learn?
‹ Is it particularly important that users be protected from making
errors?
‹ What sort of input/output devices for the human interface are
available, and what are their characteristics?

z Documentation
‹ What kind of documentation is required?
‹ What audience is to be addressed by each document?

z Hardware considerations
‹ What hardware is the proposed system to be used on?
‹ What are the characteristics of the target hardware, including
memory size and auxiliary storage space?
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 40
Nonfunctional Requirements:
Trigger Questions (2/4)

z Performance characteristics
‹ Are there any speed, throughput, or response time constraints on
the system?
‹ Are there size or capacity constraints on the data to be processed
by the system?
z Error handling and extreme conditions
‹ How should the system respond to input errors?
‹ How should the system respond to extreme conditions?
z System interfacing
‹ Is input coming from systems outside the proposed system?
‹ Is output going to systems outside the proposed system?
‹ Are there restrictions on the format or medium that must be used
for input or output?

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 41

Nonfunctional Requirements:
Trigger Questions (3/4)
z Quality issues
‹ What are the requirements for reliability?
‹ Must the system trap faults?
‹ What is the maximum time for restarting the system after a failure?
‹ What is the acceptable system downtime per 24-hour period?
‹ Is it important that the system be portable (able to move to
different hardware or operating system environments)?

z System Modifications
‹ What parts of the system are likely candidates for later
modification?
‹ What sorts of modifications are expected (levels of adaptation)?
‹ Are the users willing to tailor an application?
‹ What kind of interface is required?
‹ Might unwary adaptations lead to unsafe system states?

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 42

Nonfunctional Requirements:
Trigger Questions (4/4)

z Security Issues
‹ Must access to any data or the system itself be controlled?
‹ Is physical security an issue?

z Resources and Management Issues

‹ How often will the system be backed up?
‹ Who will be responsible for the back up?
‹ Who is responsible for system installation?
‹ Who will be responsible for system maintenance?

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 43

Summary

z Non-functional requirements define the overall qualities or

attributes of the resulting system
z Non-functional requirements may be classified into three main
types; product, process and external requirements
z Product requirements specify the desired characteristics that the
system or subsystem must posses
z Non-functional requirements tend to conflict and interact with
other system requirements
z The principal non-functional constraints which are relevant to
critical systems are reliability, performance, security, usability and
safety

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 44