What do we know about requirements management in software ecosystems?

Requirements engineering (RE) is commonly accepted as the basis of high-quality software [69, 84]. RE is an iterative socio-technical process to elicit, document, and manage the requirements of a developing system [35]. Heistracher et al. [40] state that in-deep RE and continuous requirements management are key prerequisites for the success of software engineering (SE) and systems engineering endeavors. Yaseen et al. [104] highlight the importance of requirements management, noting that the successful implementation of all other phases of RE is related to its effectiveness.

Fernández et al. [27] mention that requirements management still faces problems related to incomplete and/or hidden requirements, lack of traceability, requirements change control, and communication failures. For the authors, requirements management is challenging. However, performing requirements management in complex systems within open and dynamic environments that go beyond the limits of a single organization, such as software ecosystems (SECO), is even more challenging [24, 59]. Manikas [65] defines SECO as developing multiple products derived from a common technological platform based on a central architecture integrated with other systems through network actors and artifacts.

SECO are becoming a predominant mode of software development [24]. However, Knauss et al. [53] claim that SECO introduces complexity in requirements management. For the authors, the complexity and changing nature of SECO result in several new requirements based on ecosystem trends that make requirements management difficult, called emergent requirements. Axelsson and Skoglund [12] state that the dynamic set of stakeholders in SECO introduces challenges to understanding, managing, and maintaining the balance between different stakeholder requirements. According to Vegendla et al. [96], more research should be performed to investigate the current state of requirements management in SECO. Hence, investigating how requirements management is carried out in SECO can help professionals in the improvement of their practices, as well as researchers in the realization of an overview of the field.

In this work, we aim to characterize requirements management in SECO. To achieve this goal, we conducted a systematic mapping study (SMS) [50] to identify and analyze the current state of the requirements management in SECO concerning its characteristics and existing approaches. We considered “characteristics” as process elements [16, 26] that differentiate requirements management in SECO from requirements management in traditional software development (i.e., concepts/definitions, activities, actors’ relationships, and artifacts). We consider “approaches” as types of contributions [25, 71, 86] cited/proposed in the selected studies (i.e., methods, techniques, tools, and practices). In addition, we aim to verify if (and how) the approaches identified are assessed. This work also aims to offer to researchers in this field an overview of what has already been done and where their contributions are still needed.

We retrieved 1028 studies from seven digital libraries in database search (DBS) and 1458 studies in backward snowballing (BS) and forward snowballing (FS). Hence, we selected 29 studies in our SMS. As the main contribution of our SMS, we defined nine characteristics of requirements management in SECO. These characteristics include opening organizational boundaries, power relations between geographically dispersed multi-party actors, open communication channels, and emergent requirements spread across multiple requirements artifacts and stored in different repositories. We also identified four types of approaches (tool, method, model, and practice) to support requirements management in SECO. We identified 11 selected studies that only cite approaches to support requirements management in SECO (e.g., a selected study only cited that issue tracking tools support requirements management activities in SECO) and ten that propose specific approaches (e.g., a selected study proposed a method to support some activity of requirements management in SECO). Only three of the ten selected studies that proposed approaches presented their assessment as well.

Our main results show that requirements management in SECO is an open, informal, collaborative, and decentralized process involving multi-party actors susceptible to power relations. These multi-party actors manage different types of requirements in SECO (i.e., product, platform, and integration requirements) through strategic and emergent requirements flows. Our results also show that the characteristics and approaches for requirements management in SECO are mainly related to openness and information sharing among a “crowd.” Hence, we discuss the relationship between the characteristics of requirements management in SECO and emerging RE concepts such as Crowd-Based RE (CrowdRE) and Open RE. We also realized that other RE activities influence or are influenced by requirements management in SECO, and we address this relationship in our study. Finally, we discuss challenges regarding the characteristics of requirements management in SECO.

The remainder of this article is structured as follows. Section 2 presents the background and related work. Section 3 introduces the research questions and research method details. Section 4 presents the results, which we then discuss in Sect. 5. Section 6 points out limitations and threats to validity of the study. Section 7 presents a research agenda for requirements management in SECO. Finally, Sect. 8 outlines the conclusion and future work.

2.1 Requirements management

Requirements management is an organized process of documentation, analysis, traceability, prioritization, change control, and requirements communication [41]. García et al. [34] consider requirements management a key area within RE. According to Berenbach et al. [15], requirements management makes RE possible for large projects and helps reduce the chaos inherent in such projects because it includes version control of all artifacts that are the requirements sources of the RE process. Yaseen et al. [104] state that incorrect requirements management is linked to more than half of the reasons for project failures. According to Jayatilleke and Lai [46], failure to manage the requirements changes is the leading cause of the project’s failure. Moreover, requirements management ensures that changes in requirements are reflected in project plans, activities, and work products [21].

Song [88] defines requirements management as a process that accompanies the planning and development of a system, capturing and mapping the origin and context of changes. For Wiegers and Beatty [99], requirements management includes all activities that maintain the integrity, accuracy, and validity of requirements agreements throughout the project. For the authors, the main tasks of requirements management are four main activities: version control, change control, tracking of requirements status, and requirements traceability. Version control is an essential aspect of requirements management and applies at the level of individual and set requirements. Change control concerns the procedures, processes, and standards used to manage changes to requirements. Tracking the status of each requirement during system development is an essential aspect of requirements management and provides a more accurate indicator of project progress. Requirements traceability aims to document the dependencies and logical links between individual requirements and other system elements [99].

2.2 Software ecosystem

Barbosa et al. [13] and Manikas [65] mention that research on SECO started in 2003 in the book by Messerschmitt and Szyperski [66]. According to Bosch [17], SECO have offered organizations advantages related to the acceleration of innovation, the dispersion of innovation costs, and the reduction of software maintenance costs when sharing activities with other members of the ecosystem. Axelsson and Skoglund [12] explain that SECO are based on an open environment and have a range of actors from different organizations, interacting around an open or semi-open platform, thriving among themselves cooperatively and competitively (“coopetition”), producing several software solutions or services.

Santos and Werner [79] present three vital elements in an SECO: (i) software, which exists as a common technological platform, central software technology, software solutions, software platform, or product line; (ii) transactions, taken as the understanding that encompasses profit, reward or also benefits other than financial; and (iii) relationships, which are the links among the actors based on elements (i) and (ii). There are also two fundamental concepts in the SECO: The first is a common interest in central software technology, and the second is the concept of a network of organizations, which relate to symbiotic aspects of evolution, commercial or technical jointly, where each of the actors can benefit from participating in SECO.

In addition, Santos and Werner [78] address SECO from three dimensions: (i) technical: centered on the platform (technology, infrastructure, or organization). It is driven by three factors: development infrastructure, governance, and requirements management; (ii) business: centered on the knowledge flow (management model for artifacts, resources, and information). It is guided by three factors, i.e., environment vision, innovation, and strategic planning; and (iii) social: centered on stakeholders (influence and knowledge networks). It is conducted by three factors: usefulness, promotion, and knowledge gain. There is a need for special attention to stakeholders in these three dimensions. Defining their roles, putting the user at the center of the process, and performing configuration management may establish some challenges in the SECO context.

2.3 Related work

As related work, Vegendla et al. [96] provide an overview of the RE in the SECO context. The work focused on two main points: (i) RE activities in the SECO context and (ii) non-functional requirements in the SECO context. The study only identified topics related to ER activities that have already been studied in the context of SECO. Its results highlight that requirements management is a challenging activity and cites global RE and management practices are topics that have already been studied in the context of SECO. However, it does not describe or discuss how these topics were investigated. The study does not cite any approach or characteristics of requirements management in SECO. This work differs from the study by Vegendla et al. [96] in that it aims to define characteristics of requirements management in SECO and identify approaches to support requirements management in SECO.

