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.

In Quest of Requirements Engineering Research that Industry Needs

573 views

Published on

Keynote given at the 21st Ibero-American Conference on Software Engineering in Bogota, Colombia

Published in: Engineering
  • Hello! High Quality And Affordable Essays For You. Starting at $4.99 per page - Check our website! https://vk.cc/82gJD2
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

In Quest of Requirements Engineering Research that Industry Needs

  1. 1. In Quest of 
 Requirements Engineering Research 
 that Industry needs Daniel Méndez Technical University of Munich , Germany www.mendezfe.org @mendezfe CibSE WER 2018 Bogotá, Colombia
  2. 2. Munich Image Source: http://www.heimarbeit.de/wp-content/uploads/2015/09/TU-Munchen.jpg
  3. 3. Munich Image Source: http://www.heimarbeit.de/wp-content/uploads/2015/09/TU-Munchen.jpg Alps
  4. 4. Munich Frauenkirche Image Source: http://www.heimarbeit.de/wp-content/uploads/2015/09/TU-Munchen.jpg Alps
  5. 5. Munich Frauenkirche Image Source: http://www.heimarbeit.de/wp-content/uploads/2015/09/TU-Munchen.jpg TUM Alps
  6. 6. Munich Frauenkirche Image Source: http://www.heimarbeit.de/wp-content/uploads/2015/09/TU-Munchen.jpg TUM Industry Alps Industry Industry
  7. 7. Image Source: https://www.hindustantimes.com/photos/world-news/photos-oktoberfest-2017-world-s-biggest-beer-binge-begins-in-munich/photo-6zlNI1zD5gr6hHTSDfYe8K.html
  8. 8. In Quest of 
 Requirements Engineering Research 
 that Industry needs Daniel Méndez Technical University of Munich, Germany www.mendezfe.org @mendezfe CibSE WER 2018 Bogotá, Colombia
  9. 9. copy, share and change, film and photograph, blog, live-blog and tweet this presentation given that you attribute it to its author and respect the rights and licenses of its parts. Based on slides by @SMEasterbrook and @ethanwhite You can…
  10. 10. The Year 1977
  11. 11. “There is a demon in the bottle.”
  12. 12. Today
  13. 13. [1] http://www.dw.com/en/germany-seeks-toll-collect-compensation/a-1324248
  14. 14. [2] Quick and simple Google search [1] http://www.dw.com/en/germany-seeks-toll-collect-compensation/a-1324248
  15. 15. In 2016 alone … https://www.tricentis.com/resource-assets/software-fail-watch-2016/ # 548 publicly reported failures $ 1.1 trillion impact in assets 4.4 billion people affected
 (Amounts to over 50% of world’s population)
  16. 16. “The serious problems that have happened with software have to do with requirements, not coding errors.” — Nancy Leveson https://www.theatlantic.com/technology/archive/2017/09/saving-the-world-from-code/540393/
  17. 17. 33% … of errors happen in RE. M. Hamill and G.-P. Katerina. Common Trends in Software Fault and Failure Data, IEEE TSE, 2009.
  18. 18. 36% … of errors in RE lead to project failure. Naming the Pain in Requirements Engineering Initiative; www.re-survey.org
  19. 19. Why do we still have so many problems?
  20. 20. Image Source (left): https://upload.wikimedia.org/wikipedia/commons/7/70/Apple-II.jpg
  21. 21. RE
  22. 22. Yet, many of our contributions ‣ pretend to be universal, ‣ address problems not well understood, and/or ‣ remain unknown. There is a gap between research and practice RE
  23. 23. Key question How can we foster research that 
 industry needs?
  24. 24. Key question How can we foster research that 
 industry needs? This is a recognised problem
  25. 25. In Quest for RE Research that Industry Needs ‣Turn RE into a theory-centric discipline … to eradicate the many Leprechauns we still have. ‣Understand practitioners’ problems … to foster problem-driven research. ‣Engage in academia-industry collaborations … to analyse problems in their natural environment and frame our work.
  26. 26. In Quest for RE Research that Industry Needs ‣Turn RE into a theory-centric discipline … to eradicate the many Leprechauns we still have. ‣Understand practitioners’ problems … to foster problem-driven research. ‣Engage in academia-industry collaborations … to analyse problems in their natural environment and frame our work.
  27. 27. Goal-oriented Requirements Engineering (Example to be taken with a grain of salt)
  28. 28. Goal-oriented Requirements Engineering (Example to be taken with a grain of salt) Papers published [1]: 966 [1] Horkoff et al. Goal-Oriented Requirements Engineering: A Systematic Literature Map, 2016
  29. 29. Goal-oriented Requirements Engineering (Example to be taken with a grain of salt) Papers published [1]: 966 [1] Horkoff et al. Goal-Oriented Requirements Engineering: A Systematic Literature Map, 2016 Papers cited at least 3 times: 246
  30. 30. Goal-oriented Requirements Engineering (Example to be taken with a grain of salt) Papers published [1]: 966 [1] Horkoff et al. Goal-Oriented Requirements Engineering: A Systematic Literature Map, 2016 Papers cited at least 3 times: 246 Cited papers including “case study”: 131
  31. 31. Goal-oriented Requirements Engineering (Example to be taken with a grain of salt) Papers published [1]: 966 [2] Mavin, et al. Does Goal-Oriented Requirements Engineering Achieve its Goal?, 2017 [1] Horkoff et al. Goal-Oriented Requirements Engineering: A Systematic Literature Map, 2016 Papers cited at least 3 times: 246 Cited papers including “case study”: 131 Actual in-vivo case studies [2]: 20
  32. 32. Goal-oriented Requirements Engineering (Example to be taken with a grain of salt) Papers published [1]: 966 [2] Mavin, et al. Does Goal-Oriented Requirements Engineering Achieve its Goal?, 2017 [3] Mendez et al. Naming the Pain in Requirements Engineering Initiative - www.re-survey.org, 2014/15 [1] Horkoff et al. Goal-Oriented Requirements Engineering: A Systematic Literature Map, 2016 Papers cited at least 3 times: 246 Cited papers including “case study”: 131 Actual in-vivo case studies [2]: 20 Practitioners actually using GORE [3]: ~ 5%
 (among 228 companies surveyed)
  33. 33. Goal-oriented Requirements Engineering (Example to be taken with a grain of salt) Papers published [1]: 966 [2] Mavin, et al. Does Goal-Oriented Requirements Engineering Achieve its Goal?, 2017 [3] Mendez et al. Naming the Pain in Requirements Engineering Initiative - www.re-survey.org, 2014/15 [1] Horkoff et al. Goal-Oriented Requirements Engineering: A Systematic Literature Map, 2016 Papers cited at least 3 times: 246 Cited papers including “case study”: 131 Actual in-vivo case studies [2]: 20 Practitioners actually using GORE [3]: ~ 5%
 (among 228 companies surveyed) For comparison: Icelanders believing in elves [1]: [1] https://www.nationalgeographic.com/travel/destinations/ europe/iceland/believes-elves-exist-mythology/ 54%
  34. 34. “[…] judging a theory by assessing the number, faith, and vocal energy of its supporters […] basic political credo of contemporary religious maniacs” — Imre Lakatos, 1970 Current state of evidence in RE is weak * Addressing the situation in the quantum mechanics research community, an analogy
  35. 35. RE largely dominated by conventional wisdom Reasons are manifold: • Lack of empirical awareness • Neglecting particularities of practical contexts • Neglecting relation to existing evidence • Treating claims by authorities 
 as facts • … • Lack of data
  36. 36. Consequences » Practical relevance and impact? » Potential for transfer into practice and adoption?
  37. 37. Key Take-Away We*need to change from… •conventional wisdom •universal solutions …to… •evidence-based, theory-centric •context-sensitive …Requirements Engineering research * Everyone’s responsibility: 
 We as authors, reviewers, organisers, and educators.
  38. 38. In Quest for RE Research that Industry Needs ‣Turn RE into a theory-centric discipline … to eradicate the many Leprechauns we still have. ‣Understand practitioners’ problems … to foster problem-driven research. ‣Engage in academia-industry collaborations … to analyse problems in their natural environment and frame our work.
  39. 39. Goals ‣ First theory on industrial practices and problems 
 in Requirements Engineering ‣ Open Data Foundation for problem-driven research www.re-survey.org Naming the Pain in Requirements Engineering NaPiRE
  40. 40. ‣ Bi-yearly replicated, 
 globally distributed family of surveys ‣ Collaborative design, analysis 
 and synthesis 2017/18 25 countries 61 researchers from 53 institutions 2014/15 10 countries 23 researchers 2011/12 1 country, 2 researchers www.re-survey.org Naming the Pain in Requirements Engineering NaPiRE
  41. 41. ‣ Bi-yearly replicated, 
 globally distributed family of surveys ‣ Collaborative design, analysis 
 and synthesis 2017/18 25 countries 61 researchers from 53 institutions 2014/15 10 countries 23 researchers www.re-survey.org Naming the Pain in Requirements Engineering NaPiRE
  42. 42. ‣ Bi-yearly replicated, 
 globally distributed family of surveys ‣ Collaborative design, analysis 
 and synthesis 2017/18 25 countries 61 researchers from 53 institutions www.re-survey.org Naming the Pain in Requirements Engineering NaPiRE
  43. 43. Status quo in practices used ‣ Requirements Elicitation ‣ Requirements Documentation ‣ Requirements Change and Alignment ‣ Requirements Engineering Standards ‣ Requirements Engineering Improvement Problems in RE ‣ Problems and criticality ‣ Causes ‣ Effects Req Elicitation Technique Interview Scenario Prototyping Facilitated Meetings Observation Req Documentation Technique Structured req list Domain/business process model Use case model Goal model Data model Non-functional req Textual Semi-formal Formal Technology Req Test Alignment Approach Req review by tester Coverage by tests Acceptance criteria Test derivation from models Req Change Approach Product backlog update Change requests Trace management Impact analysis Activity Req Elicitation Req Documentation Req Change Management Req Test Alignment P 1-5 P 6-13 P 14-20 P 21-24 Actor Req Engineer Test Engineer Req Standard Application Practice Control Tailoring Req Eng Process Standard P 25-28 Req Standard Defintion Compliance Development Tool support Quality assurance Project management Knowledge transfer Process complexity Communication demand Willigness to change Possibility of standardisation P 26-45 Req Improvement Means Continuous improvement Strengths/weaknesses Own business unit/role Req Eng ImprovementP 46--48 Results from NaPiRE 2015/16 ‣ 10 countries, 228 companies
  44. 44. Status quo in practices used ‣ Requirements Elicitation ‣ Requirements Documentation ‣ Requirements Change and Alignment ‣ Requirements Engineering Standards ‣ Requirements Engineering Improvement Problems in RE ‣ Problems and criticality ‣ Causes ‣ Effects Mendez et al. Naming the pain in requirements engineering Contemporary problems, causes, and effects in practice, EMSE Journal 2017 Req Elicitation Technique Interview Scenario Prototyping Facilitated Meetings Observation Req Documentation Technique Structured req list Domain/business process model Use case model Goal model Data model Non-functional req Textual Semi-formal Formal Technology Req Test Alignment Approach Req review by tester Coverage by tests Acceptance criteria Test derivation from models Req Change Approach Product backlog update Change requests Trace management Impact analysis Activity Req Elicitation Req Documentation Req Change Management Req Test Alignment P 1-5 P 6-13 P 14-20 P 21-24 Actor Req Engineer Test Engineer Req Standard Application Practice Control Tailoring Req Eng Process Standard P 25-28 Req Standard Defintion Compliance Development Tool support Quality assurance Project management Knowledge transfer Process complexity Communication demand Willigness to change Possibility of standardisation P 26-45 Req Improvement Means Continuous improvement Strengths/weaknesses Own business unit/role Req Eng ImprovementP 46--48 Results from NaPiRE 2015/16 ‣ 10 countries, 228 companies
  45. 45. In scope of artefact-based standard (reference) models
  46. 46. In scope of artefact-based standard (reference) models
  47. 47. Unclear roles and responsabilities at customer side Weak qualification of RE team members Subjective interpretations Stakeholders lack business vision and understanding (1.28%) Customer does not know what he wants (6.41%) Lack of experience of RE team members Complexity of domain Insufficient resources Lack of time Conflicting stakeholder viewpoints (8.97%) Strict time schedule by customer Missing req. specification template Missing IT project experience at customer side Weak qualification of stakeholders (6.41%) Input (33%) (3.85%) (6.41%) (2.56%) (1.28% ) (1.28%) (1.28%) (2.56%) (10.26 %) (2.56%) (2.56%) (1.28%) (1.28%)(1.28%) (1.10%) Method (38%) Req. too abstract Missing completeness check of requirements Insufficient agility Communication flaws between team and customer Lack of a well-defined RE process Complexity of RE Unclear terminology (11.54%) (1.28%)(1.28%) (2.56%) (2.56%) (1.28%) (1.28%) People (17%) Tools (3%) (1.28%) Communication flaws customer Missing engagement by customer Missing customer involvement (2.56%) (1.28%) (1.28%) Policy restrictions (1.28%) (1.28%) Missing RE awareness at customer side (1.28%) Weak management at customer side (1.28%) Missing direct communication to customer Missing involvement of dev. (2.56%) Poor project management Missing solution approach Organization (9%) Too high team distribution Many customer s Language Barriers Not following the communication plan Missing tool support(1.28%) Customer (19%) Design or Implementation (9%) Product (22%) Validation or Verification (3%) Increased number of req. changes (16.18%) Incomplete Req. (2.94% ) Decreased user acceptance Customer dissatisfaction (2.94%) Need for post implementation Poor product quality Decreased business value (10.29%) (8.82%) (2.94%) Increased communication Implementation of irrelevant req. Effort overrun Time overrun Budget overrun Decreased efficiency (overall) Increased number of change requests Wrong estimates Increased difficulty of req. elicitation Validation of req. becomes difficult Project or Organization (47%) (2.94%) (1.47%) (13.24%) (5.88%) (4.41%) (2.94%)(2.94%) (2.94%) (1.47%) (1.47%) (1.47%) (1.47%) (2.94%) Poor (system) design quality (1.47%) Misunderstanding (overall) Late decision (2.94%) (2.94%) (2.94%) Overall demotivation Information gets lost Increased complexity in RE
  48. 48. ) Communication flaws customer Customer (19%) Design or Implementation (9%) Product (22%) Validation or Verification (3%) Increased number of req. changes (16.18%) Incomplete Req. (2.94% ) Decreased user acceptance Customer dissatisfaction (2.94%) Need for post implementation Poor product quality Decreased business value (10.29%) (8.82%) (2.94%) Increased communication Implementation of irrelevant req. Effort overrun Time overrun Budget overrun Decreased efficiency (overall) Increased number of change requests Wrong estimates Increased difficulty of req. elicitation Validation of req. becomes difficult Project or Organization (47%) (2.94%) (1.47%) (13.24%) (5.88%) (4.41%) (2.94%)(2.94%) (2.94%) (1.47%) (1.47%) (1.47%) (1.47%) (2.94%) Poor (system) design quality (1.47%) Misunderstanding (overall) Late decision (2.94%) (2.94%) (2.94%) Overall demotivation Information gets lost Increased complexity in RE
  49. 49. Unclear roles and responsabilities at customer side Weak qualification of RE team members Subjective interpretations Stakeholders lack business vision and understanding (1.28%) Customer does not know what he wants (6.41%) Lack of experience of RE team members Complexity of domain Insufficient resources Lack of time Conflicting stakeholder viewpoints (8.97%) Strict time schedule by customer Missing req. specification template Missing IT project experience at customer side Weak qualification of stakeholders (6.41%) Input (33%) (3.85%) (6.41%) (2.56%) (1.28% ) (1.28%) (1.28%) (2.56%) (10.26 %) (2.56%) (2.56%) (1.28%) (1.28%)(1.28%) (1.10%) Method (38%) Req. too abstract Missing completeness check of requirements Insufficient agility Communication flaws between team and customer Lack of a well-defined RE process Complexity of RE Unclear terminology (11.54%) (1.28%)(1.28%) (2.56%) (2.56%) (1.28%) (1.28%) People (17%) Tools (3%) (1.28%) Communication flaws customer Missing engagement by customer Missing customer involvement (2.56%) (1.28%) (1.28%) Policy restrictions (1.28%) (1.28%) Missing RE awareness at customer side (1.28%) Weak management at customer side (1.28%) Missing direct communication to customer Missing involvement of dev. (2.56%) Poor project management Missing solution approach Organization (9%) Too high team distribution Many customer s Language Barriers Not following the communication plan Missing tool support(1.28%)
  50. 50. Unclear roles and responsabilities at customer side Weak qualification of RE team members Subjective interpretations Stakeholders lack business vision and understanding (1.28%) Customer does not know what he wants (6.41%) Lack of experience of RE team members Complexity of domain Insufficient resources Lack of time Conflicting stakeholder viewpoints (8.97%) Strict time schedule by customer Missing req. specification template Missing IT project experience at customer side Weak qualification of stakeholders (6.41%) Input (33%) (3.85%) (6.41%) (2.56%) (1.28% ) (1.28%) (1.28%) (2.56%) (10.26 %) (2.56%) (2.56%) (1.28%) (1.28%)(1.28%) (1.10%) Method (38%) Req. too abstract Missing completeness check of requirements Insufficient agility Communication flaws between team and customer Lack of a well-defined RE process Complexity of RE Unclear terminology (11.54%) (1.28%)(1.28%) (2.56%) (2.56%) (1.28%) (1.28%) People (17%) Tools (3%) (1.28%) Communication flaws customer Missing engagement by customer Missing customer involvement (2.56%) (1.28%) (1.28%) Policy restrictions (1.28%) (1.28%) Missing RE awareness at customer side (1.28%) Weak management at customer side (1.28%) Missing direct communication to customer Missing involvement of dev. (2.56%) Poor project management Missing solution approach Organization (9%) Too high team distribution Many customer s Language Barriers Not following the communication plan Missing tool support(1.28%) Causes rather not due to missing guidance via reference models, but due to organisational and even social issues.
  51. 51. Do teams applying agile practices avoid these issues? Unclear roles and responsabilities at customer side Weak qualification of RE team members Subjective interpretations Stakeholders lack business vision and understanding (1.28%) Customer does not know what he wants (6.41%) Lack of experience of RE team members Complexity of domain Insufficient resources Lack of time Conflicting stakeholder viewpoints (8.97%) Strict time schedule by customer Missing req. specification template Missing IT project experience at customer side Weak qualification of stakeholders (6.41%) Input (33%) (3.85%) (6.41%) (2.56%) (1.28% ) (1.28%) (1.28%) (2.56%) (10.26 %) (2.56%) (2.56%) (1.28%) (1.28%)(1.28%) (1.10%) Method (38%) Req. too abstract Missing completeness check of requirements Insufficient agility Communication flaws between team and customer Lack of a well-defined RE process Complexity of RE Unclear terminology (11.54%) (1.28%)(1.28%) (2.56%) (2.56%) (1.28%) (1.28%) People (17%) Tools (3%) (1.28%) Communication flaws customer Missing engagement by customer Missing customer involvement (2.56%) (1.28%) (1.28%) Policy restrictions (1.28%) (1.28%) Missing RE awareness at customer side (1.28%) Weak management at customer side (1.28%) Missing direct communication to customer Missing involvement of dev. (2.56%) Poor project management Missing solution approach Organization (9%) Too high team distribution Many customer s Language Barriers Not following the communication plan Missing tool support(1.28%) Customer (19%) Design or Implementation (9%) Product (22%) Validation or Verification (3%) Increased number of req. changes (16.18%) Incomplete Req. (2.94% ) Decreased user acceptance Customer dissatisfaction (2.94%) Need for post implementation Poor product quality Decreased business value (10.29%) (8.82%) (2.94%) Increased communication Implementation of irrelevant req. Effort overrun Time overrun Budget overrun Decreased efficiency (overall) Increased number of change requests Wrong estimates Increased difficulty of req. elicitation Validation of req. becomes difficult Project or Organization (47%) (2.94%) (1.47%) (13.24%) (5.88%) (4.41%) (2.94%)(2.94%) (2.94%) (1.47%) (1.47%) (1.47%) (1.47%) (2.94%) Poor (system) design quality (1.47%) Misunderstanding (overall) Late decision (2.94%) (2.94%) (2.94%) Overall demotivation Information gets lost Increased complexity in RE
  52. 52. Small companies
 (1-50) Medium companies
 (51-250) Large companies
 (> 251) #1 Problem Incomplete/hidden requirements Communication flaws customer
 Incomplete/hidden requirements #2 Problem Communication flaws customer
 Incomplete/hidden requirements Moving targets #3 Problem Underspecified requirements Communication flaws project team Communication flaws customer
 #4 Problem Communication flaws project team
 Separation reqs. / solutions Time boxing #5 Problem Time boxing Weak access customer needs Underspecified requirements Do teams applying agile practices avoid these issues?
  53. 53. Small companies
 (1-50) Medium companies
 (51-250) Large companies
 (> 251) #1 Problem Incomplete/hidden requirements Communication flaws customer
 Incomplete/hidden requirements #2 Problem Communication flaws customer
 Incomplete/hidden requirements Moving targets #3 Problem Underspecified requirements Communication flaws project team Communication flaws customer
 #4 Problem Communication flaws project team
 Separation reqs. / solutions Time boxing #5 Problem Time boxing Weak access customer needs Underspecified requirements No. Do teams applying agile practices avoid these issues?
  54. 54. Small companies
 (1-50) Medium companies
 (51-250) Large companies
 (> 251) #1 Problem Incomplete/hidden requirements Communication flaws customer
 Incomplete/hidden requirements #2 Problem Communication flaws customer
 Incomplete/hidden requirements Moving targets #3 Problem Underspecified requirements Communication flaws project team Communication flaws customer
 #4 Problem Communication flaws project team
 Separation reqs. / solutions Time boxing #5 Problem Time boxing Weak access customer needs Underspecified requirements Not at all. Do teams applying agile practices avoid these issues?
  55. 55. Small companies
 (1-50) Medium companies
 (51-250) Large companies
 (> 251) #1 Problem Incomplete/hidden requirements Communication flaws customer
 Incomplete/hidden requirements #2 Problem Communication flaws customer
 Incomplete/hidden requirements Moving targets #3 Problem Underspecified requirements Communication flaws project team Communication flaws customer
 #4 Problem Communication flaws project team
 Separation reqs. / solutions Time boxing #5 Problem Time boxing Weak access customer needs Underspecified requirements “Insufficient RE” is too manifold to be avoided via 
 universal solutions
  56. 56. Small companies
 (1-50) Medium companies
 (51-250) Large companies
 (> 251) #1 Problem Incomplete/hidden requirements Communication flaws customer
 Incomplete/hidden requirements #2 Problem Communication flaws customer
 Incomplete/hidden requirements Moving targets #3 Problem Underspecified requirements Communication flaws project team Communication flaws customer
 #4 Problem Communication flaws project team
 Separation reqs. / solutions Time boxing #5 Problem Time boxing Weak access customer needs Underspecified requirements “Insufficient RE” is too manifold to be avoided via 
 universal solutions Context Causes Problems Effects
  57. 57. How can you make use of this initiative?
  58. 58. Open data repository www.re-survey.org Problem-driven research supports ‣ Make use of the NaPiRE results and data How can you make use of this initiative?
  59. 59. Phenomena and measurements
  60. 60. How can you contribute to such initiatives?
  61. 61. How can you contribute to such initiatives? ‣ Join existing initiatives, e.g. ‣ Understanding practitioners’ problems ‣ Understanding relevance of available RE Research and topics of interest to practitioners ‣ Kick off new community initiatives ‣ Share your own empirical data
  62. 62. Key Take-Away Only a shared understanding of •RE practices and problems •context factors supports problem-driven research Joint open data initiatives are key in our community to: » strengthen shared body of knowledge » establish common references for evaluation research
  63. 63. In Quest for RE Research that Industry Needs ‣Turn RE into a theory-centric discipline … to eradicate the many Leprechauns we still have. ‣Understand practitioners’ problems … to foster problem-driven research. ‣Engage in academia-industry collaborations … to analyse problems in their natural environment and frame our work.
  64. 64. Academia-Industry collaborations •Academia-Industry collaborations can form a great environment to frame research that cannot otherwise be conducted in the lab … but what are the success factors?
  65. 65. Academia-Industry collaborations •Academia-Industry collaborations can form a great environment to frame research that cannot otherwise be conducted in the lab … but what are the success factors? A research area of its own
  66. 66. 1. How do you remember our research collaboration? 2. Which effects did our work have in the long-run? 3. If you could name one important factor for academia- industry collaborations, which would it be? Joint work with @twinkleflip (Birgit Penzenstadler)
  67. 67. 1. How do you remember our research collaboration? 2. Which effects did our work have in the long-run? 3. If you could name one important factor for academia- industry collaborations, which would it be? Joint work with @twinkleflip (Birgit Penzenstadler)
  68. 68. Success factors for collaborations with industry
 (Least common denominator of practitioners’ voices) 1. Shared long-term vision and project goals 2. Common problem- and domain-understanding 3. Proper project organisation ‣ Manageable-sized sub-problems ‣ Minimal-invasive solutions ‣ Regular on-site work and meetings ‣ Fast feedback loops 4. Proper mindset and principles
  69. 69. Success factors for collaborations with industry
 (Least common denominator of practitioners’ voices) 1. Shared long-term vision and project goals 2. Common problem- and domain-understanding 3. Proper project organisation ‣ Manageable-sized sub-problems ‣ Minimal-invasive solutions ‣ Regular on-site work and meetings ‣ Fast feedback loops 4. Proper mindset and principles
  70. 70. Success factors for collaborations with industry
 (Least common denominator of practitioners’ voices) 1. Shared long-term vision and project goals 2. Common problem- and domain-understanding 3. Proper project organisation ‣ Manageable-sized sub-problems ‣ Minimal-invasive solutions ‣ Regular on-site work and meetings ‣ Fast feedback loops 4. Proper mindset and principles “Academic mindset with a 
