Abstract Context: Software-intensive organizations’ rationale for sharing Open Source Software (OSS) may be driven by both idealistic, strategic and commercial objectives, and include both monetary as well as non-monetary benefits. To gain the potential benefits, an organization may need to consider what they share and how, while taking into account risks, costs and other complexities. Objective: This study aims to empirically investigate objectives and complexities organizations need to consider and balance between when deciding on what software to share as OSS, when to share it, and whether to create a new or contribute to an existing community. Method: A multiple-case study of three case organizations was conducted in two research cycles, with data gathered from interviews with 20 practitioners from these organizations. The data was analyzed qualitatively in an inductive and iterative coding process. Results: 12 contribution objectives and 15 contribution complexities were found. Objectives include opportunities for improving reputation, managing suppliers, managing partners and competitors, and exploiting externally available knowledge and resources. Complexities include risk of loosing control, risk of giving away competitive advantage, risk of creating negative exposure, costs of contributing, and the possibility and need to contribute to an existing or new community. Conclusions: Cross-case analysis and interview validation show that the identified objectives and complexities offer organizations a possibility to reflect on and adapt their contribution strategies based on their specific contexts and business goals.

For a firm in an open source software (OSS) ecosystem, the requirements engineering (RE) process is rather multifaceted. Apart from its typical RE process, there is a competing process, external to the firm and inherent to the firm’s ecosystem. When trying to impose an agenda in competition with other firms, and aiming to align internal product planning with the ecosystem’s RE process, firms need to consider who and how influential the other stakeholders are, and what their agendas are. The aim of the presented research is to help firms identify and analyze stakeholders in OSS ecosystems, in terms of their influence and interactions, to create awareness of their agendas, their collaborators, and how they invest their resources. To arrive at a solution artifact, we applied a design science research approach where we base artifact design on the literature and earlier work. A stakeholder influence analysis (SIA) method is proposed and demonstrated in terms of applicability and utility through a case study on the Apache Hadoop OSS ecosystem. SIA uses social network constructs to measure the stakeholders’ influence and interactions and considers the special characteristics of OSS RE to help firms structure their stakeholder analysis processes in relation to an OSS ecosystem. SIA adds a strategic aspect to the stakeholder analysis process by addressing the concepts of influence and interactions, which are important to consider while acting in collaborative and meritocratic RE cultures of OSS ecosystems.

The communication of requirements within software development is vital for project success. Requirements engineering and testing are two processes that when aligned can enable the discovery of issues and misunderstandings earlier, rather than later, and avoid costly and time-consuming rework and delays. There are a number of practices that support requirements-test alignment. However, each organisation and project is different and there is no one-fits-all set of practices. The software process improvement method called Gap Finder is designed to increase requirements-test alignment. The method contains two parts: an assessment part and a prescriptive part. It detects potential communication gaps between people and between artefacts (the assessment part), and identifies practices for mitigating these gaps (the prescriptive part). This paper presents the design and formative evaluation of the prescriptive part; an evaluation of the assessment part was published previously. The Gap Finder method was constructed using a design science research approach and is built on the Theory of Distances for Software Engineering, which in turn is grounded in empirical evidence from five case companies. The formative evaluation was performed through a case study in which Gap Finder was applied to an on-going development project. A qualitative and mixed-method approach was taken in the evaluation, including ethnographically-informed observations. The results show that Gap Finder can detect relevant communication gaps and seven of the nine prescribed practices were deemed practically relevant for mitigating these gaps. The project team found the method to be useful and supported joint reflection and improvement of their requirements communication. Our findings demonstrate that an empirically-based theory can be used to improve software development practices and provide a foundation for further research on factors that affect requirements communication.

