Requirement Engineering

Non-Functional Requirements

presented by:
Bayu Hendradjaya

Based on slides from Tor Stålhane, Steve Easterbrook, Nan

Niu, John Mylopoulos, Lawrence Chung, Brian Nixon and
Frank Tsui
 Non-functional requirements (NFR)
• Non-functional requirements define the overall qualities or attributes of
the resulting system
– Most of the time these turn out to be “constraints” on how the (functional)
requirements are to be met.
• E.g Response time must be .xyz second per screen
– Sometimes the functional requirements may have to be “sacrificed or
increased” in order to meet the non-functional requirements
• in order to satisfy security requirements, we can not let everyone access the
system --- sacrificing some flexibility
• in order to satisfy the reliability requirements, we may add a duplicative
functionality to provide another path to achieve the desired result
• Some non-functional requirements may not address the attributes
of the resulting system (product), but something else
– the system must be developed with a very risk averse process such as
Spiral or the system must be developed with Visual Basic language
• Non-functional requirements place restrictions on the product being
developed, the development process, and specify external constraints that
the product must meet.
Concrete requirements from high level goals
Goal categorization:
Similar to requirements categorizations:
 Functional and Non-functional requirements
• No clear distinction between functional and
non-functional requirements.
• 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 degree of trust which exists between a system
customer and a system developer.
 Example
• The system shall ensure that data is protected from unauthorised
access.
– Conventionally, this would be considered as a non-functional requirement
because it does not specify specific system functionality which must be
provided. However, it could have been specified in slightly more detail as
follows:
• 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.
– In this form, the requirement looks rather more like a functional
requirement as it specifies a function (user login) which must be
incorporated in the system.
 IEEE Standard 830 – 1993
List of 13 non-functional requirements:
1. Performance
2. Interface
3. Operational
4. Resource
5. Verification
6. Acceptance
7. Documentation
8. Security
9. Portability
10. Quality
11. Reliability
12. Maintainability
13. Safety

6
 Examples
1. Performance: 100 transactions per minute
2. Interface: capable of importing data with EDI format
3. Operational: must not require more than 1 megabyte of main memory
4. Resource: will use wireless encryption algorithm that is “better” than
WEP
5. Verification: all data updates must be traceable
6. Acceptance: must pass a user defined system test bucket
7. Documentation: user manual is needed for novice users only
8. Security: user request to access any data must be authorized first
9. Portability: the system must operate with “any” relational db systems
10. Quality: the system must install with zero defect
11. Reliability: the system must be accessible 99.9 % of the time
12. Maintainability: the system must be modifiable (e.g. designed with exits)
13. Safety: the system must not perform “chemical material discard”
functions without “explicit” user authorization.

7
 Sommerville’s Classification of
Non-Functional Requirements

Process Product External

Oriented Related Directed

Delivery/Updates Usability Legal rules

Implementation Reliability Economics

Process standards Safety Interoperability

Efficiency

Performance

Capacity
 These are constraints placed on various activities
related to the development and delivery of the
software product.

For example:

Process 1.The development organization must be CMM

Oriented level 3 or above.
2. The system must use some specific tool.
3. There must be a disaster recovery plan for the
system
Delivery/Updates 4. There must be an agreed to product delivery plan

Implementation

Process standards
Why do we have these requirements?

Large organizations such as fortune 500

companies or government agencies are
experienced with quality, maintenance, and
delivery problems from past. These requirements
are meant to minimize those problems.
 These are constraints which specify the desired “attributes”
that the system must possess.
Note:
- Some can be specified quantitatively and precisely;
others are difficult to quantify and are informally
specified.
Product - Sometimes these requirements may be mutually conflicting
Related (e.g. reliability versus efficiency)

Examples:

Usability 1.The system must process 100 transactions per minute

2. The system must not require 1 meg of main memory
3. The mean time between failure must be 3 months
Reliability 4. The average user learning time must be less than 1 day
5. The system must be available 99.99% of time
Safety

Efficiency

Why do we have these requirements?

