=Paper=
{{Paper
|id=Vol-1564/paper30
|storemode=property
|title=Requirements Engineering in Open Innovation
|pdfUrl=https://ceur-ws.org/Vol-1564/paper30.pdf
|volume=Vol-1564
|authors=Johan Linåker
|dblpUrl=https://dblp.org/rec/conf/refsq/Linaker16
}}
==Requirements Engineering in Open Innovation==
https://ceur-ws.org/Vol-1564/paper30.pdf
Requirements Engineering in Open Innovation
Johan Linåker
Lund University, Lund, Sweden
johan.linaker@cs.lth.se
Abstract. During the last two decades a slow but steady change of external fac-
tors has set-up new conditions affecting the way in how software producing firms
create and leverage innovations. Firms now need to look outside of their bound-
aries and start interacting with the open environment that encompasses them in
order to stay innovative and keep a competitive advantage. To facilitate this shift
Requirements Engineering needs to consider the increase and complexity of new
requirements sources as well as networks of stakeholders. Based on the research
agenda described in this paper we expect to make a contribution by establish-
ing guidelines and tools for how Requirements Engineering should be adapted to
cope with possible challenges implied by Open Innovation, foremost in the areas
requirements selection and decision making when using Open Source Software
as a way to leverage Open Innovation.
Keywords: requirements engineering, open source software, open innovation
1 Introduction
The emergence of Open Source Software (OSS) and its pivotal part in many firms’ busi-
ness models in later years has opened up software-intensive firms to an earlier unex-
posed environment of challenges and opportunities [1, 2]. This is further explicated by
the paradigm of Open Innovation (OI), which highlights how firms should strive to look
beyond their own borders for resources that may advance their internal innovation and
technology capabilities [3]. Conversely, consideration should also be taken to how they
can profit from exploiting internal unutilized IPR together with resources outside of
the firm. As a consequence, firms’ borders become permeable for interaction and influ-
ence from a continuously evolving set of both known and unknown stakeholders. This
openness implies a shift away from traditional marked driven Requirements Engineer-
ing (RE) [4], and a need to rethink and adapt the way in how RE practices are structured
and executed. Beside the firm’s traditional RE process, there is now the advent of an
external process applied in the OSS ecosystem of which the firm is now a part of [5].
This is an informal and decentralized process where focus is on collaboration and trans-
parency [6, 7]. The challenge for a newly entered firm is to understand this new process,
and how to adapt its internal process to bridge the gap between the two [8, 9].
2 Research Questions
The overall goal of our research is to investigate and address our main research question:
RQ How should software-intensive firms, engaged in an OSS ecosystem, structure
and execute their RE practices in the context of OI?
Specifically, we build on and advance the proposed software engineering framework
for fostering OI by Wnuk & Runeson [10] with a “. . . focus on release-planning, stake-
holder analysis, trade-off between effort (cost) and value and the degree of innovation in
candidate features needed in evolving systems, to take significant future market shares in
open innovation software development”. Hence, focus will be on requirments selection
and decision-making. And as further motivated in Linåker et al. [9], this is condensed
into three research area questions, namely: stakeholder management (RQ A), when to
open up (RQ B), and prioritization and release planning (RQ C). These are then further
characterized below with a third level of research questions to better describe and define
the scope of this doctoral thesis.
2.1 Stakeholder Management
The influx of new and unknown stakeholders may introduce conflicting interests and
strategies, which may diminish a firm’s own impact in regards to feature selection and
control of product planning [8, 11]. Further, as an ecosystem evolves, power structures
and influence among stakeholders may fluctuate accordingly. This creates a need for
firms already engaged or thinking of entering an OSS ecosystem to have an awareness
of past and present ecosystem governance constellation in order to be able to adapt their
strategies and product planning to upcoming directions of the ecosystem [5, 11]. This
leads us to define the main research question for the area of Stakeholder Management
as:
RQ A How should firms manage multiple stakeholders in an OSS ecosystem and keep
a competitive edge, in the context of OI?
This can be further broken down into a series of research questions:
RQ A1 How to identify new and stay aware of present stakeholders in an open envi-
ronment?
RQ A2 How to continuously prioritize and judge importance of the stakeholders in an
open environment?
RQ A3 How to manage, adapt and act in shifting governance structures in an open
environment with multiple stakeholders and fluctuating partnership types (e.g.
feature-by-feature, project, and product)?
RQ A4 How to leverage the requirements flows to position oneself strategically in an
open environment?
2.2 When to Open Up
Stakeholder awareness is further needed as input in the planning of what a firm is to
contribute, how and when. A balance is needed between contribution and reaping of the
benefits implied by the ecosystem membership [8]. Further, care needs to be taken as giv-
ing away differentiating IPR may be hurtful both for existing and future business [8,11].
Through selective revealing [12], certain parts of the code could be broken out and con-
tributed. Separating the parts of differentiating value may however still prove difficult [8].
One way of tackling this issue would be to provide certain parts as enablers, while the
innovative features are kept internal [13]. Another strategy could be to disclose the tech-
nology, but under such circumstances that it will not be of value for competitors, e.g.
through licensing [13]. Related questions include when in the product and technology
life-cycle this should be done [14], and how. This leads us to define the main research
question for the area of When to open up as:
RQ B How should firms determine towards an OSS ecosystem, what artifacts to open
up and when, in the context of OI?
This can be further broken down into a series of research questions:
RQ B1 How to determine what artifacts (e.g. ideas, spill-over requirements, IP, plug-
ins, products) to open up and to what degree (e.g. selective revealing [12])?
RQ B2 How to determine when the right moment is to open up the artifact for external
involvement?
RQ B3 How to determine the way in which an artifact is to be developed (e.g. co-
develop, outsource) and with/by whom (e.g. single partners, groups or ecosys-
tems)?
2.3 Prioritization and Release Planning
The openness and mixture of an internal and external RE process, both on a strate-
gic and operational level, implies many new challenges to the different practices within
RE. Specifically, in regards to requirements selection and decision-making, RE sub-
processes such as triage and prioritization needs to consider the influence from both
known and unknown stakeholders. Factors of which requirements are commonly weighted
upon, such cost and value, needs to framed both from the firm’s and ecosystem’s per-
spectives. Innovative requirements may require special processes to avoid cancellation
from ordinary processes. Risks and dependencies needs consideration in the release pro-
cess as that of the ecosystem may be out of the firm’s control. This leads us to define the
main research question for the area of Prioritization and Release Planning as:
RQ C How should firms structure and execute prioritization and release-planning
towards an OSS ecosystem, in the context of OI?
This can be further broken down into a series of research questions:
RQ C1 How should other corporate stakeholders in an OSS ecosystem be taken into
account in a firm’s requirements selection and decision-making?
RQ C2 How should the internal prioritization and release processes be tailored to fit
with those of OSS ecosystems?
RQ C3 How should risks and dependencies of features be managed and considered?
RQ C4 How should cost and value be defined and considered as a decision factor?
RQ C5 What other decision factors may be considered relevant?
3 Research Methodology and Plan
The research will build on the foundation of earlier findings, which have been gathered
and synthesized in relation to OI in software engineering [10, 11], but also more specif-
ically to RE research in the context of openness (e.g. [6, 8, 15, 16]).
As emphasized by Wnuk and Runeson [10], “Studying software engineering for
open innovation must be an empirical endeavor since we are addressing complex phe-
nomena in the real world”. Hence, main research methods will be of empirical nature.
Initially, case studies will be used to conduct exploratory research in regards to the de-
fined questions and how current practices are structured and executed, but also to find
areas of improvement [17]. Unit of analysis will be software-intensive firms engaged in
OSS ecosystems [5]. Multiple parameters need to be considered in regards to the selec-
tion of firms and ecosystems respectively, for example:
– How the OSS project is leveraged in the firm’s business model, e.g. as pooled
R&D [1], a spinout [1], opensourcing [2], dual-licensing [13], or third-party ecosys-
tem [13].
– The size of the firm, both in regards to the development organization and size of
requirements repository.
– The size, composition and maturity of the OSS ecosystem, e.g. size of the code base,
number of actors, and type of actors.
– The governance structure of the ecosystem, e.g. open meritocracy or strict but benev-
olent dictatorship.
– Availability, traceability and structure of data, e.g. commit and issue data of the OSS
project, but also internally of the firm.
Triangulation will be needed in order to establish and generalize the RE practices,
both from the firm and ecosystem perspectives. Qualitative data will be derived from
interviews with firm representatives, both from the strategic and operational levels [9].
Interviews, or possibly surveys with a mix of opened and closed questions will be used
when confronting other ecosystem actors. Archival data is a further possible data source
as documentation of processes, roadmaps, discussions etc. may be available on both
sides. Analysis approach is expected to primarily focus on thematic coding of the data.
Quantitative data will be derived from software repositories of both the OSS projects
and the firms. From the firm’s perspective, this could include requirements repositories,
as well as commit and contribution data. From the OSS ecosystem’s perspective, this
regards the multiple informalisms across which the OSS requirements are represented
and specified [7]. Other than descriptive statistics, social network analysis will play a
primary role in the analysis work. Due to the importance and focus on stakeholder man-
agement in our research, aspects such as collaboration and interaction between stake-
holders in the ecosystems is preferably analyzed through the context of networks, as has
been successfully adopted in previous studies [18, 19]
Consideration should specifically be taken to the different dimensions imposed on
the questions as a result of the OI context [9]. And as with any empirical work there
will be a need for replication in order to support external validity and to make a strong
synthesis [20, 21].
In table 1 initial studies are presented. Study 1 focused on establishing clearer rela-
tionships between different types of innovations in software producing firms, e.g. that
improved software engineering process and tools as process innovation may render prod-
uct innovations, and reverse. Study 2 followed along these lines and investigated how a
large software producing firm used OSS ecosystems to improve their tools and processes
from an OI perspective, with the bigger goal to improve their products. In this study we
piloted the combination of data from both firm and communities as described earlier.
Both study 1 and 2 provides a further foundation in the understanding of OI in the con-
text of Software Engineering [10, 11], hence valuable foundation for all three research
areas (RQ A-C).
The purpose of study 3 was to explore how stakeholders interact and collaborate
to create a foundation for the research questions in regards to stakeholder management
(RQ A). Study 5 is an extension, with the goal to create further understanding of the
area, but also to investigate its impact on feature-selection and ecosystem governance.
Study 4 was used to outline and establish a research agenda for RE in OI by surveying
available literature, highlighting the three areas further defined in this paper (RQ A-C).
Study 6 and 7 have the purpose to further explore the general RE practices of software-
intensive firms engaged in OSS ecosystems, but from two different sides on the scale in
regards to size. These studies will provide foundation and understanding to build on in
regards to all the three research areas (RQ A-C).
Study 8 is a planned follow-up study on study 6 to explore the contribution strategy
and feature innovativeness classification at the same firm. Goal is to examine trade-offs
between cost and benefit of contributing in different areas and levels of the OSS project,
hence addressing the research questions related to the topic when to open up (RQ B).
This first phase can be seen as an empirical complement to earlier studies and will
serve as a foundation for more narrow and solution-oriented studies later on.
4 Expected contributions
We expect to make a contribution by establishing guidelines and tools for how RE should
be structured and executed to cope with possible challenges implied by OI. Focus will
foremost be on the areas of requirements selection and decision making, more specifi-
cally in regards to:
1. Stakeholder Management - Help for firms managing multiple stakeholders in an
open environment and how to adapt strategically in the governance structure of the
open environment to keep a competitive edge.
2. When to Open Up - Help for firms to determine what artifacts to open up, when
and how.
3. Prioritization and Release planning - Help for firms to best structure and execute
prioritization and release-planning towards Open Source ecosystems.
References
1. Joel West and Scott Gallagher. Challenges of open innovation: the paradox of firm investment
in open-source software. R&d Management, 36(3):319–331, 2006.
Table 1: Research overview with finished, ongoing and planned studies.
Started April, 2014. Preliminary target for Doctoral Thesis - Spring, 2019.
Study Questions and Objectives Methodology Status
#1 What is the perception of product innovation and its Survey at a Large Finished
relation to process, business and organizational in- Product-focused Soft-
novation? ware organization
#2 Explore the use of OSS tools at a large product- Case study with a quan- Submitted
focused software organization and their involvement titative and qualitative
in the ecosystems from an OI perspective, and from approach
this identify innovative outcomes and how software
engineering practices have been adapted.
#3 How firms adapt and interact in OSS ecosystems by Case study with quanti- Finished
analyzing the influence and collaboration patterns tative approach with so-
among and between the stakeholders cial network analysis
#4 Propose a direction for RE research in the field of OI Opinion paper based on Finished
literature and current
findings
#5 Explore stakeholder interaction and collaboration Case study with a quan- Ongoing
further, in regards to feature selection and ecosys- titative and qualitative
tem governance approach.
#6 Explore RE practices at a large product-focused Case study with a quan- Ongoing
software organization engaged in an OSS platform titative and qualitative
ecosystem, from an OI perspective approach.
#7 Explore RE practices at three startups, engaged dif- Case study with a quan- Ongoing
ferent OSS ecosystems, from an OI perspective titative and qualitative
approach.
#8 Explore contribution strategy and feature innova- Case study with a quan- Planned
tiveness classification at a large product-focused titative and qualitative
software organization engaged in an OSS platform approach.
ecosystem, from an OI perspective
2. Pär J Ågerfalk and Brian Fitzgerald. Outsourcing to an unknown workforce: Exploring open-
surcing as a global sourcing strategy. MIS quarterly, pages 385–409, 2008.
3. Henry William Chesbrough. Open innovation: The new imperative for creating and profiting
from technology. Harvard Business Press, 2006.
4. Björn Regnell and Sjaak Brinkkemper. Market-driven requirements engineering for software
products. In Engineering and managing software requirements, pages 287–308. Springer,
2005.
5. Slinger Jansen, Sjaak Brinkkemper, and Anthony Finkelstein. Business network management
as a survival strategy: A tale of two software ecosystems. Proccedings of the 1st International
Workshop on Software Ecosystems, pages 34–48, 2009.
6. Samuel Fricker. Requirements value chains: Stakeholder management and requirements en-
gineering in software ecosystems. In Requirements Engineering: Foundation for Software
Quality, pages 60–66. Springer, 2010.
7. Walt Scacchi. Understanding the requirements for developing open source software systems.
In Software, IEE Proceedings-, volume 149, pages 24–39. IET, 2002.
8. Krzysztof Wnuk, Dietmar Pfahl, David Callele, and Even-André Karlsson. How can open
source software development help requirements management gain the potential of open in-
novation: an exploratory study. In Proceedings of the ACM-IEEE international symposium
on Empirical software engineering and measurement, pages 271–280. ACM, 2012.
9. Johan Linåker, Björn Regnell, and Hussan Munir. Requirements engineering in open inno-
vation: a research agenda. In Proceedings of the 2015 International Conference on Software
and System Process, pages 208–212. ACM, 2015.
10. Krzysztof Wnuk and Per Runeson. Engineering open innovation–towards a framework for
fostering open innovation. In Software Business. From Physical Products to Software Services
and Solutions, pages 48–59. Springer, 2013.
11. Hussan Munir, Krzysztof Wnuk, and Per Runeson. Open innovation in software engineering:
a systematic mapping study. Empirical Software Engineering, pages 1–40, 2015.
12. Joachim Henkel, Simone Schöberl, and Oliver Alexy. The emergence of openness: How and
why firms adopt selective revealing in open innovation. Research Policy, 43(5):879–890,
2014.
13. Joel West. How open is open enough?: Melding proprietary and open source platform strate-
gies. Research policy, 32(7):1259–1285, 2003.
14. Frank Van der Linden, Björn Lundell, and Pentti Marttiin. Commodification of industrial
software: A case for open source. IEEE Software, 26(4):77–83, 2009.
15. Eric Knauss, Daniela Damian, Alessia Knauss, and Arber Borici. Openness and require-
ments: Opportunities and tradeoffs in software ecosystems. In IEEE 22nd International Re-
quirements Engineering Conference, pages 213–222. IEEE, 2014.
16. Thomas Alspaugh, Walt Scacchi, et al. Ongoing software development without classical
requirements. In 21st IEEE International Requirements Engineering Conference, pages 165–
174. IEEE, 2013.
17. Per Runeson, Martin Host, Austen Rainer, and Bjorn Regnell. Case study research in software
engineering: Guidelines and examples. John Wiley & Sons, 2012.
18. Daniela Damian, Sabrina Marczak, and Irwin Kwan. Collaboration patterns and the impact
of distance on awareness in requirements-centred social networks. In 15th IEEE International
Requirements Engineering Conference, pages 59–68. IEEE, 2007.
19. Jose Teixeira, Gregorio Robles, and Jesús M González-Barahona. Lessons learned from
applying social network analysis on an industrial free/libre/open source software ecosystem.
Journal of Internet Services and Applications, 6(1):1–27, 2015.
20. Stefan Schmidt. Shall we really do it again? the powerful concept of replication is neglected
in the social sciences. Review of General Psychology, 13(2):90, 2009.
21. Daniela S Cruzes, Tore Dyba, Per Runeson, and Martin Host. Case studies synthesis: Brief
experience and challenges for the future. In International Symposium on Empirical Software
Engineering and Measurement, 2011, pages 343–346. IEEE, 2011.