Despite growing interest of Open Innovation (OI) in Software Engineering (SE), little is known about what triggers software organizations to adopt it and how this affects SE practices. OI can be realized in numerous of ways, including Open Source Software (OSS) involvement. Outcomes from OI are not restricted to product innovation but also include process innovation, e.g. improved SE practices and methods. This study explores the involvement of a software organization (Sony Mobile) in OSS communities from an OI perspective and what SE practices (requirements engineering and testing) have been adapted in relation to OI. It also highlights the innovative outcomes resulting from OI. An exploratory embedded case study investigates how Sony Mobile use and contribute to Jenkins and Gerrit; the two central OSS tools in their continuous integration tool chain. Quantitative analysis was performed on change log data from source code repositories in order to identify the top contributors and triangulated with the results from five semi-structured interviews to explore the nature of the commits. The findings of the case study include five major themes: i) The process of opening up towards the tool communities correlates in time with a general adoption of OSS in the organization. ii) Assets not seen as competitive advantage nor a source of revenue are made open to OSS communities, and gradually, the organization turns more open. iii) The requirements engineering process towards the community is informal and based on engagement. iv) The need for systematic and automated testing is still in its infancy, but the needs are identified. v) The innovation outcomes included free features and maintenance, and were believed to increase speed and quality in development. Adopting OI was a result of a paradigm shift of moving from Windows to Linux. This shift enabled Sony Mobile to utilize the Jenkins and Gerrit communities to make their internal development process better for its software developers and testers.

Change Impact Analysis (CIA) during software evolution of safety-critical systems is a labor-intensive task. Several authors have proposed tool support for CIA, but very few tools were evaluated in industry. We present a case study on ImpRec, a recommendation System for Software Engineering (RSSE), tailored for CIA at a process automation company. ImpRec builds on assisted tracing, using information retrieval solutions and mining software repositories to recommend development artifacts, potentially impacted when resolving incoming issue reports. In contrast to the majority of tools for automated CIA, ImpRec explicitly targets development artifacts that are not source code. We evaluate ImpRec in a two-phase study. First, we measure the correctness of ImpRec's recommendations by a simulation based on 12 years' worth of issue reports in the company. Second, we assess the utility of working with ImpRec by deploying the RSSE in two development teams on different continents. The results suggest that ImpRec presents about 40 percent of the true impact among the top-10 recommendations. Furthermore, user log analysis indicates that ImpRec can support CIA in industry, and developers acknowledge the value of ImpRec in interviews. In conclusion, our findings show the potential of reusing traceability associated with developers' past activities in an RSSE.

Deciding the optimal project scope that fulfills the needs of the most important stakeholders is challenging due to a plethora of aspects that may impact decisions. Large companies that operate in rapidly changing environments experience frequently changing customer needs which force decision makers to continuously adjust the scope of their projects. Change intensity is further fueled by fierce market competition and hard time-to-market deadlines. Staying in control of the changes in thousands of features becomes a major issue as information overload hinders decision makers from rapidly extracting relevant information. This paper presents a visual technique, called Feature Survival Charts+ (FSC+), designed to give a quick and effective overview of the requirements scoping process for Very Large-Scale Requirements Engineering (VLSRE). FSC+ were applied at a large company with thousands of features in the database and supported the transition from plan-driven to a more dynamic and change-tolerant release scope management process. FSC+ provides multiple views, filtering, zooming, state-change intensity views, and support for variable time spans. Moreover, this paper introduces five decision archetypes deduced from the dataset and subsequently analyzed and the atomic decision visualization that shows the frequency of various decisions in the process. The capabilities and usefulness of FSC+, decision patterns (state changes that features undergo) and atomic decision visualizations are evaluated through interviews with practitioners who found utility in all techniques and indicated that their inherent flexibility was necessary to meet the varying needs of the stakeholders.