Performance Many organizations have critical needs; Aviation or

Health Systems may have safety, reliability, and
Capacity performance needs beyond the normal processing
environment 10
 These are constraints which may be placed on
both the product and/or process.

For example:
Externally
Directed 1.The system must abide to HIPAA (Health Insurance
Portability and Accountability Act) privacy rules
2. The system must meet European Sales Tax laws
3. The system must use Automotive EDI for B2B
Legal rules e-commerce

Economics

Interoperability
Why do we have these requirements?

Many countries have specific financial laws, privacy

protection laws, etc. that the system must abide to.

Some industries have their own business rules

to conduct commerce.
 Non-Functional Requirement - ISO 9126
• ISO 9126 - non-functional requirements linked to
“quality in use”.
• Quality in use - users experience when using the
system.
– Since the users’ experience is subjective, many of the
quality factors will also be subjective.
• Not an ideal situation, but a situation that we must
live with.
ISO 9126 Quality in use a c c u ra c y

s u itab ility

f u n c t i o n a l i t y in tero p erab ility

co m p lian ce

s e cu rity

m atu rity

fa u lt to le ra n c e
re l i a b i l i t y
re c o v e ra b ility

av ailab ility

u n ders tan dab ility

u s a b i l i t y learn ab ility

q u a l i t y i n u s e o p e ra b ility

tim e b eh av io u r
e f f i c i e n c y
re s o u rc e u tilis a tio n

an aly s ab ility

ch an g eab ility
m a i n t a i n a b i l i t y
s tab ility

tes tab ility

adap tab ility

in s tallab ility

p o rt a b i l i t y co -ex is ten ce

c o n fo rm a n c e

re p la c e a b ility
 Difficulties in Specifying
Non-functional Requirements
• Mostly because people tend to focus on the functions and services that they
need:
– Certain non-functional requirements are sometimes hard to quantify and
therefore hard to express without some “trial and error prototyping”.
• e.g. : usability
– Certain non-functional requirements are hard to differentiate between
functional and non-functional
• e.g. security
– Certain non-functional requirements are difficult to specify because they
can not be well understood or validated until much later
• e.g. reliability or quality
– Certain non-functional requirements may be conflicting
• e.g. performance .vs. security .vs. reliability
– Certain non-functional requirements may be difficult to express and
validate; may require more refinements
• e.g. when to stop prototyping usability if the users do not clearly signal
14
satisfaction
 Understanding the Goals and Objectives

• Many have suggested that non-functional

requirements be derived from understanding the:
– Business Goals
– Objectives that the system should meet to satisfy these
Goals
– Concerns about the system meeting the objectives

This is not very easy for most technical people who have no
business experience.
Try an example of a Business Goal? Objective?, Concern?

15
Concrete requirements from high level goals
Goal refinement tree:
Refinement links are two way links: One showing goal decomposition,
other showing goal contribution
 Critical Systems
• Critical systems are systems whose failure
causes significant economic, human or
organizational damage:
– Business Critical System
• e-commerce systems such as stock trading,
reservations, etc.
– Mission Critical System
• Aircraft control, manufacturing process control, etc.
– Safety (life) Critical system
• Medical Device control, hazardous materials
management, etc.

17
 Requirements for System Criticality
• Most of the requirements for these “business,” “mission,” and
“safety” criticality deals with non-functional requirements of
the a) “complete” system, not just software and b) may be
expressed in general ways that need to be decomposed
further:

– Performance
– Reliability
– Security
– Usability
– Safety

Again, these may be “conflicting” - - - - so what do you do?

Must prioritize the requirements, especially when there are conflicts

 Performance Related Requirements
• These requirements mostly addresses the
constraints of speed and sometimes capacity:

– System Response time to end-user such as 1 second

response to user requests
– System throughput such as # of transactions per minute
(time interval)
– System timing such as collection of data and responding
to it within sub-second for real-time system.
– System capacity such as number of simultaneous users
that may access an application (instantaneous time)

These should be specified quantitatively.

 Reliability Related Requirements