‘Free-as-a-bird’-mentality.” “Pragmatism […] free of idealism when solving industry problems.”
  71. 71. Success factors for collaborations with industry
 (Least common denominator of practitioners’ voices) 1. Shared long-term vision and project goals 2. Common problem- and domain-understanding 3. Proper project organisation ‣ Manageable-sized sub-problems ‣ Minimal-invasive solutions ‣ Regular on-site work and meetings ‣ Fast feedback loops 4. Proper mindset and principles “Academic mindset with a 
‘Free-as-a-bird’-mentality.” “Pragmatism […] free of idealism when solving industry problems.” Partner with 
 academic background Partner with no 
 academic background
  72. 72. Key Take-Away •Academia-Industry collaborations can form a great environment to frame research that cannot otherwise be conducted in the lab … but there is a fine line between
 applied research and (cheap) consultancy “Academic mindset with a 
‘Free-as-a-bird’-mentality.” “Pragmatism […] free of idealism when solving industry problems.”
  73. 73. In Quest for RE Research that Industry Needs ‣Turn RE into a theory-centric discipline … to eradicate the many Leprechauns we still have. ‣Understand practitioners’ problems … to foster problem-driven research. ‣Engage in academia-industry collaborations
 … to analyse problems in their natural environment and frame our work.
  74. 74. In Quest for RE Research that Industry Needs ‣ Change from conventional wisdom 
 to theory-centric, context-sensitive RE
  75. 75. In Quest for RE Research that Industry Needs ‣ Change from conventional wisdom 
 to theory-centric, context-sensitive RE ‣ Unlock our data to support a shared understanding on practical problems
  76. 76. In Quest for RE Research that Industry Needs ‣ Change from conventional wisdom 
 to theory-centric, context-sensitive RE ‣ Unlock our data to support a shared understanding on practical problems ‣ Engage in academia-industry collaborations to frame our research while preserving our academic integrity
  77. 77. In Quest for RE Research that Industry Needs ‣ Change from conventional wisdom 
 to theory-centric, context-sensitive RE ‣ Unlock our data to support a shared understanding on practical problems ‣ Engage in academia-industry collaborations to frame our research while preserving our academic integrity LAST BUT NOT LEAST For a successful dissemination of RE research into practice, it still needs “two to tango”[1] Even though sometimes people want to make you believe that industry needs are the sole measure of success, they are clearly not. [1] Runesen, P. It Takes Two to Tango -- An Experience Report on Industry -- Academia Collaboration, 2012 1 2
  78. 78. In Quest for RE Research that Industry Needs ‣ Change from conventional wisdom 
 to theory-centric, context-sensitive RE ‣ Unlock our data to support a shared understanding on practical problems ‣ Engage in academia-industry collaborations to frame our research while preserving our academic integrity Thank you!

×