More broadly, some SMS on SECO was conducted to provide an overview of the subject. Barbosa et al. [13] present the subject’s benefits, limitations, and challenges. Manikas [65] lead a longitudinal study on SECO to provide an up-to-date overview of the field and document its development. Barbosa et al. [13] mention the importance of communicating the requirements among stakeholders that may be geographically distant. Barbosa et al. [13] also presents aspects related to requirements negotiation as a characteristic of a given SECO. Manikas [65] point out that RE is represented in the SECO literature and cite a work focusing on privacy requirements. Despite this, it is possible to notice that none of the works present more excellent detailing on requirements management in SECO.

Other works sought to analyze SECO through specific topics. Fontão et al. [30] conduct an SMS on mobile software ecosystems (MSECO). The authors state an apparent demand for approaches, methodologies, processes, and tools to support this type of SECO. Besides, relations were identified among the MSECO quality and business requirements and objectives verification. However, as the work is focused on the MSECO domain, the mapped approaches are focused or adaptable to this context and are not directed to requirements management. Franco-Bedoya et al. [31] conduct an SMS to assess state of the art in open-source software ecosystems (OSSECO) research. The study presents the most relevant definitions related to OSSECO and its particularities. In this context, the authors define requirements as an essential activity in OSSECO. The authors give the need to monitor OSSECO and link the collected data to the actors’ needs and quality requirements as a research agenda.

Jayatilleke and Lai [46] identify studies that deal with requirements management and are common to SECO, such as, for example, a method that supports the requirements change management (RCM) in the context of global software development (GSD), a paradigm in which software development activities are carried out beyond the geographic, cultural and temporal boundaries [4]. Furthermore, the existence of geographically distributed actors was identified as one of the challenges in agile RCM. However, despite containing elements in the research that are inherent characteristics of SECO, the authors do not incorporate the SECO perception. Moreover, the work of Jayatilleke and Lai [46] can serve as insight for research regarding requirements management in SECO, as it addresses aspects that permeate the topic.

Alsanoosy et al. [9] conduct a systematic literature review (SLR) that investigated the influence of culture on RE activities. The authors noted that studies on the relations between culture and RE practices are still immature. The authors emphasize that understanding how each culture undertakes the RE process contributes to effectively implementing their practices in a GSD context. In addition, the study highlights that the incompatibility of practices can lead to several challenges, such as the difference in time for developing requirements in different locations, the common understanding among software teams on how the work should be done, and the monitoring of the current stage of each requirement. However, the cited practices are common in the requirements management process. Our work considers the discussion presented by Alsanoosy et al. [9] and aims to investigate specifically the requirements management in a broader context such as SECO.

In the present work, we have not established a specific type of SECO to be studied. Therefore, requirements management was characterized in studies related to any SECO, including those aimed at MSECO or OSSECO. We notice that several topics have been approached about RE in SECO, among them identifying stakeholders and the roles for the requirements elicitation and analysis. Furthermore, it was possible to make an exciting mapping between RE activities and research topics in the SECO context. For example, topics related to modeling, reference model, and non-functional requirements were mapped for requirements elicitation. For requirements management, only global management practices were mentioned. Thus, the secondary studies in the SECO literature do not focus on requirements management or the definition and evaluation of approaches used to accomplish it. Overall, they seek to understand the RE process and activities in SECO.

In this section, we described our research method. We conducted an SMS to achieve the objective we present in Sect. 1. For Kitchenham et al. [51], an SMS aims to (i) survey the available knowledge about a topic; (ii) synthesize this by categorization; (iii) identify where there are “clusters” of studies that could form the basis of a fuller review; and (iv) identify where there are “gaps” indicating the need for more primary studies. In our SMS, (i) we search the available knowledge about requirements management in SECO; (ii) we synthesize data about characteristics and approaches of the requirements management in SECO; (iii) we identify ‘clusters’ of studies about other RE activities in SECO (Sect. 5); and (iv) we identify “gaps” (Sect. 5).

According to Kitchenham and Charters [50], an SMS or SLR must perform the following phases: planning, conducting, and reporting the review. The following subsections detail the planning phase of this SMS. Section 4 presents details on the conducting phase and results.

3.1 Goals and research questions

This study aimed to characterize requirements management in SECO. The objective of this study was formalized based on the GQM (Goal-Question-Metric) method, proposed by Basili and Rombach [14] and defined as follows: analyze the requirements management with the purpose of characterizing with respect to elements (i.e., concepts/definitions, activities, actors’ relationships, and artifacts) and types of contributions (i.e., methods, techniques, tools, and practices) from the point of view of researchers in the context of SECO studies. We consider “characteristics” as process elements and “approaches” as types of contributions cited/proposed in the selected studies. Hence, we defined three research questions (Table 1).

3.2 Search strategy

We applied a hybrid search strategy [67, 101] in our SMS. Wohlin et al. [101] defined a hybrid search strategy as “the pre-planned integration of at least two systematic approaches to searching for articles for a systematic literature study.” Mourão et al. [67] presented four hybrid search strategies used in SE: (i) DBS in Scopus followed by full BS and FS; (ii) DBS in Scopus followed by BS and FS in parallel; (iii) DBS in Scopus followed by BS and then FS; and (iv) DBS in Scopus followed by FS and then BS. Wohlin et al. [101] compared and evaluated the four strategies and concluded that the full-fledged hybrid search strategy (i) is better than the other alternatives. For this reason, we applied strategy (i).

In the full-fledged hybrid search strategy (i), we must initially perform the DBS and then identify new studies by BS and FS based on the initial set of selected studies from the DBS. Our hybrid search strategy involved DBS in seven digital libraries: ACM Digital Library,^{Footnote 1} ScienceDirect,^{Footnote 2} Engineering Village,^{Footnote 3} IEEE Xplore Digital Library,^{Footnote 4} Scopus,^{Footnote 5} Web of Science,^{Footnote 6} and Wiley Online Library.^{Footnote 7} Wohlin et al. [101] highlight that BS and FS must be performed for all selected studies, i.e., they must be performed in several iterations until no new studies are selected. Figure 1 presents our hybrid search strategy.

Hybrid search strategy

Full size image

The guidelines provided by Kitchenham and Charters [50] recommend composing a string to find relevant studies by searching several digital libraries or index databases. To conduct the DBS, we initially identified keywords from terms present in the research questions. Afterward, we gathered the keywords into a search string (Table 2). Regarding the keywords, we restricted searches to find studies that investigated/cited requirements management in the specific context of SECO. We highlight that one of the first SMS on “software ecosystems” [13] used synonyms such as “software supply network,” “software vendor,” or “software supply industry.” However, more current studies [57, 65] use only “software ecosystems.” Additionally, the term “software ecosystems” has been a topic of interest at the International Conference on Software Engineering (ICSE)^{Footnote 8} in the past years and covered by other venues as well.

To increase the reliability of our search strategy, we use control studies in the DBS. Control studies support evaluating the quality and comprehensiveness of the search string [42]. Control studies must be retrieved when searching in a given digital library and are essential for calibrating a search string [68]. We identified the two control studies [53, 62] in exploratory studies we conducted previously. The two control studies investigated requirements management in SECO and were retrieved in different digital libraries as we calibrated our search string.

3.3 Study selection

Kitchenham and Charters [50] divide the study selection into two parts: (a) definition of study selection criteria and (b) definition of the study selection process. We present below our definitions for each part.

3.3.1 Study selection criteria

According to Kitchenham and Charters [50], for the selection of retrieved studies, inclusion criteria (IC) (Table 3) and exclusion criteria (EC) (Table 4) must be defined and applied. Kitchenham and Charters [50] mention that an SMS requires explicit IC and EC to evaluate each potential primary study and that these criteria are based on the set of research questions. We were inspired by the examples of IC and EC presented by Kitchenham et al. [51] in their recent reference book and the related work presented in Sect. 2.3 to define the set of IC and EC.