In recent years Open Innovation (OI) has gained much attention and made firms aware that they need to consider the open environment surrounding them. To facilitate this shift Requirements Engineering (RE) needs to be adapted in order to manage the increase and complexity of new requirements sources as well as networks of stakeholders. In response we build on and advance an earlier proposed software engineering framework for fostering OI, focusing on stakeholder management, when to open up, and prioritization and release planning. Literature in open source RE is contrasted against recent findings of OI in software engineering to establish a current view of the area. Based on the synthesized findings we propose a research agenda within the areas under focus, along with a framing-model to help researchers frame and break down their research questions to consider the different angles implied by the OI model.

Abstract Lead time, defined as the duration between the moment a request was filed and the moment the decision was made, is an important aspect of decision making in market‐driven requirements engineering. Minimizing lead time allows software companies to focus their resources on the most profitable functionality and enables them to remain competitive within the quickly changing software market. Achieving and sustaining low decision lead time and the resulting high decision efficiency require a better understanding of factors that may affect both decision lead time and outcome. In order to identify possible factors, we conducted an exploratory two‐stage case study that combines the statistical analysis of seven possible relationships among decision characteristics at a large company with a survey of industry participants. Our results show that the number of products affected by a decision increases the time needed to make a decision. Practitioners should take this aspect into consideration when planning for efficient decision making and possibly reducing the complexity of decisions. Our results also show that when a change request originates from an important customer, the request is more often accepted. The results provide input into the discussion of whether a large company should focus on only a few of its large customers and disregard its significantly larger group of small customers. The results provide valuable insights for researchers, who can use them to plan research of decision‐making processes and methods, and for practitioners, who can use them to optimize their decision‐making processes. In future work, we plan to investigate other decision characteristics, such as the number of stakeholders involved in the discussion about the potential change or the number of dependencies between software components. Copyright © 2015 John Wiley & Sons, Ltd.

In order to create a successful software product and assure its quality, it is not enough to fulfill the functional requirements, it is also crucial to find the right balance among competing quality requirements (QR). An extended, previously piloted, interview study was performed to identify specific challenges associated with the selection, tradeoff, and management of QR in industrial practice. Data were collected through semistructured interviews with 11 product managers and 11 project leaders from 11 software companies. The contribution of this study is fourfold: First, it compares how QR are handled in two cases, companies working in business-to-business markets and companies that are working in business-to-consumer markets. These two are also compared in terms of impact on the handling of QR. Second, it compares the perceptions and priorities of QR by product and project management, respectively. Third, it includes an examination of the interdependencies among quality requirements perceived as most important by the practitioners. Fourth, it characterizes the selection and management of QR in downstream development activities.

Requirements prioritization is recognized as an important but challenging activity in software product development. For a product to be successful, it is crucial to find the right balance among competing quality requirements. Although literature offers many methods for requirements prioritization, the research on prioritization of quality requirements is limited. This study identifies how quality requirements are prioritized in practice at 11 successful companies developing software intensive systems. We found that ad-hoc prioritization and priority grouping of requirements are the dominant methods for prioritizing quality requirements. The results also show that it is common to use customer input as criteria for prioritization but absence of any criteria was also common. The results suggests that quality requirements by default have a lower priority than functional requirements, and that they only get attention in the prioritizing process if decision-makers are dedicated to invest specific time and resources on QR prioritization. The results of this study may help future research on quality requirements to focus investigations on industry-relevant issues.

Communication is essential for software development as its efficiency throughout the entire project life-cycle is a key factor in developing and releasing successful software products to the market. This paper reports on findings from an explanatory case study aiming at a deeper understanding of the causes and effects of communication gaps in a large-scale industrial set up. Based on an assumption of what causes gaps in communication of requirements and what effects such gaps have, a semi-structured interview study was performed with nine practitioners at a large market-driven software company. We found four main factors that affect the requirements communication, namely scale, temporal aspects, common views and decision structures. The results also show that communication gaps lead to failure to meet the customers' expectations, quality issues and wasted effort. An increased awareness of these factors is a help in identifying what to address to achieve a more efficient requirements management, and ultimately more efficient and successful software development. By closing the communication gaps the requirements may continue all the way through the project life-cycle and be more likely to result in software that meets the customers' expectations.

