Non-Functional
Requirements
Software engineering
INTRODUCTION
Non-functional requirements define the overall
qualities or attributes of the resulting system.
Non-functional requirements place restrictions on
the product being developed, the development
process, and specify external constraints that the
product must meet such requirements are safety,
security, usability, reliability and performance
requirements.
05/11/25 2
Concrete requirements from high level goals
Goal categorization:
Similar to requirements categorizations:
05/11/25 3
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.
Examples:
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.
05/11/25 4
Examples
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.
05/11/25 5
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.
05/11/25 6
ISO 9126 Quality in use
accuracy
suitability
f unc t i o nal i t y interoperability
compliance
security
maturity
fault tolerance
re l i abi l i t y
recoverability
availability
understandability
us abi l i t y learnability
qual i t y i n us e operability
time behaviour
e f f i c i e nc y
resource utilisation
analysability
changeability
m ai nt ai nabi l i t y
stability
testability
adaptability
installability
po rt abi l i t y co-existence
conformance
05/11/25 replaceability 7
Concrete requirements from high level goals
Goal refinement tree:
Refinement links are two way links: One showing goal decomposition, other showing goal
contribution
05/11/25 8
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!
05/11/25 9
Functionality – Factor
The capability of the software to provide
functions which meet stated and implied
needs when the software is used under
specified conditions.
05/11/25 10
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.
05/11/25 11
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.
05/11/25 12
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.
05/11/25 13
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.
05/11/25 14
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.
05/11/25 15
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).
05/11/25 16
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.
05/11/25 17
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.
Willuse usability as an example to show the
couplings between
05/11/25 18
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.
05/11/25 19
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?
05/11/25 20
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”?
05/11/25 21
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.
05/11/25 22
Dealing with Requirements like this
05/11/25 23
Summary
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?
05/11/25 24
Any Questions?
05/11/25 25
References
1) SOFTWARE ENGINEERING , Ninth
Edition,by Ian Sommerville.
2) Based on slides from Tor
Stålhane, Steve Easterbrook,
Nan Niu, John Mylopoulos,
Lawrence Chung, and Brian
Nixon
05/11/25 26