3.3.2 Study selection process

In our SMS, we divided the selection process into seven stages and explained each stage and its relationship with the IC and EC, according to Kitchenham and Charters [50], in Table 5. We also considered the selection processes defined in the related work of Sect. 2.3. The selection process involved the four authors. The first two authors initially applied the IC and EC independently. Thereafter, the same two authors compared the results and sought a consensus in case of divergence. Finally, the last two authors, who have more than ten years of experience conducting and publishing secondary studies, assessed the results of each stage.

3.4 Data extraction and synthesis

According to Kitchenham and Charters [50], the data extraction process must collect the data items needed to answer the research questions. The data extraction process in a secondary study comprises elaborating forms to accurately record the information obtained in the primary studies [50]. Our data extraction form is openly available via ZENODO.^{Footnote 9}

During data extraction, we identified in each selected study: (a) specific characteristics of requirements management in SECO (RQ1); (b) approaches used for requirements management in SECO (RQ2); (c) whether or not there was an assessment of the approaches used for requirements management in SECO (RQ3); and (d) the method used for assessment (RQ3). We also extracted data that allowed us to do the demographic analysis of the studies selected in our SMS. We followed the example of some related work mentioned in Sect. 2.3 [9, 96]. These works present an overview of the demographic data of the select studies without referring to specific RQ. We identified in each selected study: (a) Title; (b) Year; (c) Authors; and (d) Country of 1st author.

We performed the data extraction process by following these steps: (a) The first two authors initially extracted data from the studies independently; (b) the first two authors jointly analyzed and compared the individual data extraction results and completed the data extraction form; and (c) the last two authors with more than fifteen years of experience in conducting secondary studies in SE and information systems evaluated the process and the results obtained at each stage. Ampatzoglou et al. [10] suggest the cross-check process of the extracted data by a more senior researcher. During this process, the role of the additional researchers is to cross-check results or resolve conflicts.

To answer the research questions, we used data synthesis. Kitchenham and Charters [50] state that there are two main data synthesis methods: (i) descriptive (qualitative) and (ii) quantitative. We used the qualitative method to analyze the extracted data and answer our research questions, which led to descriptive data synthesis [22]. We applying open and axial coding procedures [18] to support the qualitative synthesis method. Open coding involves applying codes that are derived from the text, and axial coding categorizes the initial codes into key codes [18]. Qualitative methods such as content analysis, thematic analysis, and grounded theory use coding procedures.

Figure 2 presents an overview of the selection process. We performed a DBS in the seven digital libraries. We retrieved 1,028 studies published up to March 2023 in the DBS. Then, we applied the filters defined in the stages of the selection process (Sect.  3.3.2). We selected 25 studies in the DBS. Thus, we applied BS and FS to the 25 studies selected from the search database and retrieved 1300 studies. We selected three studies in the first snowballing iteration. Then, we applied BS and FS for the second time in 120 retrieved studies in the three selected studies in the first snowballing iteration. Thus, we selected one study in the second snowballing iteration. Finally, we applied BS and FS for the third time in 38 retrieved studies in the selected study in the second snowballing iteration. However, when we applied the filters defined in the selection process, we did not select any new studies. Hence, we got a total of 29 selected studies in our SMS. Appendix A presents the selected studies in ascending order by year of publication and are referred to as S1–S29.

Study selection process

Full size image

4.1 Demographic data and overview of results

Figure 3 shows the distribution of selected studies over the years. We noted that at least one study was published from 2012 to 2021. The selected studies had 87 different authors. However, for analyzing the countries related to each study, we considered only the countries of the first author. Figure 4 presents the distribution of publications by country. Sweden (9 studies) and Brazil (7 studies) are the countries that authored most of the selected studies.

Distribution of select studies by year

Full size image

Distribution of selected studies by country

Full size image

Figure 5 presents this study’s main findings and the summary of answers to research questions (Sects. 4.2, 4.3, and 4.4). In addition, Fig. 5 also shows other information discussed in Sect. 5, such as the main reasons requirements management in SECO is considered a challenge and what other activities of the RE are related to requirements management in SECO.

Requirements management overview in SECO

Full size image

4.2 Characteristics of requirements management in SECO (RQ1)

In our work, characteristics are process elements [16, 26] related to requirements management in SECO that differentiate it from requirements management performed in traditional software development. To define them, we considered the technical, human, and organizational factors in SECO used by Luz et al. [64]. Luz et al. [64] state these factors can influence SECO technical and organizational elements. For example, the factor multiplicity of organizations and relationships of a SECO influence the requirements management in SECO.

We defined the characteristics of requirements management in SECO through the data synthesis process detailed in Sect. 3.4. We used the synthesis qualitative method [22] to analyze the extracted data and answer our research questions. To do so, we initially used an open coding approach. We coded the extracted data of the selected studies in an inductive (bottom-up) way [18]. We performed a detailed reading of selected studies and divided parts of the text of these studies into coherent units (sentences or paragraphs). Subsequently, we agreed on a set of codes that captured the most frequent and relevant characteristics of requirements management in SECO cited in the selected studies. The coding was done by two authors and reviewed over several iterative cycles by the other two authors (with more than fifteen years of experience with SE research).

After executing open coding, we used axial coding to group the codes into categories, as described by Charmaz [18]. We categorized the characteristics into (i) concepts/definitions; (ii) activities; (iii) actors’ relationships; and (iv) artifacts. Table 6 shows examples of the coding process of the selected studies (the resulting codes and their categories). The complete coding process is openly available via ZENODO.^{Footnote 10} Finally, Table 7 presents the nine characteristics of requirements management in SECO (C1–C9).

4.2.1 Concepts/definitions

C1 refers to the openness, informality, collaboration, and decentralization of requirements management in SECO. S13, S14, S17, S19, and S24 state that requirements management in SECO is informal, has overlapping practices and uses informalisms [83]. S3, S11, S13, S15, S17, and S24 mention that the requirements management process in SECO is decentralized and collaborative. S15 highlights that SECO require a collaborative and joint requirements engineering process. S24 defines requirements management in SECO as a lightweight and evolutionary process compared to more traditional processes characterized by heavy processes and supporting tools.

S11, S13, S14, S15, S16, S17, S20, S22, and S29 indicate that requirements management in SECO is open. S11, S16, S17, and S22 cite that the requirements management in SECO is cross-domain and uses the open innovation paradigm. S16 suggests that open innovation positively impacts requirements change management, quality requirements, and requirements communication. However, open innovation negatively impacts identifying stakeholders’ needs, requirements prioritization, and requirements traceability. S20 mentions that SECO are, by nature, cross-domain and open. Then, requirements managers in SECO no longer deal with one domain at a time and must accept the openness inherent to SECO in requirements management activities. S11 points out that involving new business models to support open RE is necessary.

C2 focuses explicitly on the concept of emergent requirements in requirements management in SECO. S17 mentions that the complexity and ever-changing nature of SECO results in several new requirements based on ecosystem trends and defines them as emergent requirements. S3, S13, and S17 cite that emergent requirements originate from end users of consumers in the ecosystem, who find new ways to use existing services. S29 mentions that new functionalities offered by external developers (complementors) can generate emergent requirements. S7 highlights that multi-party actors who are not responsible for the requirements but contribute to discussing them beyond organizational boundaries originate emergent requirements. For S29, emergent requirements allow keystone to innovate further to grow platform offerings, creating a circular flow of requirements knowledge. According to S17, it is difficult to map emergent requirements to specific actors, especially since they are generally transversal to several SECO actors.

C3 focuses on the types of requirements that affect requirements management in SECO. S3 bifurcates the requirements in SECO into kernel requirements and periphery requirements. S8 ranks the requirements in SECO into partner requirements and customer requirements. S8 highlights that partner requirements in SECO may be a higher priority than customer requirements. For S9, there are product, integration, and platform requirements in SECO. Integration requirements must be “generic and reusable” among partners as they are part of a shared infrastructure. Platform requirements are the basis of the development environment actors use to develop complementary products in SECO. S15 highlights that most demands in a SECO are integration requirements involving data types exchanged and data dictionary, for instance. S29 mentions that evangelists are a key source of feedback and provide several integration requirements.