• These requirements addresses constraints on run-time

behavior of the system:

– System Availability such as the system is up certain percentage of the

time.

– System Failure rate such as average mean time between system

failures to deliver the user service.

These should also be specified quantitatively.

 Security Related Requirements

• These requirements addresses the issues related to

unauthorized access: to the system, to specific function, to
data:

– System Access protection such as firewall requirement

– Application Functional Access & Usage protection such as

authorization and authentication requirement

– Data Access and Usage protection such as authorization and

encryption requirement

Security is also an important factor for other requirement such

as safety. A little hard to specify these quantitatively.
 Usability Related Requirements

• These requirements addresses the user interface looks and user inter-
actions with the system

– Entry and beginners-level knowledge assumption to use the system

– Learning time and experience needed such as hours or number of lessons to

learn the system

– Handling and usage such as time to complete certain tasks or number of errors
made before completing certain tasks

– Likeness and delight experienced from using the system such as availability of
context sensitive help text or “re-do” capability

Some of these requirements can be and should be specified

Quantitatively; delight and likeness are a bit hard to define.
 Safety Critical System Requirements

• These requirements addresses everything with the

safety of the system and of the usage of the system.
• These requirements deal mostly with the “shall not”
requirements such as:

– The system shall not allow - - - -

– The system will not operate without - - -
Note that safety may be dependent on many of the other requirements:

- insecure system may be open to malicious danger

- unreliable system may fail unpredictably and hurt someone
- non-responsive system may miss critical data and damage something
- difficult to use system may create a critical human error
 Requirements Engineering for Safety-Related System

• Safety-related requirements engineering needs a “safety-

analysis” Step:

1. Safety requirements discovery:

• Hazard identification
• Risk analysis

2. Safety Validation
• Analysis of the discovered requirements to ensure that there is no
conflict with other requirements
 1. Safety Requirements Discovery
• Identify potential hazard
– This may be as simple as listing the hazards and placing “priorities” based on
some damage value
– One may use some form of a tree to help generate and classify the hazards.

• The identified hazards may be viewed through some risk assessment and
analysis to generate requirements in stages:
– Avoidance requirements to ensure that the hazard will not occur in the first
place
– Prevention requirements to ensure that if the hazard occurs then it does not
result in a damage
– Protection requirements address the situation where if the accident does
occur it only causes limited damage.
 2. Requirements Conflict Resolution

Reliability
Performance

Safety Related
Requirements

Usability
........ Security

26
 Software Qualities

 Think of an everyday object

 e.g. a chair
 How would you measure it’s “quality”?
 construction quality? (e.g. strength of the joints,…)
 aesthetic value? (e.g. elegance,…)
 fit for purpose? (e.g. comfortable,…)
 All quality measures are relative
 there is no absolute scale
 we can sometimes say A is better than B…
 … but it is usually hard to say how much better!
 For software:
 construction quality?
 software is not manufactured
 aesthetic value?
 but most of the software is invisible
 aesthetic value matters for the user interface, but is only a marginal concern
 fit for purpose?
 what’s the purpose? what’s fit?

10
 Factors vs. Criteria
 Quality Factors
 These are customer-related concerns
 Examples: efficiency, integrity, reliability, correctness, survivability, usability,...

 Design Criteria
 These are technical (development-oriented) concerns such as anomaly
management, completeness, consistency, traceability, visibility,...
 Quality Factors and Design Criteria are related:
 Each factor depends on a number of associated criteria:
 E.g. correctness depends on completeness, consistency, traceability,...
 E.g. verifiability depends on modularity, self-descriptiveness and simplicity
 There are some standard mappings to help you…
 During Analysis:
 Identify the relative importance of each quality factor
 From the customer’s point of view!
 Identify the design criteria on which these factors depend
 Make the requirements measurable

12
 Functionality – Factor
The capability of the software to provide
functions which meet stated and implied needs
when the software is used under specified
conditions.
 Functionality – Criteria
