The document focuses on the classification and challenges of non-functional requirements (NFRs) in requirements engineering, emphasizing their importance for system quality and functionality. It outlines dimensions for classifying requirements, examples of quality and process requirements, and specific NFRs, such as usability, availability, and accessibility. Additionally, it discusses the challenges of elicitation, evaluation, and modeling of NFRs, highlighting their impact on system design and user satisfaction.

1. Requirements Engineering:
Classification of non-
functional requirements
CECS 542
Dr. Birgit Penzenstadler
1
Photo credit: Mahkeo, Unsplash

2. Mo;va;on
Dr. Birgit Penzenstadler 2 CSULB spring 2015

3. Classifica;on of non-func;onal
requirements
• Quality of a product
• Dimensions for the classifica;on of
requirements
• Examples
• Challenges with NFRs
UCI winter 2014 Dr. Birgit Penzenstadler 3
K Rayker, stock.xchng

4. Which product is of higher quality?
4
„Quality is a complex and
mul3faceted concept.“
- Garvin
• Quality is oWen determined by
not or hard to measure system
characteris;cs
(„In the eye of the beholder.“)
à What are non-func.onal
requirements?
à Which interdependencies do
non-func.onal requirements
have with other classes of
requirements?

5. Classifica;on of requirements:
Dimensions
1. Formalisa;on
2. Degree
of abstrac;on
3. Qualita;ve and quan;ta;ve
4. Func;onal, non-func;onal
à Choice of degree of precision
– For making
qualita;ve/quan;ta;ve
statements
– For classifying requirements
into func;onal/non-func;onal.
Example
• The system is easy to use!
– Func;onal/qualita;ve implementa;on: The system shall have a help func3on
that provides the user with support at any 3me.
– Non-func;onal/quan;ta;ve: The typical user understands the system a?er 10
minutes of training.
5
Qualita;ve
Quan;ta;ve
informal formal
abstract
concrete
Abstract
requirements
Formal, abstract
requirements
Concrete
requirements
Formal, concrete
requirements
important

6. A rough classifica;on of requirements
• Func.onal requirements: All requirements refering to
func;onality (to func;onal behavior)
– Qualita;ve: Which behavior is correct (compare Use Cases)
• Non-func.onal requirements:
„Everything that is not func;onal“
– Quan;ta;ve system characteris;cs: quality (realiability,
performance, security, usability, adaptability, …)
– Constraints for the implementa;on (programming language,
opera;ng system, off-the-shelf components, …)
– Requirements w.r.t. the development process (process model,
documenta;on, development standard, milestones, costs, …)
§ Furthermore: Objec;ves with regard to marke;ng, rights,
deployment and opera;ng constraints, etc. …
6

7. Quality requirements
(1st Classifica;on)
Requirements to the quality characteris.cs of the system
• Quan;ta;ve characteris;c w.r.t. the behavior and the
func;onal usage („Quality in Use“)
Examples:
– Usability
– Reliability
– ...
• Characteris;cs, that exceed the func;onal usage of the
system (remaining „Product quality“)
Examples:
– Maintainability
– Reusability
– ...
7
ATM
Examples?

8. Simple textual template
UCI winter 2014 Dr. Birgit Penzenstadler 8

9. ATM
Examples?
Constraints (1st classifica;on)
• (Project-specific) process requirements are
requirements for the development process
Examples:
– Process model
– Project plan (milestones, budget, deadlines)
– Quality assurance (applica;on of security norms)
• Implementa;on constraints and limita;ons for the
implementa;on
(Product Constraints)
Examples:
– Structure/Architecture,
– Plagorms and technologies
– ...
9

10. Non-func;onal requirements in prac;ce
(Examples)
10
Which problems may arise
with this requirement?

11. Component Model
Behaviour Model
Usage
Model
Business Processes
Functional
Hierarchy
Component 1
Port 1 SM1.
2
SM1.
4
SM1.
3
Context
Requirements
System
F1
... ...
...... ...
Modes
Modes
Modes
... ... ...
User System
States
Component ...
External
SystemsStake
holder
Non-func;onal requirements in prac;ce
(Examples)
11
On which abstrac;on
level does this
requirement belong?
How could we
specify this
requirement in a
measurable way?

12. Component Model
Behaviour Model
Usage
Model
Business Processes
Functional
Hierarchy
Component 1
Port 1 SM1.
2
SM1.
4
SM1.
3
Context
Requirements
System
F1
... ...
...... ...
Modes
Modes
Modes
... ... ...
User System
States
Component ...
External
SystemsStake
holder
Non-func;onal requirements in prac;ce
(Examples)
12
“The system shall be maintainable.”
On which abstrac;on
level does this
requirement belong?
How could we
specify this
requirement in a
measurable way?

13. Summary: 3 challenges
1. Crosscukng Concerns: qualita;ve/quan;ta;ve statements
– Par;ally w.r.t. func;onality (e.g. performance)
– Par;ally across func;onality (e.g. maintainability)
2. Elicita;on, assessment and evalua;on
– OWen general wish w.r.t. characteris;cs, but not concrete
– No statement to which extent the characteris;c must be present
– Requirements (and implementa;on) possible on different levels of
abstrac;on with different concepts (and expressivity)
– Abstrac;on levels influence modeling concepts and characteris;cs (as
well as interdependencies), and therefore also the classifica;on
3. Classifica;on of non-func;onal requirements
– Depends on the underlying quality model
– Depends on the underlying system model and modeling concepts
13
important

14. Reading...
14