S10 identifies several requirements communicated by the keystone to other SECO members. S10 classifies them into three generic categories of requirements: strategic, brand, and platform requirements. Strategic requirements ensure a particular function that is essential to the systemic product the customer will acquire. Branding requirements play a role in preserving SECO’s brand reputation. Platform requirements facilitate product design and development in SECO. S26 carries out a case study in a specific SECO. It suggests that the RE process in SECO should have three main focuses: RE for the product, RE for the platform, and RE for the ecosystem (holistic view to identify integrations between products). For S26, the developers of partner applications are direct users of the platform, and their needs are essential for the ecosystem’s health.

4.2.2 Actors’ relationships

C4 refers to groups of multi-party actors that influence the requirements management in SECO. S7 and S17 cite that requirements emerge and propagate through multiple stakeholders’ collaboration across a SECO. S2, S4, S6, S26, and S28 point out that in SECO, it is necessary to consider the interaction of several stakeholders to define requirements for their products and platforms. For S6, it is necessary to identify requirements from several customers with different contexts of use and coordinate the work with several teams responsible for the products of the SECO. S8, S20, S21, S24, and S29 highlight that requirements managers must consider external and interdependent stakeholders in SECO. For S21, one of the major differences between distributed teams in GSD and SECO is that the teams or actors are not within the same company or organization but instead spread across several organizations, whereby each actor contributes different elements to the system or product.

C5 focuses on power relations among different multi-party actors that influence requirements management in SECO. However, C5 focuses explicitly on the power relationship between actors in SECO. For S15, companies exercise their legitimate power by proposing new requirements for partners in SECO. S9 mentions that power conflicts are frequent between partners in SECO. S17 cites that multiple stakeholders are susceptible to issues of stakeholder power affecting requirements management activities. Power relations strongly affect stakeholder identification (S17), negotiation (S9, S20, and S21), prioritization (S20, S24), and requirements communication (S17) in SECO. For S9, the notion of power is a common problem affecting RE decision-making. S24 highlights that power relations can result in misalignment with internal RE processes.

4.2.3 Activities

C6 focuses on requirements negotiation activity that impacts requirements management in SECO. S14 highlights that requirements negotiation in SECO is fundamental, as a consensus often is needed to make certain decisions. S2 and S9 mention that requirements negotiation in SECO establishes an agreement of interests and intentions between multiple stakeholders distributed globally. S5 states that geographic distribution causes the inefficiency of negotiation activities that depend on face-to-face communication or require interaction between teams. S7 justifies that since the stakeholders are multiple and spread across the SECO, the requirements negotiation is complex, as it must consider shared objectives and relationships between the ecosystem actors. S5 points out that these actors have different and sometimes conflicting expectations.

S7 suggests using specific technologies or techniques to address requirements negotiation in SECO. However, S7 mentions that these technologies or techniques do not have an in-depth view of the social dynamics of SECO. For S7, SECO introduce specific requirements negotiation questions, such as aligning interests and expectations among companies and its markets. S13 and S17 point out that emergent stakeholders from across the ecosystem and the relationship with partners are important in requirements negotiation in SECO. For S5, requirements negotiation involves a decision-making process conducted by several different actors along the SECO lifecycle. In traditional software development, requirements negotiation is often less complex, as it usually occurs between a limited number of customers and a limited set of organizations developing the software.

C7 focuses on requirements identification and prioritization that impacts requirements management in SECO. S4, S6, S7, S15, S17, S25, S26, and S29 cite that keystone must consider interacting with several stakeholders to identify requirements. S15 highlights that the requirements are not equally important and must be ranked or prioritized with a value. For S5 and S9, SECO provide products for a broad market, which means that requirements are often jointly defined by the suppliers of the ecosystem rather than elicited from users. S17 points out that traditional RE methods were reported as insufficient to support requirements elicitation in SECO. For S5 and S25, the high number of stakeholders in SECO presents challenges regarding requirements elicitation.

S14 and S24 mention that SECO maintainers (keystones) commonly conduct requirements prioritization, though care is often taken to the opinions of other developers and users. For S5 and S8, requirements prioritization in SECO should only be carried out by relevant stakeholders. According to S21, requirements prioritization can differ highly between SECO actors because different stakeholders value different attributes when dealing with a requirement. Every partner contributes requirements to the ecosystem, which might result in a requirements overload, causing complications in the prioritization process. S24 cites that practices such as requirements identification and prioritization in SECO overlap and are done collaboratively through iterative and transparent discussions and negotiations. S5 highlights that the requirements definition cannot be disconnected from business processes governing the SECO.

C8 focuses on requirements communication activity that is fundamental to requirements management in SECO. S10 and S17 highlight that the requirements must be communicated inside and outside the SECO. For S5, requirements emerge through communications among the actors of the ecosystem. S20 and S26 cite that CrowdRE supports requirements communication through open and heterogeneous communication channels. According to S2, S6, and S8, a requirements communication network (RCN) enables the analysis and design of requirements communication between multiple stakeholders. RCN describe the stakeholders, the communicated requirements traces, and the structure of a SECO in terms of actors, groups of actors, and negotiation channels.

S4, S21, and S27 highlight using multiple open communication channels to allow transparent communication between the multiple SECO actors. S4 cites that RE via open channels is an innovative process. The studies present discussion forums (S3, S13, S15), problem/issue trackers (S13, S14, S27), mailing lists (S13, S14, S15, S27), ticket/helpdesk systems (S14, S15, S27), and version control systems (S27) as examples of open communication channels. This scenario diverges from requirements management in traditional software development, where the actors are usually well defined, the view on requirements management tends to be more centralized, and communication channels are generally closed.

4.2.4 Artifacts

C9 focuses on the requirements repositories in SECO. For S8, requirements sharing in SECO must be expanded with relevant and authorized external actors. S14, S19, and S24 mention that there is often no central repository with requirements defined, along with heavy processes and tools for examining the requirements for completeness and consistency in SECO. According to S19, decentralized repositories (i.e., issue trackers, mailing lists, and source-code repositories) store the requirements in SECO. S19 and S24 highlight that in OSSECO, several artifacts can represent a requirement, often complementing each other to give a complete picture, i.e., as an issue, in a mail thread, and/or as a prototype or a finished implementation.

4.3 Approaches used to requirements management in SECO (RQ2)

To categorize the approaches identified in the selected studies, we used the taxonomy defined by Shaw [86] and the definitions of types of contributions cited by Paternoster et al. [71] and Dermeval et al. [25]. Shaw’s taxonomy uses some research results in SE, such as procedure or technique; model (qualitative or descriptive, empirical, analytic); tool or notation; or a specific solution (i.e., practice).

Paternoster et al. [71] also use the taxonomy described by Shaw (2003). For Paternoster et al. [71], types of contributions can be divided into weak (advises and implications, lessons learned, tools and guidelines) and strong (theory, framework/method, and model) contributions. Dermeval et al. [25] mention that its classification of approaches (type of contribution) was based on the work of Petersen et al. [72]. Dermeval et al. [25] defines method, model, tool, and process as types of approaches. Finally, we also considered the classifications of approaches defined by the authors of the selected studies. For example, S23 mentions the term “practice” to refer to the approach that the study cites. Table 8 presents the definitions of each type of approach according to Shaw [86].

The results obtained show that requirements management in SECO has been performed with the support of Tool (S4, S6, S9, S12, S13, S14, S17, S19, S20, S23, S24, S26, S27, S29); Model (S5, S7, S14, S19, S25, S28); Method (S1, S18, S24); and Practice (S23). Figure 6 shows that most of the approaches found are related to the use of tools. In the context of RQ2, the selected studies propose or cite the identified approaches. Furthermore, a unique selected study may propose or cite multiple approaches. We present more details about each type of approach in the following subsections.

