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. Munich
Image Source: http://www.heimarbeit.de/wp-content/uploads/2015/09/TU-Munchen.jpg

3. Munich
Image Source: http://www.heimarbeit.de/wp-content/uploads/2015/09/TU-Munchen.jpg
Alps

4. Munich
Frauenkirche
Image Source: http://www.heimarbeit.de/wp-content/uploads/2015/09/TU-Munchen.jpg
Alps

5. Munich
Frauenkirche
Image Source: http://www.heimarbeit.de/wp-content/uploads/2015/09/TU-Munchen.jpg
TUM
Alps

6. Munich
Frauenkirche
Image Source: http://www.heimarbeit.de/wp-content/uploads/2015/09/TU-Munchen.jpg
TUM
Industry
Alps
Industry
Industry

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. 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

19. [1] http://www.dw.com/en/germany-seeks-toll-collect-compensation/a-1324248

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?

67. Phenomena and measurements

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!