• Suitability: Capability of the software to provide an
appropriate set of functions for specified tasks and user
objectives.
• Accuracy: Capability of the software to provide the right or
agreed.
• Interoperability: Capability of the software to interact with
one or more specified systems.
• Compliance: Capability of the software to adhere to
application related standards, conventions or regulations in
laws and similar prescriptions.
• Security: Capability of the software to prevent unintended
access and resist deliberate attacks intended to gain
unauthorised access to confidential information, or to make
unauthorised modifications to information or to the program
so as to provide the attacker with some advantage or so as to
deny service to legitimate users.
 Reliability – Factor

• The capability of the software to maintain the level

of performance of the system when used under
specified conditions
• Wear or aging does not occur in software.
• Limitations in reliability are due to faults in
requirements, design, and implementation.
• Failures due to these faults depend on the way the
software product is used and the program options
selected rather than on elapsed time.
 Reliability – Criteria
• Maturity: Capability of the software to avoid failure as a
result of faults in the software.
• Fault tolerance: Capability of the software to maintain a
specified level of performance in cases of software faults or
of infringement of its specified interface.
• Recoverability: Capability of the software to re-establish its
level of performance and recover the data directly affected
in the case of a failure.
• Availability: Capability of the software to be in a state to
perform a required function at a given point in time, under
stated conditions of use.
 Usability – Factor
• Capability of the software to be understood,
learned, used and liked by the user, when
used under specified conditions.
• Some aspects of functionality, reliability and
efficiency will also affect usability, but for the
purposes of this International Standard are
not classified as usability.
 Usability – Criteria
• Understandability: Capability of the software
product to enable the user to understand whether
the software is suitable, and how it can be used for
particular tasks and conditions of use.
• Learnability: Capability of the software product to
enable the user to learn its application
• Operability: Capability of the software product to
enable the user to operate and control it.
• Likeability: Capability of the software product to be
liked by the user.
 Efficiency – Factor
• The capability of the software to provide the
required performance relative to the amount
of resources used, under stated conditions
• Resources may include other software
products, hardware facilities, materials, (e.g.
print paper, diskettes).
 Efficiency – Criteria
• Time behavior: Capability of the software to
provide appropriate response and processing
times and throughput rates when performing
its function, under stated conditions.
• Resource utilisation: Capability of the
software to use appropriate resources in an
appropriate time when the software performs
its function under stated conditions.
 Maintainability – Factor
• The capability of the software to be modified.
• Modifications may include corrections,
improvements or adaptation of the software
to changes in environment, and in
requirements, and functional specifications.
 Maintainability – Criteria
• Changeability: Capability of the software
product to enable a specified modification to
be implemented.
• Stability: Capability of the software to
minimise unexpected effects from
modifications of the software
• Testability: Capability of the software product
to enable modified software to be validated.
 Portability – Factor
• The capability of software to be transferred
from one environment to another.
• The environment may include organizational,
hardware or software environment.
 Portability – Criteria
• Adaptability: Capability of the software to be modified for
different specified environments without applying actions or
means other than those provided for this purpose for the
software considered.
• Installability: Capability of the software to be installed in a
specified environment.
• Co-existence: Capability of the software to co-exist with other
independent software in a common environment sharing
common resources
• Conformance: Capability of the software to adhere to
standards or conventions relating to portability.
• Replaceability: Capability of the software to be used in place
of other specified software in the environment of that
software.
 Setting Requirements – 1
Can set non-functional requirements in at least
three ways – to
• The way the system behaves – user level
• The way the product is developed – process
level
• The way the software is – product or metrics
level
 Setting Requirements – 2
• If we will state requirements that are testable,
we at least need to go to the criteria level.
• In order to demonstrate how this can be done
we will look at two important factors –
maintainability and reliability.
• What follows is only an example. There are
several other ways to set reliability and
maintainability requirements.
 Setting Requirements – 3
• The method used in the example is based on
T. Gilb’s ideas of MbO – Management by
Objectives.
• We start with the requirement – e.g. the
system shall be easy to maintain.
• We then follow up with “what do you mean
by…” until we reach something that is
observable and thus testable.
 Setting Requirements – 4