Types of approaches to support requirements management in SECO

Full size image

4.3.1 Tool

S4 presents a qualitative and quantitative investigation of RE in SECO. S4 conducts a case study on SECO IBM Collaborative Lifecycle Management (IBM CLM) and cites two tools related to requirements management in SECO: Rational Team Concert (RTC) and Rational Requirements Composer (RRC). S4 also cites issue trackers, discussion forums, and other open communication channels to the public as tools that support requirements management in SECO. S17 also conducts a study related to SECO IBM CLM and demonstrates requirements flow in SECO. S17 evidences the use of RTC and cites that the tool facilitated the discussion of requirements and the creation of bug reports and change requests.

S6 proposes a framework for dealing with various aspects of SECO, called Reuse-based Software Ecosystems Engineering and Management (ReuseSEEM). The study highlights the need to create tools that map socio-technical networks to manage the needs, platform requirements, and SECO products and services. For S6, these tools allow communication and requirements management based on community participation, suggesting and solving customer needs on an extended social networking site.

S9 presents a case study of two software companies participating collaboratively and competitively in an SECO. One of the interviewers mentioned that one of the companies used the One Studio tool to record requirements change. Furthermore, client company stakeholders used a web-based request system to describe their new demands. Requests were automatically forwarded to the helpdesk service, which selected or discarded the requests. Then, company teams analyzed these demands and tracked their status in the tool, from registering the demand to fulfilling the requirements in a future release.

S12 presents a case study to analyze RE challenges in a specific SECO (AUTOSAR Ecosystem). One of the interviewees from the study pointed out that in their new project, they have started using an issue tracker for requirements management. He believed using the issue tracker has facilitated requirements management and communication. S13, S14, S19, S20, S24 S26, S27, and S29 mention issues trackers, discussion lists, and a version control system as tools that support requirements management in SECO. S23 and S27 also cite requirements portals, S29 cites Stack Overflow and social media (such as Twitter and LinkedIn), and S24 mentions source-code repositories, and code reviews to support the requirements management in SECO.

4.3.2 Model

S5 and S7 propose a requirements negotiation model in the SECO context to enrich the requirements management process. The proposal is associated with the management of the software platform and seeks to establish requirements for negotiation activities in this social context. S14 presents the Requirements Analysis and Management for Benefiting Openness (RAMBO) model. This model is used for requirements analysis and management to benefit open innovation. The model presents how the main stages of RE and requirements management processes can be adjusted to benefit from the new context’s openness.

S19 presents the model called Contribution Acceptance Process (CAP). It aims to help motivate the contribution of companies in OSSECO. Its operationalization in the organization is performed through a meta-model that integrates the requirements management infrastructure so that the contribution strategies of the primary model can be communicated and tracked. The meta-model enables inspiration and guidance on how developer organizations should implement necessary adaptations to their requirements management infrastructure or create a new one.

S25 and S28 propose a reference process model to identify key stakeholders as part of requirements elicitation in SECO. According to S25, this model can be applied by requirements managers of the common technological platform of SECO to design a business process model to identify stakeholders. In this model, requirements managers identify stakeholders they already know and document their roles in SECO. After that, they open lines of communication with the identified stakeholders (or primary stakeholders) and ask them to identify others (secondary stakeholders). S28 suggests that requirements managers of the keystone use the reference process model in their activities. The model will provide a structured approach to identifying stakeholders in complicated environments. For S28, the existing stakeholder identification methods in the literature do not take a comprehensive approach to consider all stakeholders while pinpointing only a subset from whom to elicit requirements and also with approaches that preserve SECO health, especially in SECO that include proprietary software.

4.3.3 Method

S1 mentions three ecosystem elements that constitute agile methods: barely sufficient methodology, collaborative values, and chaordic perspective. Thus, the more volatile the requirements are, and the more experimental the technology, the more agile approaches increase the chances of success in SECO. The study cites that agile methods hold significant promise to deliver greater value to all main SECO actors. For S1, agile methods in the SECO context can help in (i) technical issues: requirements and tests management, and (ii) organizational issues: process adaptation, knowledge sharing, transfer, and culture change.

S1 highlights the need for new approaches to requirements elicitation in SECO to ensure that the voice of the customer is accurately captured. S1 cites goal-oriented brainstorming and workshops as potential strategies to support agile requirements elicitation. Moreover, S1 suggests that visual specifications (high-fidelity prototypes) can be used as partial replacements for exclusively textual specifications, thus increasing the emphasis on requirements assessment. S1 also cites the user story-driven development for requirements management in SECO. According to S1, agile methods mitigate the impact of emerging changes between systems and embedded software that can unexpectedly increase the cost and duration of the development process.

S18 presents the results of an investigation into the effects of SECO in two software consumer organizations that conducted information technology management activities. In one of the cases, the study reveals that the demand management team faced challenges related to requirements management concerning the frequent “re-prioritization” of the project portfolio due to external issues. An agile method was adopted to mitigate this challenge. The study does not provide further details on use. However, it is possible to figure out that agile methods have been used to support requirements management in SECO.

S24 proposes the stakeholder influence analysis (SIA) method. SIA aims to help companies analyze an OSSECO to identify its stakeholders’ influence by their impact on the requirements implemented. The method SIA was based on social network analysis constructs that have proven useful in characterizing the influence of stakeholders but also effective when analyzing a firm’s participation in OSSECO and requirement-centric stakeholder collaborations.

4.3.4 Practice

S23 presents the Software Ecosystem Governance Maturity Model (SEG-M2). This model seeks to evaluate and classify, from the keystone, various elements of SECO in terms of governance. The model is divided into seven focus areas concentrating on a set of practices. S23 points out a practice related to requirements management, which is requirements sharing. This practice is evidenced at level 3 of the model when adopting a requirements portal (cited in Sect. 4.3.1) is recommended. Furthermore, the study mentions that implementing an open requirements management system would face technical and cultural problems in the organization. A third-party system interfaced with the company is already used internally through an application programming interface (API) and manual data copying.

In the context of RQ2, we identified the approaches to support requirements management in SECO that were proposed or cited in the selected studies. Hence, we noticed that some requirements management tools used in traditional software development also are used in the SECO context. However, the selected studies highlight several difficulties in using the SECO context. Additionally, when it comes to models, methods, or practices, none focus specifically on requirements management in SECO. The studies only cite that these approaches affect or benefit the requirements management in SECO and do not present much detail.

4.4 Assessment of approaches used to requirements management in SECO (RQ3)

RQ3 aimed to identify if (and how) the approaches to requirements management in SECO identified in RQ2 were assessed. We classified the selected studies into (i) studies that do not cite or propose approaches (S3, S8, S10, S11, S15, S16, S21, S22), (ii) studies that only cite approaches (S1, S4, S9, S12, S13, S17, S18, S20, S26, S27, S29), and (iii) studies that propose approaches to requirements management in SECO (S2, S5, S6, S7, S14, S19, S23, S24, S25, S28). We identified multiple approaches in the same study (e.g., in S24, we identified a tool and method). We also identified that some selected studies (S14, S19, S23, S24) propose a certain approach while only citing others. Thus, we classified these studies as (iii). To answer RQ3, we considered only selected studies that proposed approaches (iii).

Among the selected studies that proposed approaches (iii), we classified them into (a) studies that present assessment (S19, S23, S24) and (b) studies that do not present assessment (S2, S5, S6, S7, S14, S25, S28). Among those that do not present an assessment, some mention the need for future assessment (S2, S6, S7, S25, S28).

