Article Preview
TopIntroduction
The rapid pace of technological changes and the competitive race for quick product release are driving many companies to look for new ways to deliver software. Software product lines (SPLs) are one step towards making software development more efficient (Bosch & Bosch-Sijtsema, 2010). In SPL, a set of business units in an organization could develop the products through collaboration by sharing a common technological platform, and by reusing much of the software between different versions and variants of the product. Over the past decade, companies have been transitioning their SPLs to software ecosystems (SECOs) to open their platforms for external software providers (Bosch, 2009). The goal is to rapidly develop new capabilities and foster innovations unforeseeable by the platform’s original designers (Jansen & Cusumano, 2013). The SECOs are multi-disciplinary systems inspired from business and natural ecosystems. Manikas and Hansen define software ecosystem as “…the interaction of a set of actors on top of a common technological platform that results in a number of software solutions or services…” (Manikas & Hansen, 2013) (p. 1297). For example, Google controls the Android platform while external developers can build applications that are distributed to Android users via the Google Play store. Thus, Google has collaborated with external developers to build functionality in the form of available applications. In contrast to the software development in an individual organization, SECO includes the software development by several organizations through collaboration and competition (Bosch-Sijtsema & Bosch, 2015). For instance, Microsoft made the PowerShell tool built on Microsoft .NET as an open source product to keep the developers interested in the Windows platform while Google released Cloud Tools for PowerShell to make Google's cloud more attractive to .NET developers. Either way, both Google and Microsoft co-create value through collaboration and competition.
Despite the perceived advantages of SECOs, transitioning to SECOs may have challenges with communication barriers between parties due to the dispersion of SECO members. On the other hand, providing the open platform to external actors raises the conflicts of interest when negotiating requirements. One of the main issues is inconsistency and variability in stakeholders’ requirements. Requirements engineering (RE) is essential for SECO’s to involve stakeholders early in the development to understand requirements and use cases. The impact of changes can be analyzed and documented through a model of the system (Hull, Jackson, & Dick, 2011) during the early stage of RE. Modeling can aid the stakeholders of a SECO to make sustainable relations among the actors when they negotiate their common interests (i.e. requirements) for the software. The obvious question to ask is whether the RE process used for traditional systems can cope with the context of SECO’s? How can the RE process best be conducted when developing multi-organizational, socio-technical systems like SECOs? Can adaptation of existing traditional approaches used in designing of technical system aids modeling of SECOs or does SECO require a new approach? Our research questions are: RQ1: What RE activities have been studied specifically in relation to software ecosystems earlier? RE activities address, how are the requirements elicited, analyzed, documented, validated, and traced. RQ2: How are non-functional requirements considered in the context of SECOs? A number of challenges in SECO’s have been discussed in the literature (Serebrenik & Mens, 2015), we focus on challenges specific to non-functional requirements in SECOs.
The remainder of the paper is structured as follows. Section 2 provides the background of SECOs and RE. In Section 3, we describe the research method used for conducting a literature review for the paper. Section 4 analyzes the results. Section 5 provides discussion of research gaps identified in the existing literature on RE in SECOs follows with conclusion in section 6.