On the Distinction of Functional and Quality Requirements in Practice
0 likes589 views
The document presents results from a survey of 103 practitioners regarding their handling of functional requirements (FRs) versus quality requirements (QRs). Key findings include: 1) Most practitioners document QRs separately from FRs, but some do not distinguish between the two. 2) Reasons for distinguishing include different nature/stakeholders of QRs, influence on architecture/testing, while reasons for not distinguishing include guidance/tool limitations and seeing no difference. 3) Potential benefits of distinguishing include focused design/testing and increased QR awareness, while drawbacks include increased effort and potential neglect of QRs.
![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](https://image.slidesharecdn.com/frnfrprofes-161123103238/85/On-the-Distinction-of-Functional-and-Quality-Requirements-in-Practice-9-320.jpg)
![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](https://image.slidesharecdn.com/frnfrprofes-161123103238/85/On-the-Distinction-of-Functional-and-Quality-Requirements-in-Practice-17-320.jpg)
![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](https://image.slidesharecdn.com/frnfrprofes-161123103238/85/On-the-Distinction-of-Functional-and-Quality-Requirements-in-Practice-18-320.jpg)
On the Distinction of Functional and Quality Requirements in Practice
- 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
- 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”