We use the empirical research methods in SECO described by Abdullai et al. [3] and empirical research methods in SE described by Wohlin et al. [100] to categorize our results. Abdullai et al. [3] enumerate nine research methods used in SECO: (a) Case study; (b) Mixed methods; (c) Design science; (d) Survey; (e) Longitudinal study; (f) Experimental study; (g) Exploratory study; (h) Interview; and (i) Repository mining. Wohlin et al. [100] enumerate four research methods used in SE: (a) controlled experiment; (b) case study; (c) survey; and (d) postmortem analyses.

S19 defines the model described from the collaboration of Sony Mobile professionals. However, the authors conducted three exploratory case studies to evaluate it, verifying its usability and applicability. The companies that participated in the validation were: (i) a small company that creates a platform product in the agricultural domain, the Chief Technical Officer (CTO) was interviewed; (ii) a small business that creates games for mobile platforms, the founder was interviewed; and (iii) a large company in the field of telecommunications, a workshop with 8 participants was held. From the three evaluations, the study concludes that the model can be applied to a set of features, a product, or a complete project.

S23 assesses in six case studies with professionals from the following companies and/or platforms the model and practices presented: (i) platform for augmented reality that provides API through an extension from Unity; (ii) enterprise resource planning company; (iii) credit management company; (iv) network equipment manufacturer; (v) platform specifically designed to facilitate the ecosystem of the company mentioned in item iv; and (vi) a business-to-business platform that allows telecommunications providers to build their ecosystems. First, they applied the model to companies and assessed whether it was valid, functional, and effective. The overall conclusion of the evaluation showed that the model is a valuable collection of practices that enable decision-making regarding governance in SECO.

S24 conducted a case study on the Apache Hadoop OSSECO. S24 applied a proof of concept to demonstrate that the model is functional and practical. The Apache Hadoop OSSECO was chosen due to the high concentration of firms in the ecosystem and because it is the Apache project with the highest number of committers. The case study further helped to evolve and refine the model and its seven steps.

The results presented in Sect. 4 provided some insights that will be discussed in this section. Initially, we discuss the results obtained with the RQ responses with the RE and SECO literature in other contexts. Next, we discuss how other RE activities influence or are influenced by requirements management in SECO. Finally, we discuss why the selected studies find requirements management challenging in SECO.

5.1 Characteristics and approaches of requirements management in SECO

In Sect. 4.2, we identified nine characteristics of requirements management in SECO. Some of these characteristics relate to challenges and concepts emerging from RE. C1 to C3 and C9 refer to the openness and informality of requirements management in SECO, among other aspects. According to S16, SECO are inherently open, to some extent, which influences requirements management activities. Openness in RE processes is also discussed in the context of open-source software (OSS) projects, which can form OSSECO. Iyer and Lyytinen [43] point out that RE processes in OSS projects are less formal and reliant on online documentation and communication tools.

We notice that the open innovation paradigm is explored in requirements management in SECO. Open innovation has been linked to both SECO and RE in the literature. Hanssen and Dybå [38] cite that the emergence of SECO relates to the inherent potential for open innovation. Linåker et al. [61] highlight that RE needs to consider the implicit changes in open innovation and adapt to this new context. Yin and Pfahl [105] cite that the application of open innovation strategies in RE is little investigated and that there is no support from proprietary tools for open innovation in RE.

We look deeper at openness and open innovation in requirements management in SECO and identify their relationship to emerging concepts in RE. S20 and S22, for example, discuss the ubiquitous RE in the context of digital transformation involving the formation of SECO. S20 and S22 envision RE in multiple dimensions (i.e., RE everywhere, RE with everyone, RE for everything, automated RE, open RE, and cross-domain RE), resulting in the digital transformation of RE itself into ubiquitous RE. In these dimensions, S20, S22, and S26 highlight the importance of the CrowdRE paradigm for requirements management in SECO. CrowdRE refers to an emerging paradigm that promotes the active involvement of a “crowd” of stakeholders, including current and potential users of a software product [36].

S26 mentions that RE in SECO involves a crowd that includes different types of users, external developers, and the keystone. According to S26, CrowdRE in SECO brings new opportunities and challenges for keystones and its partners. S22 highlights that traditional requirements elicitation techniques, such as interviews or focus groups, present scalability problems in SECO. For S22, the CrowdRE paradigm addresses typical problems experienced in RE in SECO (i.e., involvement of multiple actors and the lack of scalability of RE) using global automation to perform with a crowd. According to S20, in heterogeneous and dispersed settings that include a crowd, such as SECO, allowing anyone to provide potential requirements can be more effective than involving only a selection of representative end users or applying personas. S20 states that CrowdRE help address RE challenges in a social context such as SECO.

Current works have investigated CrowdRE in different contexts. Abdullah et al. [1] present research efforts and challenges in CrowdRE and conclude that researchers in CrowdRE continually explore the research area and propose new techniques and tools to improve it. Tizard et al. [90] state that researchers found relevant information about requirements in feedback from multiple online communication channels, including app stores, social media, and product forums. For Wouters et al. [102], CrowdRE expands the reach of established RE approaches, which involve a selected sample of stakeholders, extending the notion of market-driven RE toward the democratic participation of users in RE. Gómez et al. [37] demonstrate that a SECO designed to leverage different types of crowds greatly benefits all actors in the ecosystem. The growing trend in CrowdRE research indicates that this field has more room to be improved and explored, including the context of SECO.

C4 to C8 highlight the existence of geographically distributed multi-party actors groups that influence requirements management in SECO. Geographical distribution has been studied in the context of the GSD. Ali and Lai [7] cite that organizations collaborate with software teams worldwide in GSD. GSD collaboration can be inter-organizational, intra-organizational, and of mixed nature (inter+intra). The authors indicated a significant difference between the number of intra and inter-organizational collaborations due to management and communication processes, which often differ in inter-organizational setups. S21 identifies one of the main differences between teams distributed in traditional organizations and SECO. In SECO, the teams or actors are not within the same company or organization but are spread across several organizations. Each actor contributes different elements to the system or product.

In RQ2, we identified approaches to support requirements management in SECO, and the most cited was “Tool.” Several selected studies mentioned using “issue trackers” as a tool to support requirements management in SECO. CrowdRE explores the “issue trackers” as a source of feedback. Ali Khan et al. [8] propose a CrowdRE framework. The framework can be applied in issue trackers to identify or respond to critical issues. Cleland-Huang [20] mentions that the use of digital technologies as tools have brought about disruptive changes in all domains, widely known as “digital transformation.” For Cleland-Huang [20], disruptive change is a powerful force that explodes on the scene, introducing a new dominant solution or an unprecedented practice.

Regarding methods in RQ2, we identified that agile methods had been used to support requirements management in SECO. Cleland-Huang [20] highlights that agility is just one example of a disruptive change that significantly impacts RE. Disruptive changes bring unprecedented opportunities for innovation. In addition, the author argues that the widespread adoption of agile methods across multiple project domains threatens many of the existing true practices associated with requirements management. However, for the author, there is an industrial tendency to move away from “traditional” requirements processes in the digital transformation scenario.

Jayatilleke and Lai [46] differentiate requirements change management between traditional and agile software development. In addition, they cite challenges for these two contexts. In our work, we noticed that there are initiatives to use agile methods to help manage requirements in SECO, despite the additional disruptions in new ways of software development and emerging contexts such as SECO. Hence, when discussing requirements management challenges in SECO, we relate them to some challenges identified by Jayatilleke and Lai [46]. For example, we highlight the challenges related to requirements communication are different in SECO. We also note that the analysis of how organizations make decisions presented by Jayatilleke and Lai [46] focuses on the context of a single organization. In the results of our work, we extend the analysis to a requirements management context that goes beyond the limits of organizational boundaries, as happens in SECO.

