1. Technische Universität München
On the Distinction of
Functional and Quality Requirements in Practice
Daniel Méndez
Technical University of Munich
Germany
PROFES 2016
Trondheim, Norway
@mendezfe
Joint work with
Jonas Eckhardt (Technical University of Munich)
AndreasVogelsang (Technical University of Berlin)

3. Objective
— RQ 1
— RQ 2
— RQ 3
We want to better understand
• whether practitioners handle Functional Requirements
(FR) differently from Quality Requirements (QR),
• why they do so, and
• what the consequences are.

4. Methodology
Overview
Vehicle: Survey Research
Purpose: Exploratory / Curiosity-driven
Target Population: Practitioners handling
requirements (directly or indirectly)
Data Collection: Feb 4th - Feb 22nd
Data Analysis: Descriptive statistics and
manual coding of free-text answers
Details: goo.gl/EppYXr
– Instrument*
– Raw data
– Coding results
Demographics
* Instrument (overview)
Documentation Practice
No documentation
of QR
Documentation of
QR
No distinction
(from FR)
Distinction
(from FR)
RQ 1
ReasoningRQ 2
Consequences (problems and benefits)RQ 3

5. Study results
Demographics / Sample Characteristics
• 103 responses considered for data analysis (283 reached via different channels)
• 93% of respondents with more than 3 years experience
??
0 0,25 0,5 0,75 1
0,0137%21%41%
rather agile
rather plan-driven
mixed
did not know...
Software processes mix of agile and plan-driven
0 0,25 0,5 0,75 1
0,0534%37%24%
embedded systems
business inf. systems
hybrid systems
consumer SW
Balanced families of systems
Diverse project team sizes
0 0,25 0,5 0,75 1
0,0624%46%24%
< 11 team members
11-50 team members
> 50 team members
did not know...
Requirements specification has an important role
0 0,25 0,5 0,75 1
19%23%57%
for in-house development
for external development
subcontractors using SRS

6. Study results
RQ 1 - Do practitioners handle QRs differently?
Do practitioners document QRs (at all)?
0 0,25 0,5 0,75 1
12%88%
Documentation
No documentation
0%
25%
50%
75%
100%
Agile Mixed Plan-driven
Document QRs No QRs
blocking

7. Study results
RQ 1 - Do practitioners handle QRs differently?
Do practitioners differentiate between QRs and FRs in the documentation?
0 0,25 0,5 0,75 1
15%85%
Distinction
No distinction
0%
25%
50%
75%
100%
Agile Mixed Plan-driven
Distinction No distinction
blocking

8. Study results
RQ 1 - Do practitioners handle QRs differently?
To what extent do development activities for QRs differ from
activities for FRs?
Distinction No distinction
RE
Arch/Design
Impl
Testing
0% 25% 50% 75% 100% 0% 25% 50% 75% 100%
Differs strongly Differs slightly Does not differ at all Don't Know
52% 31%12%
48% 31% 8%13%
27% 43% 13% 17%
23% 47% 26%
57% 21%21%
21% 43% 21% 14%
36% 43% 14%7%
14% 36% 43% 7%

9. Distinction No distinction
RE
Arch/Design
Impl
Testing
0% 25% 50% 75% 100% 0% 25% 50% 75% 100%
Differs strongly Differs slightly Does not differ at all Don't Know
52% 31%12%
48% 31% 8%13%
27% 43% 13% 17%
23% 47% 26%
57% 21%21%
21% 43% 21% 14%
36% 43% 14%7%
14% 36% 43% 7%
“NFRs are drivers for architectural decisions.
Tests depend strongly on NFRs.”
“It does not make any difference.
Both [QR and FR] are important.”
versus

