In Quest of Requirements Engineering Research that Industry Needs
•
3 likes•957 views
Keynote given at the 21st Ibero-American Conference on Software Engineering in Bogota, Colombia
Recommended
Recommended
More Related Content
What's hot
What's hot (14)
Similar to In Quest of Requirements Engineering Research that Industry Needs
Similar to In Quest of Requirements Engineering Research that Industry Needs (20)
More from Daniel Mendez
More from Daniel Mendez (11)
Recently uploaded
Recently uploaded (20)
In Quest of Requirements Engineering Research that Industry Needs
- 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
- 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. 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. The Year 1977
- 17. “There is a demon in the bottle.”
- 18. Today
- 20. [2] Quick and simple Google search [1] http://www.dw.com/en/germany-seeks-toll-collect-compensation/a-1324248
- 21. 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)
- 22. “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/
- 23. 33% … of errors happen in RE. M. Hamill and G.-P. Katerina. Common Trends in Software Fault and Failure Data, IEEE TSE, 2009.
- 24. 36% … of errors in RE lead to project failure. Naming the Pain in Requirements Engineering Initiative; www.re-survey.org
- 25. Why do we still have so many problems?
- 26. Image Source (left): https://upload.wikimedia.org/wikipedia/commons/7/70/Apple-II.jpg
- 27. RE
- 28. 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
- 29. Key question How can we foster research that industry needs?
- 30. Key question How can we foster research that industry needs? This is a recognised problem
- 31. 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.
- 32. 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.
- 33. Goal-oriented Requirements Engineering (Example to be taken with a grain of salt)
- 34. 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
- 35. 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
- 36. 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
- 37. 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
- 38. 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)
- 39. 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%
- 40. “[…] 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
- 41. 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
- 42. Consequences » Practical relevance and impact? » Potential for transfer into practice and adoption?
- 43. 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.
- 44. 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.
- 46. 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
- 47. ‣ 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
- 48. ‣ 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
- 49. ‣ 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
- 50. 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
- 51. 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
- 53. In scope of artefact-based standard (reference) models
- 54. In scope of artefact-based standard (reference) models
- 55. 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
- 56. ) 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
- 57. 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%)
- 58. 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.
- 59. 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
- 60. 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?
- 61. 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?
- 62. 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?
- 63. 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
- 64. 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
- 65. How can you make use of this initiative?
- 66. 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?
- 68. How can you contribute to such initiatives?
- 69. 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
- 70. 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
- 71. 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.
- 72. 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?
- 73. 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
- 75. 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)
- 76. 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)
- 77. 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
- 78. 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
- 79. 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.”
- 80. 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
- 81. 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.”
- 82. 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.
- 83. In Quest for RE Research that Industry Needs ‣ Change from conventional wisdom to theory-centric, context-sensitive RE
- 84. 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
- 85. 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
- 86. 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
- 87. 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!