Summary form only given. You may think that your requirements engineering process is fairly limited and currently not too complex to manage. Or you may be right in the middle of a storm of requirements where it is impossible to manage even the most important ones comprehensively. If you are in the former situation, it may be dangerous to relax as many successful software-intensive products have a tendency to grow very rapidly in size and complexity, and sooner than you might think you may be hit by a massive flood of feature requests and too few resources to prevent the flood from drowning your development organization, which in turn put your future innovation capability and competitiveness at risk.

We present a model for supporting scoping decisions that is based on an analysis of the ROI for a given feature. Employing a ROI threshold value for making scoping decisions, the utility of the model was investigated using data from a single large project and identified a group of outlying features responsible for a disproportionate wasted investment. These initial results are promising and indicate that further investigation and validation efforts are warranted.

Scientific evaluation papers investigate existing problem situations or validate proposed solutions with scientific means, such as by experiment or case study. There is a growing amount of literature about how to report about empirical research in software engineering, but there is still some confusion about the difference between a scientific evaluation paper and other kinds of research papers. This is related to lack of clarity about the relation between empirical research, engineering, and industrial practice. In this minitutorial we give a brief rundown on how to structure a scientific evaluation papers as a special kind of research paper, using experiment reports and case study reports as examples. We give checklists of items that a reader should be able to find in these papers, and sketch the dilemmas that writers and readers of these papers face when applying these checklists.

When developing software platforms for product lines, decisions on which features to implement are affected by factors such as changing markets and evolving technologies. Effective scoping thus requires continuous assessment of how changes in the domain impact scoping decisions. Decisions may have to be changed as circumstances change, resulting in a dynamic evolution of the scope of software asset investments. This paper presents an industrial case study in a large-scale setting where a technique called feature survival charts for visualization of scoping change dynamics has been implemented and evaluated in three projects. The evaluation demonstrated that the charts can effectively focus investigations of reasons behind scoping decisions, valuable for future process improvements. A set of scoping measurements is also proposed, analyzed theoretically and evaluated empirically with data from the cases. The conclusions by the case company practitioners are positive, and the solution is integrated with their current requirements engineering measurement process.

The process of selecting requirements for a release of a software product is challenging as the decision-making is based on uncertain predictions of customer value and development cost. This paper presents a method aimed at supporting software product development organisations in the identification of process improvement proposals to increase requirements selection quality. The method is based on an in-depth analysis of requirements selection decision outcomes after the release has been launched to the users. The method is validated in two separate case studies involving real requirements and industrial requirements engineering experts. The conclusions from the two case studies are that the method seems valuable in situations with complex release planning decisions, such as in market-driven projects. It also appears essential that participants with different viewpoints attend the root cause discussion. Requirements interdependencies seem to play a big role in release planning decision-making. In addition, successful projects can also be a source of learning.

In market-driven development of product software, a crucial decision for each candidate requirement is whether or not to select it for implementation in the next release. We present an analytical model of the requirements selection process, which is used for reasoning about decision quality. A network of queues, with two classes of jobs, models the selection of requirements of different quality. The feasibility of model parameter estimation is validated in a survey involving product managers and system engineers. The results show that some of the respondents have made internally consistent parameter estimations, indicating that the model is relevant and its parameters understandable. It is also shown that a majority of the consistent respondents estimate that most of their implemented product requirements are incorrectly selected. The main objective of the model is to provide tools for evaluation of improvement proposals by estimating the impact of process change.