Santos and Werner [82] mention that SECO emerged to improve software reuse in the GSD industry, considering the relationships between companies and stakeholders worldwide. The authors also observe that the SECO vision has motivated the leading players in the sector to rethink their operational actions to open their platforms to external agents and keep their businesses alive. S29 points out that success no longer depends solely on keystone’s efforts to manage end user expectations of its offering. Instead, it works with a more complex set of business relationships within the SECO. The situation becomes even more complex when these relationships include collaboration between competitors, that is, a state of competition. S21 points out that in SECO, several types of relationships exist between actors, which can be competitors or share mutual benefits about requirements. The complexity of relationships and dependencies increases with the number of stakeholders in the ecosystem.

5.2 Requirements engineering activities related to requirements management in SECO

Vegendla et al. [96] investigated RE activities in SECO and divided RE into five activities: requirements elicitation, requirements analysis, requirements specification, requirements validation, and requirements management. In our SMS, we characterize requirements management in SECO. We use the definition of ISO/IEC/IEEE [41], which considers requirements management an organized process of documentation, analysis, traceability, prioritization, change control, and communication of requirements. However, when answering our RQ, we noticed that other RE activities influence or are influenced by requirements management in SECO. Table 9 presents the citation frequency in the selected studies of other RE activities related to requirements management in SECO.

5.2.1 Requirements elicitation

S25 focuses on one aspect of requirements management in SECO, identifying stakeholders as a preliminary step of requirements elicitation. S25 considers that the first step of requirements management is requirements elicitation, but it is imperative to know from whom the requirements should be elicited before that. According to Lim et al. [56], digital transformation has spawned new opportunities for requirements elicitation in different contexts. The authors highlight that currently, requirements elicitation can consider an unprecedented and increasing amount of high-velocity and heterogeneous data. Vegendla et al. [96] highlight that the platform’s openness in SECO allows everyone to provide the requirements without role identification.

According to Vegendla et al. [96], requirements elicitation involves identifying SECO members’ requirements according to their business goals and can be considered a challenging issue. Fricker et al. [33] mention that large organizations need to consider the interaction of several actors to define the requirements of their products and commercial platforms. However, conventional requirements elicitation techniques are not sufficiently scalable or capable of considering stakeholder groups that are becoming increasingly large and global [56, 91]. For S1 and S7, requirements elicitation requires new approaches that must provide mechanisms to capture the customer’s voice. We consider that the scalability that SECO requires in requirements elicitation approaches also affects requirements management, mainly concerning change control and traceability.

5.2.2 Requirements analysis

Our results show that requirements management and analysis strongly relate to SECO. Vegendla et al. [96] cite that requirements analysis and management should be conducted in parallel to handle the conflicts and ambiguity in the requirements. However, S9 mentions that companies participating in SECO perform requirements analysis differently. Alsanoosy et al. [9] mention the influence of culture on requirements analysis. For the authors, each culture relies on its context to interpret and understand information. Finally, Oriol et al. [70] state that SECO health objectives are achieved as part of a requirements analysis and refinement process with the stakeholders.

We consider that requirements management and analysis must jointly and continually control changes and requirements status considering the open and dynamic environment of SECO. Nonetheless, S14 points out that the challenge of requirements analysis in SECO is the analysis of requirements with openness in mind. For the authors, from this broader perspective, requirements analysis should calculate the probability of completion if someone else in the ecosystem contributes to co-development or analyzes optimistic or pessimistic scenarios with or without other contributions within the same SECO.

5.2.3 Requirements specification

S24 points out that multi-party actors dispersed geographically collaboratively conduct the requirements specification at SECO. Vegendla et al. [96] cite several works on SECO modeling related to the requirement specification and highlight the importance of GSD in SECO. In this scenario, S19 mentions the difficulty of specifying requirements linked to different repositories of software artifacts within a global requirements management infrastructure in SECO. For Ali and Lai [6], social, linguistic, geographic, and cultural differences in GSD make it challenging to understand poorly written requirements specifications by introducing pauses and delays in communication. We consider that this is not different in the SECO context. However, we emphasize that SECO’s open and inter-organizational environment makes this scenario even more difficult.

S18 mentions the need to develop formal requirements specifications that consider the specificities of the ecosystem platform to assist in decision-making in SECO. Shahzad et al. [85] state that it is necessary to consider the properties of ecosystems, such as sustainability, contribution, and incentives in requirements elicitation and specification. The authors justify that people usually have requirements for socio-technical systems, and such a system consists of several different actors (e.g., other people and machines). In addition, according to the authors, most socio-technical systems are operated for an extended period, and they should be improved and sometimes adapted to the current situation.

5.2.4 Requirements validation

S14 highlights that informalism facilitates social interaction in requirements management in SECO and supports requirements validation. S20 mentions that using crowdsourcing techniques that include crowd members was essential for collaborative and systematic requirements validation in SECO. Vegendla et al. [96] cite that there are few studies on requirements management and validation in SECO. Nevertheless, for the authors, without validation and management of the requirements, the consistency and completeness of the requirements and models and the changes in the requirements are not ensured. For Kamalrudin and Sidek [48], the requirements validation process in the context general of software development needs to consider consistency, completeness, and correctness for producing software specifications.

Cysneiros and Zisman [23] claim that requirements traceability, an activity of requirements management, supports requirements validation in traditional software development. In turn, Vegendla et al. [96] state that requirements traceability is a significant task to provide requirements changes in SECO. However, according to the authors, more research should be performed for requirements validation and traceability in SECO. Che and Perry [19] state that SECO need efficient automated traceability between system drivers (such as requirements, business, and market needs) and architecture design decisions. Nonetheless, the authors also point out that extensive research is still required on architectural knowledge traceability to SECO.

5.3 Challenges of requirements management in SECO

During data extraction and synthesis to answer RQ1, we found that 16 of the 29 selected studies in our SMS (S2, S4-S7, S9, S14, S15, S17, S20, S21, S25-S29) consider requirements management (or some related activity) a challenge in SECO. Thus, we realized that the main challenges pointed out by the selected studies are related to the characteristics of requirements management in SECO (Table 7). Table 10 presents the relationship between the identified challenges and the characteristics of requirements management in SECO. Table 11 illustrates some examples of coherent units we define to answer RQ1. The rest of the coherent units are available in the RQ1 complete coding process, which is available at ZENODO.^{Footnote 11} Then, we detail and discuss the challenges.

S5 mentions that the SECO approach brings new challenges to RE. S6 states that requirements communication and management in SECO are challenging. For S2, S5, S6, and S20, requirements communication is challenging, especially when multiple actors must collaborate in dispersed locations in the GSD scenario. In the GSD context, Qureshi et al. [73] mention several challenges related to requirements communication as “inadequate use of informal communication” and “inadequate transfer of information.” Several works consider the requirements communication between stakeholders in distributed geographic locations as a challenge [2, 11, 46, 103]. In addition, S4 points out that requirements need to be communicated and understood by all relevant stakeholders in SECO and identifies this as a challenge. S15 reports that there are challenges in establishing centralized requirements communication in SECO. For S21, S26, and S27, requirements communication in SECO is challenging due to multiple communication channels.

S14 cites challenging aspects that open innovation brings to requirements identification in SECO. For S5, S25, and S28, the number of SECO stakeholders may become too large, which presents a challenge for requirements identification. Lim et al. [56] highlight that conventional elicitation techniques are often time-consuming and not sufficiently scalable for considering stakeholder groups that are becoming increasingly large and global. For Lim et al. [56], CrowdRE is an excellent example of dealing with this challenge. The authors cite that the primary focus of CrowdRE is the requirements identification from explicit crowd users’ feedback (e.g., app reviews and data from social media) by applying various techniques based on machine learning and natural language processing.