When we use MbO or other related techniques
for setting requirements we will in most cases
have a situation where:
• The user will have to participate in the tests in
one way or another.
• There will be a strong link between
requirement and test. In many cases the
requirement will be the test.
 The MbO – Customer View
Requirement: “The system shall be easy to
maintain”
1. What do you mean by “easy to maintain”
2. No error identification and correction shall
need more than two person-days.
Note – other changes are not mentioned.

For the customer, these requirements are OK.

 The MbO – Developer View
Next step - ask the developers how they will
achieve this requirement.
For maintainability this can be requirements on
– Maximum class size
– Coupling and cohesion
– Self-documenting names for all entities
– Etc.
 Maintainability Requirements - 1
• Changeability:
No error shall need more than one person-
days to identify and fix
• Stability:
Not more than 10% of the corrections shall
have side-effects
• Testability:
The correction shall need no more than one
person-day of testing. This includes all
necessary regression testing
 Reliability Requirements
• Maturity:
MTTF = TTT / n. MTTF > 500 hrs.
• Fault tolerance:
Under no circumstances shall the system crash.
• Recoverability:
In case of an error, the time needed to get the
system up and running again shall not exceed one
hour (MTTR).
• Availability:
MTTF /(MTTF + MTTR) > 0.998
 Reliability Tests – 1
• MTTF = TTT / n. MTTF > 500 hrs. Use 10 PCs. Test for
two weeks => TTT = 800. Not more than one error.
• Under no circumstances shall the system crash.
Generate random input sets. No check for result is
necessary – only crash / no crash,
• In case of an error, the time needed to get the
system up and running again shall not exceed one
hour (MTTR).
 Reliability Tests – 2
We need to consider three data:
• The total testing time – TTT.
– For how long have we tested the system?
• The usage frequency – UF.
– How often is the system used at the users’ site?
• Number of users each time the system is used
We need to distinguish between test time – TTT
– and usage time.
 Reliability Tests – 3
Simple Example:
• Have TTT = 400 hrs.
• The system will be used one hour once a week
– e.g. for accounting purposes – at 10 sites.
• We then have 10 hrs. of use per week.
– Under the assumption that all 10 sites use the
system the way it is tested, our test is equivalent
to 40 weeks of real use.
 More Non-functional Requirements
• Relatively simple to make requirement and
tests for reliability, maintainability and other
“objective” non-functional factors.
• Subjective factors (e.g. usability) are more
difficult.
– Will use usability as an example to show the
couplings between
 Usability requirements – 1
• Understandability: The capability of the software
product to enable the user to understand whether
the software is suitable, and how it can be used for
particular tasks and conditions of use.
• Learnability: The capability of the software product
to enable the user to learn its application
• Operability: The capability of the software product
to enable the user to operate and control it.
• Likeability: The capability of the software product to
be liked by the user.
 Usability Requirements – 2
• All the usability criteria are subjective.
• As a result, tests will also have a strong component
of subjectivism.
• Understand
– Whether the software is suitable for a particular task
– How it can be used for particular tasks
– Under which conditions it can be used
• Learn its application
• Operate and control it (the software)
• Is the software product liked by the user?
 Requirements – First Step
• First step - apply the MbO for each criteria.
• Look at two of the requirements:
– Learn its application
What does it mean to “learn application”
– Is the software product liked by the user
What do you mean by “liked”?
 Requirements – Second Step
• Learn application:
– Can use the system after a one week course.
– Use the system for two weeks and then solve a set
of standardized problems.
• Like application:
– Score high on a likeability scale – e.g. 90 % score 7
or higher on a scale from 1 to 10 – after a one
week course and two weeks of real use.
 Requirements – to Remember
• The test says much more about the
requirement than the requirement itself does.
• We need to
– Develop a course, a set of standardized problems
and a likeability questionnaire.
– Include the customer’s participation in the test
into the contract. Who will pay for this?