The task of finding an optimal selection of requirements for the next release of a software system is difficult as requirements may depend on each other in complex ways. The paper presents the results from an in-depth study of the interdependencies within 5 distinct sets of requirements, each including 20 high-priority requirements of 5 distinct products from 5 different companies. The results show that: (1) roughly 20% of the requirements are responsible for 75% of the interdependencies; (2) only a few requirements are singular; (3) customer-specific bespoke development tend to include more functionality- related dependencies whereas market-driven product development have an emphasis on value-related dependencies. Several strategies for reducing the effort needed for identifying and managing interdependencies are outlined. A technique for visualization of interdependencies with the aim of supporting release planning is also discussed. The complexity of requirements interdependency analysis is studied in relation to metrics of requirements coupling. Finally, a number of issues for further research are identified.

Software reliability is an important characteristic for most systems, but due to its dynamic properties it is hard to assess until very late in the development. Nevertheless, the testing must be planned to meet the reliability requirements. In test planning, the notion of usage coverage may be used as an indicator of reliability as they are correlated with each other. When the testing is planned, the test cases to be run and the usage profile are derived. The usage profile is estimated using the available information of the expected usage. There are therefore some uncertainties in the estimated usage profile. The paper presents and evaluates a method for analysing the impact of uncertainties in the usage profile on the usage coverage. The method is applied during test planning to evaluate how sensitive the usage coverage is to usage profile uncertainties. Different usage profiles are simulated using the expected usage profile and an uncertainty expressed as a percentage value or a range within which the changed usage profile may vary. Test cases are derived from the expected usage profile and the resulting usage coverage is estimated for each simulated usage profile. Thus the impact in the usage coverage can be analysed. The presented analysis method is illustrated with an example system. One of the conclusions from this first study of the method is that the sparseness of the usage profile, which is defined by limitations in the usage pattern, reduces the impact of the usage profile uncertainties. Further, the number of test cases is an important factor in the sensitivity to uncertainties in the usage profile.

This paper presents a collection of experience related to success factors in graduate and postgraduate education. The experiences are mainly concerned with how to make the education relevant from an industrial viewpoint. This is emphasized as a key issue in software engineering education and research, since the main objective is to give the students a good basis for large-scale software development in an industrial environment. The presentation is divided into experiences at the graduate and postgraduate levels respectively. For each level a number of strategies to achieve industrial relevance are presented. These strategies have been successful, but it is concluded that more can be done regarding industrial collaboration in the planning and conduction of experiments and case studies. Another interesting strategy for the future is a special postgraduate programme for people employed in industry.

Reuse is pin-pointed as a key factor to improve productivity and reliability of software systems. Verification and validation of software components and the resulting system is important for reuse to be beneficial on a broad industrial basis. The paper suggests a modelling approach which is suitable for reliability certification of modular systems. It discusses a general reliability certification procedure and provides guidelines and opportunities for how to certify software components and also presents some alternatives for certification of modular systems. We conclude that to create reliable systems, we must start certifying the individual constituents of the systems.

Requirements engineering and software reliability engineering both involve model building related to the usage of the intended system; requirements models and test case models respectively are built. Use case modelling for requirements engineering and operational profile testing for software reliability engineering are techniques which are evolving into software engineering practice. Approaches towards integration of the use case model and the operational profile model are proposed. By integrating the derivation of the models, effort may be saved in both development and maintenance of software artifacts. Two integration approaches are presented, transformation and extension. It is concluded that the use case model structure can be transformed into an operational profile model adding the profile information. As a next step, the use case model can be extended to include the information necessary for the operational profile. Through both approaches, modelling and maintenance effort as well as risks for inconsistencies can be reduced. A positive spin-off effect is that quantitative information on usage frequencies is available in the requirements, enabling planning and prioritizing based on that information.

The paper presents the idea of usage oriented requirements engineering, an extension of use case driven analysis. The main objective is to achieve a requirements engineering process resulting in a model which captures both functional requirements and system usage aspects in a comprehensive manner. The paper presents the basic concepts and the process of usage oriented requirements engineering, and the synthesized usage model resulting from this process. The role of this model in system development, and its potential applications are also discussed.