10. Study results
RQ 2 & 3 - Reasons, Problems, and Benefits
Distinction /
No Distinction
Reason
(#Occurence)
Reason
(#Occurence)
Project phase
Project phase
Reason
(#Occurence)
Reason
(#Occurence)
Consequence
(#Occurence)
Consequence
(#Occurence)
Project phase
Project phase
Consequence
(#Occurence)
Consequence
(#Occurence)
RQ 2 What are the reasons for distinguishing (or
not) between QRs and FRs in the documentation?
RQ 3 What are (positive / negative) consequences of
distinguishing (or not) QRsand FRs in the documentation?

11. Study results
RQ 2 & 3 - Reasons, Problems, and Benefits
General & Project Organiza2on
RE
Design & Implementa2on
Valida2on & Verifica2on
Influence the Architecture (6)
QRs require different verifica9on methods (9)
QRs can only be reviewed (2)
General & Project Organiza2on
RE
Valida2on & Verifica2on
Design & Implementa2on
Focused implementa9on (1)
General & Project Organiza2on
RE
Valida2on & Verifica2on
Design & Implementa2on
Focus too much on FR (2)
Late architectural changes (2)
Unclear tes9ng process for QRs (2)
Distinction btw.
QRs and FRs
Compliance to customer constraints (2)
Company Prac9ce (10)
QRs are cross-func9onal (8)
Improved reuse (3)
Different responsibility (3)
Different exper9se (2)
Find informa9on in one place (2)
QRs have different nature (10)
QRs cannot be completed before end of the proj. (2)
Completeness of Requirements (3)
Reduce Ambiguity (2)
Different stakeholders (4)
QR defect may lead to weak user acceptance (2)
QRs are forgoUen (2)
Dis9nc9on between QR and FR unclear (2)
QRs are neglected (2)
Traceability becomes expensive (4)
Find informa9on in one place (5)
Separa9on of concerns (3)
Increased awareness of QRs (4)
Structured Process (4)
Reuse of QRs (4)
Increased Product Quality (2)
BeUer domain/system understanding (2)
Completeness of Requirements (2)
Clearer responsibility for QRs (2)
Increased awareness of QRs (2)
Find informa9on in one place (2)
Focused Design (2)
Focused Tests (4)
Explicit QR Tests (3)
Reduce Ambiguity (2)
Different priority (2)
Distinguishing QRs and FRs

12. General & Project Organiza2on
RE
Design & Implementa2on
Valida2on & Verifica2on
Influence the Architecture (6)
QRs require different verifica9on methods (9)
QRs can only be reviewed (2)
Focus too m
Distinction bt
QRs and FR
Compliance to customer constraints (2)
Company Prac9ce (10)
QRs are cross-func9onal (8)
Improved reuse (3)
Different responsibility (3)
Different exper9se (2)
Find informa9on in one place (2)
QRs have different nature (10)
QRs cannot be completed before end of the proj. (2)
Completeness of Requirements (3)
Reduce Ambiguity (2)
Different stakeholders (4)
QR defect may lead to weak user a
QRs are
Dis9nc9on between QR and FR
QRs are neg
Traceability becomes expe
Find informa9on in one
Separa9on o
Increased awarene
Structured
Reuse
Increased Pr
BeUer domain/system
Completeness of R
Clearer responsib
Reduce Ambiguity (2)
Different priority (2)

13. RE
General & Project Organiza2on
RE
Valida2on & Verifica2on
Design & Implementa2on
Focused implementa9on (1)
General & Project Organiza2on
RE
Valida2on & Verifica2on
Design & Implementa2on
Focus too much on FR (2)
Late architectural changes (2)
Unclear tes9ng process for QRs (2)
Distinction btw.
QRs and FRs
s (3)
(2)
rs (4)
QR defect may lead to weak user acceptance (2)
QRs are forgoUen (2)
Dis9nc9on between QR and FR unclear (2)
QRs are neglected (2)
Traceability becomes expensive (4)
Find informa9on in one place (5)
Separa9on of concerns (3)
Increased awareness of QRs (4)
Structured Process (4)
Reuse of QRs (4)
Increased Product Quality (2)
BeUer domain/system understanding (2)
Completeness of Requirements (2)
Clearer responsibility for QRs (2)
Increased awareness of QRs (2)
Find informa9on in one place (2)
Focused Design (2)
Focused Tests (4)
Explicit QR Tests (3)
2)
(2)

14. Study results
RQ 2 & 3 - Reasons, Problems, and Benefits
General & Project Organiza2on
RE
Design & Implementa2on
Valida2on & Verifica2on
QRs are already translated into FRs (1)
To limit resources (1)
Missing guideline (1)
Tooling limita9ons (1)
Compliance to customer constraints (1)
There is no difference (2)
Different Priority (1)
Separa9on results in redesigns in late project phases (1)
General & Project Organiza2on
RE
Valida2on & Verifica2on
Design & Implementa2on
Increased awareness of QRs (2)
Cohesive documents (1)
No addi9onal training required (1)
Avoids late redesign (1)
More freedom in the imply. of QRs (1)
More comprehensive tests (2)
General & Project Organiza2on
RE
Valida2on & Verifica2on
Design & Implementa2on
Decreased product quality (1)
Tracing becomes expensive (1)
Focus too much on FRs (1)
Customer specifies unfeasible QRs (1)
QRs are unfeasible (1)
Missing V&V for QRs (1)
No distinction btw
QRs and FRs
Reqs. already on a detailed level (1)
No addi9onal training required (1)
No distinction between QRs and FRs

15. General & Project Organiza2on
RE
Design & Implementa2on
Valida2on & Verifica2on
QRs are already translated into FRs (1)
To limit resources (1)
Missing guideline (1)
Tooling limita9ons (1)
Compliance to customer constraints (1)
There is no difference (2)
Different Priority (1)
Separa9on results in redesigns in late project phases (1)
General & Proje
Increased awareness of QRs (2)
Cohesive documents (1)
No addi9onal training required (1)
Mo
General & Proje
Decreased product quality (1)
Tracing becomes expensive (1)
Focus too much on FRs (1)
Custo
No distinction btw
QRs and FRs
Reqs. already on a detailed level (1)

16. RE
n
on & Verifica2on
erent Priority (1)
General & Project Organiza2on
RE
Valida2on & Verifica2on
Design & Implementa2on
Increased awareness of QRs (2)
Cohesive documents (1)
No addi9onal training required (1)
Avoids late redesign (1)
More freedom in the imply. of QRs (1)
More comprehensive tests (2)
General & Project Organiza2on
RE
Valida2on & Verifica2on
Design & Implementa2on
Decreased product quality (1)
Tracing becomes expensive (1)
Focus too much on FRs (1)
Customer specifies unfeasible QRs (1)
QRs are unfeasible (1)
Missing V&V for QRs (1)
No distinction btw
QRs and FRs
No addi9onal training required (1)

17. Some observations
Reasoning not clear
» Contrary arguments
“Both are requirements” versus
“[they] are different”
» Same line of reasoning
“increase awareness” by
distinguishing and by not
distinguishing QRs and FRs
Heterogenous, extrinsic
decision drivers
» Lack of guidance
“There is no real guidelines how to do it”
» Enforced guidance
“[…] as requested by customer”,“Our
specification template prescribes […]”
» Unclear difference in practice
“Most people have problems to
distinguish them, so they mix”
Unclear decision implications
» Impact on testing
Distinguishing leads to more
specialised tests, but also to not
testing them at all
» (potential) Conventional wisdom
Arguments from literature not
underpinned by consequences

18. Take-Aways
Reasoning not clear
» Contrary arguments
“Both are requirements” versus
“[they] are different”
» Same line of reasoning
“increase awareness” by
distinguishing and by not
distinguishing QRs and FRs
What we have
conventional wisdom
reasoning based on norms
Heterogenous, extrinsic
decision drivers
» Lack of guidance
“There is no real guidelines how to do it”
» Enforced guidance
“[…] as requested by customer”,“Our
specification template prescribes […]”
» Unclear difference in practice
“Most people have problems to
distinguish them, so they mix”
Unclear decision implications» Impact on testing Distinguishing leads to more
specialised tests, but also to not
testing them at all» (potential) Conventional wisdom
Arguments from literature not
underpinned by consequences
What we lack
evidence

19. Takk!
Daniel Méndez
Daniel.Mendez@tum.de
@mendezfe
Approach me if you need material
(study details & raw data)
Future work
Increase understanding about
• implications of (not) distinguishing QRs from FRs
• where preconceptions emerge from
➡ Contribute to testable theories in RE to debunk “(RE) Leprechauns”