15. Philosophy
• AMDiRE concept model based on
system model and quality model
• Behavior models are in the center for
func;onal requirements and
quality requirements
Classifica.on of NFRs
• Process Requirements
• Deployment Requirements
• System Constraints
• Quality Requirements
Structured elicita.on of
quality requirements
• From system goals
• To scenarios
• To quality requirements
15
Context Layer
System Layer
Requirements Layer
Stakeholder Model Objectives
& Goals
Constraints
& Rules
!
!
!
!
!
Data Model
E
A
A
A
E
System Vision
Functional
Hierarchy
Architecture Overview
System
Function Model
Fun 1
Fun 2
Component Model
C C
Data Model
E
A
A
A
E
Behaviour Model
Business Case
Deployment Requirements
System Constraints
Domain Model
Service ModelUsage Model
Quality Requirements
Risk List
Project Scope
Process Requirements
Glossary
Glossary
Glossary
important

16. Overview of relevant Content Items
1. Process Requirements: Required
characteris;cs of the process/ project
e.g.: Use RUP as process model
2. Deployment Requirements: Demands
for deployment
e.g.: strategy to be followed for data migra;on
3. System Constraints: System-related
restric;ons that don‘t necessarily
results from func;onal goal.
E.g.: usage of specific technologies
4. Quality Requirements: desired quality
characteris;cs of the system
examples following
16
Context Layer
System Layer
Requirements Layer
Stakeholder Model Objectives
& Goals
Constraints
& Rules
!
!
!
!
!
Data Model
E
A
A
A
E
System Vision
Functional
Hierarchy
Architecture Overview
System
Function Model
Fun 1
Fun 2
Component Model
C C
Data Model
E
A
A
A
E
Behaviour Model
Business Case
Deployment Requirements
System Constraints
Domain Model
Service ModelUsage Model
Quality Requirements
Risk List
Project Scope
Process Requirements
Glossary
Glossary
Glossary
1
2
3
4
4
important

17. Template for Assignment
17
Context Layer
System Layer
Requirements Layer
Stakeholder Model Objectives
& Goals
Constraints
& Rules
!
!
!
!
!
Data Model
E
A
A
A
E
System Vision
Functional
Hierarchy
Architecture Overview
System
Function Model
Fun 1
Fun 2
Component Model
C C
Data Model
E
A
A
A
E
Behaviour Model
Business Case
Deployment Requirements
System Constraints
Domain Model
Service ModelUsage Model
Quality Requirements
Risk List
Project Scope
Process Requirements
Glossary
Glossary
Glossary
1
2
3
4
important
• 3 requirements of each type
• Descrip;on of challenges

18. Example
More examples on BeachBoard in “Ci;zen Muscle Bootcamp”
Quality NFR Usability – the system shall be easy to use.
Ra.onale Makes it more likely for users to accept a
new system.
Sa.sfac.on Criterion 90% of new users know how to carry out all
features aWer 15 minutes of use.
Measurement Test with 200 beta testers who receive a
task and measure the ;me for comple;on.
Risk If the system is not easy to use, it will be
rejected by the users and not conquer the
market.

19. Example
More examples on BeachBoard in “Ci;zen Muscle Bootcamp”
Quality NFR Availability
Descrip;on The ra;o that the system will perform acceptably at any
;me when it is running under the predefined condi;ons
and in the environment which supports its execu;on,
with the minimum down;me possible.
Ra.onale Since this system is used all around the world, the ;mes
in the day that the user would use the system would be
24/7 from a webserver’s perspec;ve, which implies
that the system would need to be up and running at all
;mes.
Sa.sfac.on Criterion The system would have the down;me no less than one
hour per week, which could be a combina;on of
smaller down;mes.
Measurement This is done by making the system live for the two
months of February and March, giving us the ;me
period of 8 consecu;ve weeks and it was noted that the
system sa;sfied the criper of not being unavailable for
more than an hour in any given week.
Risk The risk with having the system unavailable for long
;mes is that the users of the system would be
unsa;sfied with the system and there is a possibility
that these disgruntled users would move to another
system.

20. Example
More examples on BeachBoard in “Ci;zen Muscle Bootcamp”
Quality NFR Accessibility
Descrip;on This is described as the level to which the system which is created is accessed by and
provides aid to as many people as possible, including those with special needs or any form
of disability by the use of assis;ve technology.
Ra.onale The system has to made such that it can be used by a large number of people and they can
get inspired and gain the required knowledge to start their own ini;a;ves to help make
the world a beper place. Not providing assis;ve technology will restrict the use of the
system and will not reach all the audience on a large scale
Sa.sfac.on Criterion The system should provide alterna;ves by considering the various disabili;es that people
may have, such as:
✴ Providing text to speech conversion for text on the screen for those who are blind.
✴ Providing text alterna;ves for the images so that it can be converted into speech for
those who are blind.
✴ Along with different color, providing addi;onal alterna;ves such as underline for the
various highlighted text on the screen for those who are colorblind.
✴ Providing a text of all the material in the courses that can be read for those who are
deaf.
The system would have said to reach its sa;sfac;on criteria if the differently abled people
would take at the most 5 minutes to perform the same func;on as the normal users.
Measurement The fulfillment of this criteria is done through tests in which, the 20 differently abled
people are called in to the site and their interac;on with the system is monitored to check
if they can successfully interact with the system as well as the normal users of the systems
and the fulfillment of this criteria is noted
Risk If the system is not made accessible, then the system will lose on a large chunk of the
traffic coming from the differently abled people and this would reduce the number of
people gekng the required knowledge to help make the world beper.