Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

On the Distinction of Functional and Quality Requirements in Practice

367 views

Published on

Talk given at the 17th Int. Conference on Product-Focused Software Process Improvement

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

On the Distinction of Functional and Quality Requirements in Practice

  1. 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)
  2. 2. 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.
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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%
  8. 8. 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
  9. 9. 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?
  10. 10. 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
  11. 11. 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)
  12. 12. 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)
  13. 13. 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
  14. 14. 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)
  15. 15. 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)
  16. 16. 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
  17. 17. 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
  18. 18. 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”

×