S5 cites that the existence of multi-party actors introduces challenges to requirement management in SECO. S17 points out that connecting the right actors to clarify requirements in SECO is difficult. S21 mentions that the coordination between multi-party actors has already been identified as a significant challenge in agile and large-scale distributed teams. However, for S21, this challenge cannot be taken similarly in SECO because each actor has a way of working that can hardly be standardized. This results in several different practices being applied across the ecosystem. In addition, S21 highlights that it is necessary to consider that the actors in SECO do not belong to a single organization but to many organizations that share different, possibly competing relationships (coopetition). Roth et al. [74] explore open coopetition, i.e., open innovation cooperation between competitors that includes third parties such as networks, platforms, communities, ecosystems, or triple helices. The authors suggest using open innovation management principles to deal with open coopetition.

S14, S17, and S29 mention that openness brings RE-related challenges in SECO. S14 cites the challenge of analyzing requirements with openness in mind. For S14, in an open perspective, the requirements analysis should calculate the probability of completion of the implementation of the requirements if someone from the ecosystem contributes in co-development or analyzes optimistic or pessimistic scenarios with or without other contributions within the same ecosystem. S17 points out that openness brings challenges related to requirements engineering in SECO, such as managing dynamic and emerging contributions from ecosystem stakeholders and collecting their input while protecting their intellectual property. Zaggl et al. [106] ensure that finding the right degree of openness is challenging, especially in complex open innovation ecosystems. For the authors, being too open involves the risk of imitation and slippage of values. Furthermore, users can gain a lot of influence on corporate decisions, leading to the challenge of requirements negotiation.

S5 points out that the SECO approach makes requirements negotiation difficult. S7 considers that the requirements negotiation in SECO is a relevant challenge for the social dimension of an ecosystem and states that it directly affects the success of a SECO. For S9, interacting with multiple partners in a SECO introduces challenges to requirements negotiation. Abdullahi et al. [2] cite the need for SECO actors to reach agreements effectively through requirements negotiation. However, for the authors, there is little understanding of how stakeholders make decisions in requirements engineering. Abdullahi et al. [2] also state that decision-making is the most challenging and difficult task in requirements negotiation in SECO. According to the authors, when making a decision, several challenges need attention before starting the negotiation. The authors cite some of them as the interaction between multiple actors in a SECO and the existence of incompatible objectives of these actors that require careful negotiation to avoid further conflicts.

S17 and S29 mention that managing emergent requirements in SECO is challenging. For S17, it is difficult to map emergent requirements to specific actors in SECO. Ailane et al. [5] cite challenges regarding emergent requirements and propose a new attempt to define the emergence phenomenon from a SE perspective. According to the authors, the emergence phenomenon is an important phenomenon that is difficult to formalize and standardize in complex systems (such as SECO).

This section presents potential threats to the validity of this study and our actions to mitigate them. The discussion builds on the guidelines for addressing threats to the validity of secondary studies provided by Ampatzoglou et al. [10]. Threats in this context can be classified as study, data, and research validity.

6.1 Study validity

Threats in this category are directly related to the study selection process. Therefore, they may lead to the omission of relevant studies or the inclusion of irrelevant studies. This potential threat includes (i) limitations in search strategy; (ii) ineffective search strings; and (iii) bias in the selection of studies that were selected in this SMS.

To mitigate (i), we applied a full-fledged hybrid search strategy (DBS + snowballing via BS and FS). Mourão et al. [67] mention that hybrid search strategies are efficient compared to the simple DBS strategy. According to Wohlin et al. [101], a full-fledged hybrid search strategy is better than other alternative hybrid strategies. In addition, we run searches in seven digital libraries, including Scopus, which index works from several other digital libraries. Then, we selected 29 studies in our SMS. Therefore, in this category, we emphasize the limitation regarding the generalization of the results. To mitigate (ii), we used two control studies to evaluate the quality and comprehensiveness of our search string. To mitigate (iii), our study had the participation of four researchers, two of them with more than ten years of experience in conducting secondary studies, which helped in conducting the activities. Two researchers applied the IC and EC independently, and two more experienced researchers evaluated the results. Regarding disagreements, a consensus was sought between the parties.

6.2 Data validity

The data extraction and synthesis process can threaten the data’s validity, as it could lead to dubious results and conclusions. This potential threat includes (i) unverified data extraction and (ii) researcher bias during the data extraction and synthesis. To mitigate (i), we documented all data transformations so that it is possible to trace the synthesis back to the corresponding selected study. Concerning (ii), two researchers performed data extraction independently. Afterward, the same two researchers performed a joint analysis, and finally, they condensed the data. Later in this process, two other more experienced researchers verified the result.

6.3 Search validity

The lack of auditing and the difficulty in replicating the research threaten the validity of the research. These threats are related to (i) lack of documentation on study planning and (ii) lack of justification for changes made during the conduct of the study. To mitigate (i) and (ii), we defined a detailed protocol based on well-established guidelines of Kitchenham and Charters [50]. Finally, we analyzed, justified, and documented all necessary changes that occurred during the conduct of this study.

Motivated by the results of this SMS, we suggest a research agenda inspired by the work of Santos et al. [75] and Santos and Carvalho [76], where some issues raised during the SMS can investigate in the future:

1. 1.

   How can CrowdRE, open innovation, and ubiquitous RE support requirements management in software ecosystems?

2. 2.

   How can the different requirements (product, platform, and integration) be managed for different types of software ecosystems (open, proprietary, and hybrid software ecosystems)?

3. 3.

   Are the requirements management approaches identified in this SMS sufficient to support the problems and specificities of different types of software ecosystems (open, proprietary, and hybrid software ecosystems)? How to assess or adapt them?

4. 4.

   How to carry out requirements traceability in software ecosystems considering the characteristics of requirements management in software ecosystems?

5. 5.

   How to monitor emergent requirements flows in software ecosystems and manage such requirements in conjunction with other requirements?

6. 6.

   How to perform the requirements change control in software ecosystems considering the changes requested in multiple open communication channels by multi-party actors?

In this study, we characterize requirements management in the SECO context. We define specific characteristics (process elements, i.e., concepts/definitions, activities, actors’ relationships, and artifacts) that differentiate requirements management in SECO from requirements management in traditional software development. In addition, we identify approaches (types of contributions, i.e., methods, techniques, tools, and practices) to support requirements management in SECO. To do so, we conducted an SMS to identify studies related to the topic in the literature.

From a total of 1028 studies retrieved in DBS and 1458 studies retrieved in snowballing, we selected 29 studies for data extraction. Of the 29 selected studies, 25 contributed to defining characteristics of requirements management in SECO, and 21 cited/proposed one or more support approaches to requirements management in SECO. Only ten of 21 studies proposed a specific approach, and only three presented the evaluation.

We defined nine characteristics of requirements management in SECO that differentiate it from requirements management in traditional software development. Requirements management at SECO is open, informal, collaborative, and decentralized. It is influenced by geographically dispersed multi-party actors affected by power relations. We emphasize that some of these characteristics may have already been identified in other software development contexts, such as OSS, GSD, and agile development. However, we emphasize that the SECO context differs mainly because it allows a holistic view of an ecosystem formed by different projects, products, networks of actors, and artifacts. Thus, in SECO, it is possible for multi-party actors geographically distributed to conduct OSS projects and to implement different development practices, including agile development.

Among the found approaches, we identified that tools (14 studies) and models (6 studies) were the most frequent in the selected studies. However, we observed that most of the approaches identified were not focused only on requirements management. This can happen due to the transversal character of requirements management in RE activities. Case studies assessed a few of these approaches (3 studies). In addition, we identified different types of SECO in the studies selected in our SMS (i.e., automotive SECO, MSECO, OSSECO), which highlights the scope of this terminology for several scenarios.

Finally, based on the knowledge built from this SMS, we defined a research agenda that presents research topics that can help understand requirements management activities in SECO and the approaches used for their realization. As a result, in future research, we will investigate in a more directed way the different requirements flows and their characteristics, considering the different dimensions of an SECO. Furthermore, after investigating the requirements flows, we can propose a specific approach to support requirements management in the SECO context.