Krzysztof Wnuk

Continuously achieving and maintaining competitive advantage is the critical survival factor for software-intensive product development companies undergoing digitalization transformation. These companies remain uncertain if investments in business modeling is sufficient to cope with rapidly changing business models, technology, and customer demands. We conducted a Systematic Literature Review using the snow-balling methodology to explore the effects of business modeling on business flexibility and variability in the realization. Our results confirm a research gap regarding translating desired strategic flexibility into business options that can efficiently and effectively be implemented using software-based variability in the realization. We conclude that more research is needed consolidating business model innovation, experimentation , and operationalization. Building on theories for learning and knowledge creation, we propose a framework for describing change and analyzing strategic, tactical and operational choices in business model experimentation .

Agile methodologies gave teams more autonomy regarding planning tasks and executing them. As a result, coordination gets more flexible, but much relevant knowledge remains undocumented and inside teams' borders, due to informal communication and reduced development documentation. Since knowledge plays an essential role in software development, it is important to have effective knowledge management (KM) practices that contribute to a better knowledge resource allocation. Several KM practices have been reported in empirical studies in Agile Software Development (ASD). However, these practices are not evaluated regarding its effectiveness or how do they affect product quality. Besides, the studies do not demonstrate connections between the KM practices in the project level and the strategic level. The lack of connection between these levels can result in deviations from the company's corporate strategy, wasted resources and irrelevant knowledge acquisition. This paper discusses how the strategic management can contribute to an integrated approach to KM in ASD; considering the organizational structure and the corporate strategy. Based on this discussion, we propose research areas that may help with planning KM strategies that can have their effectiveness measured and contribute to product quality.

— In this perspective paper, we investigate the parallels between public policy and IT projects from the perspective of traditional RE practice. Using the mainstream media as an information source (as would an average citizen), over a period of approximately one year we captured documents that presented analyses of public policy issues. The documents were categorized into eight topic areas, then analyzed to identify patterns that RE practitioners would recognize. We found evidence of policy failures that parallel project failures traceable to requirements engineering problems. Our analysis revealed evidence of bias across all stakeholder groups, similar to the rise of the " beliefs over facts " phenomenon often associated with " fake news ". We also found substantial evidence of unintended consequences due to inadequate problem scoping, terminology definition, domain knowledge, and stakeholder identification and engagement. Further , ideological motivations were found to affect constraint definitions resulting in solution spaces that may approach locally optimal but may not be globally optimal. Public policy addresses societal issues; our analysis supports our conclusion that RE techniques could be utilized to support policy creation and implementation. (Abstract) Index Terms—Requirements engineering, public policy, bias, unintended consequences, mainstream media, ideology and belief, failure. (key words)

—This paper investigates methods and techniques from finance for supporting value estimation for features or requirements. We discuss the applicability and challenges associated with applying financial techniques for feature value estimation and for supporting requirements prioritization.

— Component-based software engineering is a common approach to develop and evolve contemporary software systems where different component sourcing options are available: 1) Software developed internally (in-house), 2) Software developed outsourced, 3) Commercial of the shelf software, and 4) Open Source Software. However, there is little available research on what attributes of a component are the most important when selecting new components. The object of the present study is to investigate what matters the most to industry practitioners during component selection. We conducted a cross-domain anonymous survey with industry practitioners involved in component selection. First, the practitioners selected the most important attributes from a list. Next, they prioritized their selection using the Hundred-Dollar ($100) test. We analyzed the results using Compositional Data Analysis. The descriptive results showed that Cost was clearly considered the most important attribute during the component selection. Other important attributes for the practitioners were: Support of the component, Longevity prediction, and Level of off-the-shelf fit to product. Next an exploratory analysis was conducted based on the practitioners' inherent characteristics. Nonparametric tests and biplots were used. It seems that smaller organizations and more immature products focus on different attributes than bigger organizations and mature products which focus more on Cost.

Despite the continuously increasing importance of Agile and Lean in software development, the number of studies that investigate Requirements Engineering (RE) related aspects remains low. In this paper, we report the results from a literature review about Agile and Lean requirements engineering. By performing a systematic mapping literature review, we identified 22 metrics in 18 publications. We analyzed the identified papers based on research methodology, rigor and relevance and other external attributes. We also map the identified metrics on the abstracted model for Agile and Lean development. We conclude that requirements-associated metrics are underrepresented in the literature and most of the metrics focuses on the time aspect rather than the quality aspect.

Context: Regression testing is a well-researched area. However, there is a lack of industrial application of regression testing techniques , proposed in the research. The disparity in goals and communication gaps is part of the reason. Close collaboration between industry and academia can help in bridging the gaps and resolving the disparities. Objective: The study aims at exploring the views of academics and practitioners about the regression testing goals. The purpose is to investigate the commonalities and differences in the viewpoints of the software industry practitioners and the academic researchers in this regard, and finally defining some common goals for the success of regression testing. Method: We used focus group method to elicit the regression testing goals from practitioners and researchers. 7 testing experts participated in the study. 4 participants were representing the testing practitioners, while 3 were representatives of the research community. We followed GQM (goal-question-metric) approach to conduct the study. Results: We finalized 10 regression testing goals from 43 different options, which were further restricted to 5 by the experts during the priority assignment to the goals. Later from 47 different options, we identified 10 questions (information needs) corresponding to goal "G5". Finally we identified measures corresponding to the information needs of G5. Conclusions: We observed that participation level of practitioners and researchers during the elicitation of goals and questions was same. We found a certain level of agreement between the participants regarding the regression testing definitions and goals. But there was some level of disagreement regarding the priorities of the goals. We also identified the need to implement a regression testing evaluation framework in the participating companies.

Background: Software testing benefits from the usage of Knowledge Management (KM) methods and principles. Thus, there is a need to adopt KM to the software testing core processes and attain the benefits that it provides in terms of cost, quality, etc. Aim: To investigate the usage and implementation of KM for software testing. The major objectives include 1. To identify various software testing aspects that receive more attention while applying KM. 2. To analyse multiple software testing techniques, i.e. test design, test execution and test result analysis and highlight KM involvement in these. 3. To gather challenges faced by industry due to the lack of KM initiatives in software testing. Method: A Systematic Literature Review (SLR) was conducted utilizing the guidelines for snowballing reviews by Wohlin. The identified studies were analysed in relation to their rigor and relevance to assess the quality of the results. Results: The initial resulting set provided 4832 studies. From these, 35 peer-reviewed papers were chosen among which 31 are primary, and 4 are secondary studies. The literature review results indicated nine testing aspects being in focus when applying KM within various adaptation contexts and some benefits from KM application. Several challenges were identified, e.g., improper selection and application of better-suited techniques, a low reuse rate of software testing knowledge, barriers in software testing knowledge transfer, no possibility to quickly achieve the most optimum distribution of human resources during testing, etc. Conclusions: The study brings supporting evidence that the application of KM in software testing is necessary, e.g., to increase test effectiveness, select and apply testing techniques. The study outlines the testing aspects and testing techniques that benefit their users.

—This papers surveys current stakeholder identification methods and techniques from the Requirements Engineering (RE) discipline. Upon critical analysis of available models and techniques, we identify the techniques that should be prioritized when identifying stakeholders that should be involved in the decision making processes about software components or assets. Next, we analyzed industrial decision scenarios and match the most prominent issues with stakeholder identification against the perceived benefits that the identified techniques offer. We conclude this paper with a research agenda in stakeholder identification for decision making about software components.

— This short paper presents an iterative and incremen-tal process to improve the probability that the product or service definition leading to requirements and implementation is both representative of the market needs and has a reasonable expectation of a financially viable business model. Rather than a relatively linear process wherein marketing delivers a product definition to the development team, this process ensures that all assumptions are validated during the definition stage and that all team members are engaged. The process balances the need to address current challenges against future opportunities, providing short-term customer satisfaction (and justification for purchasing or adoption) and a coherent vision for future development efforts (and maintaining and growing the customer base). The process is applied to a case in the agriculture commodities sector.

A common situation is that an initial architecture has been sufficient and served its purpose in the initial phases of a project, but when the size and complexity of the product scales the architecture must be changed. The main objective of this research is to present experiences from changing an architecture into independent units, providing basic reuse of main functionality although giving higher priority to independence than reuse. The objective was also to introduce metrics in order to monitor the architectural changes and to what degree the new architecture is implemented. This was studied in a case-study through weekly meetings with the team, collected metrics, and questionnaires. The new architecture was well received by the development team, perceiving it to be less fragile. Concerning the metrics for monitoring it was concluded that a high abstraction level was useful for the purpose and, when added to the processes used, helps to maintain the important characteristics of the new architecture.

— Intense competition in rapidly changing markets puts intense pressure on product definition and the associated requirements engineering processes. An extensive literature review has identified that brand inertia, customer inertia, inappropriate market entry strategies and an inability to satisfy customer needs or expectations are the principle contributors to customer product rejection. While RE practice has developed a number of methodologies for addressing aspects of the contributing factors to these failures, very little prior work has focused on the inertia aspects of the problem. In this work we present the results of our literature review and build upon this review to develop an initial framework for incorporating stakeholder inertia into RE practice and management processes. We conclude with a detailed agenda for further research into aspects of the stakeholder inertia problem is also provided.

—Requirements Engineering and Testing are considered inseparable and together enable successful projects. One could make a statement that serious negligence of any of the two will bring catastrophic consequences for the project, delays, failures and unhappy customers. Thus, alignment and cooperation between the two are not only recommended but highly required for contemporary complex software and system development. In this paper, we share some experiences from a large company that significantly downplayed requirements engineering activities while shifting the focus to testing and QA activities. Despite that, the company's products are well received by its customers and the company remains profitable and significantly growing. We share our experiences and discuss how this unbalance may actually be a recipe for success and what contextual factors enable using this approach.

—We discuss the supervision of undergraduate students conducting their master's project ("examensarbete"). We base our reflections on both literature studies and insight into practical experiences, gained in an interview with an experienced supervisor, and aim to identify guidelines for successful supervision.

—Engineers working on safety critical software development must explicitly specify trace links as part of Impact Analyses (IA), both to code and non-code development artifacts. In large-scale projects, constituting information spaces of thousands of artifacts, conducting IA is tedious work relying on extensive system understanding. We propose to support this activity by enabling engineers to reuse knowledge from previously completed IAs. We do this by mining the trace links in documented IA reports, creating a semantic network of the resulting traceability, and rendering the resulting network amenable to visual analyses. We studied an Issue Management System (IMS), from within a company in the power and automation domain, containing 4,845 IA reports from 9 years of development relating to a single safety critical system. The domain has strict process requirements guiding the documented IAs. We used link mining to extract trace links, from these IA reports to development artifacts, and to determine their link semantics. We constructed a semantic network of the interrelated development artifacts, containing 6,104 non-code artifacts and 9,395 trace links, and we used two visualizations to examine the results. We provide initial suggestions as to how the knowledge embedded in such a network can be (re-)used to advance support for IA.

— One of the goals of requirements engineering is to capture and document innovation in the form of new product requirements. These product requirements need to express new system functions or new qualities that are most desired by customers while maintaining customer familiarity with existing products. This paper explores the contradiction between the customer desire for revolutionary advancement and their desire to maintain familiarity with existing systems. This customer inertia creates a bias toward incremental (evolutionary) advancement, potentially multiplying the risks associated with revolutionary innovations. We present a review of scenarios illustrating this stakeholder bias and propose a research agenda for further work in the area.

[Context & motivation] Growing software companies with increasing product complexity face the issue of how to scale up their Requirements Engineering (RE) practices. In market-driven requirements engineering, release planning and scoping decisions are increasingly challenging as the size and complexity increases. [Problem] This paper presents initial results of an ongoing exploratory, qualitative investigation of three market-driven, industrial cases with the objective of increasing our understanding of challenges in scaling up requirements engineering and how these challenges are addressed by the studied companies. [Results] Through 13 interviews in three companies, requirements engineering scalability issues are explored related to scoping and the structure of RE artifacts. [Contribution] The main contribution are findings related to increasing RE scale based on interpretations of the experienced interviewees' views.

In the software industry, there is a strong shift from traditional phase-based development towards agile methods and practices. This paper reports on a case study aimed at investigating if, and how, agile Requirements Engineering (RE) can remedy the challenges of traditional RE, and what new challenges agile RE may pose. The results from an initial case study with 9 practitioners from a large software development company, which is transitioning towards agile-inspired processes, show that agile practices address some RE challenges such as communication gaps and overscoping, but also cause new challenges, such as striking a good balance between agility and stability, and ensuring sufficient competence in cross-functional development teams.

— Efficient scope management is a core part of software release management and often a key factor in releasing successful software products to the market. In a case when not all the requirements for the next software product release are known 'a priori' and when new requirements are issued throughout the project, the risk of overscoping by including more functionality than can be implemented increases. In this paper, we report on findings from an empirical interview study about understanding the causes and effects of overscoping in a large-scale industrial set up. Six main causes of overscoping have been identified in this work, complemented by root cause analysis of the causes and concluded by effects of overscoping. The results provide an increased understanding of the scoping activity as a continuous activity and outline risks and issues that can lead to a situation of overscoping.

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

Abstr act. When large organizations develop systems for large markets the size and complexity of the work products of requirements engineering impose critical challenges. This paper presents an industrial case study with the objective to increase our understanding of large-scale requirements engineering practice. We focus on a senior requirements engineering role at our case company in the mobile handset domain, called requirements architect, responsible for quality and coordination of large requirements repositories. Based on interviews with 7 requirements architects we present typical tasks of their work. Issues in these task as well as improvements related to requirements architecting practice are identified. We also present the views of interviewees on quality attributes of a good requirements architecture should have. Our results imply several further research opportunities in large-scale requirements engineering with focus on structural and quality aspects of large requirements repositories. 1 Intr oduction Large software companies are often confronted with large and complex requirements repositories. The requirements originate from multiple sources and address multiple customers and market segments. This paper presents an industrial case study of the tasks involved in managing large and complex requirements repositories. The investigated tasks are related to a role called Requirements Architect that has recently been introduced at the case company. The requirements architects are responsible for the scope of large platform projects that products are based on [7]. Our motivation to perform this study was to understand current practices in working with large-scale requirements repositories and to find issues for future research. Due to the exploratory nature of this study a qualitative approach was applied. In this study, we have conducted interviews with requirements architects in order to address the following research questions:

Efficient variability management is a key issue in large-scale product line engineering, where products with different propositions are built on a common platform. Variability management implies challenges both on requirements engineering and configuration management. This paper presents findings from an improvement effort in an industrial case study including the following contributions: problem statements based on an interview study of current practice, an improvement proposal that addresses the challenges found, and an initial validation of the proposal based on interviews with experts from the case company.

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.

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.

In large-scale multi-project software engineering it is a challenge to provide a comprehensive overview of the complexity and dynamics of the requirements engineering process. This paper presents a visualization technique called Feature Transition Charts (FTC) that gives an overview of scoping decisions involving changes across multiple projects based on previous work on within-project visualization of feature survival. FTC is initially validated using industrial data from the embedded systems domain in a multi-project product line engineering context in dialogue with practitioners. The initial validation provided specific improvement proposals for further work and indicated a positive view on the general feasibility and usefulness of FTC.

Decision outcomes and their lead times are critical in product management, as the market success of a product may strongly depend on the both the decisions themselves and their timing in relation to the market and competitors. This paper presents an investigation of one particular industrial case study data set by comparing upstream scoping decisions with downstream change decision. The results in this case indicate that changes are more likely to be accepted during upstream decision-making compared to downstream. We also found that the most common value for upstream decision lead-time is three days, while only one day for downstream. The results trigger a general discussion on factors that may impact or explain decision lead-time. Assumptions and questions for further investigation in the context of product management decision-making are proposed.

This paper presents a method for visualizing the scoping process in platform-based development of embedded systems. The proposed visualization shows the decision process of including or excluding features that are candidates for the next release. The presented visualization charts are evaluated in a large-size embedded system platform project. The evaluation indicates that the visualization of feature survival and scope dynamics can improve the understanding of the decision process of platform scoping in real industrial projects. Future work includes dealing with the relations between features and system requirements, improving user interaction as well as visualizing statistical measures of efficiency of the scoping process.

Competitive development of complex embedded systems such as mobile phones requires management of massive amounts of complex requirements. This paper defines and discusses orders of magnitudes in RE and implications of the highest order of magnitude that we have experienced in industrial settings. Based on experiences from the mobile phone domain we propose research areas that, if addressed successfully, may help beating the complexity of Very Large-Scale Requirements Engineering.

Decision making and requirements scoping occupy central roles in helping to develop products that are demanded by the customers and ensuring company strategies are accurately realized in product scope. Many companies experience continuous and frequent scope changes and fluctuations but struggle to measure the phenomena and correlate the measurement to the quality of the requirements process. We present the results from an exploratory interview study among 22 participants working with requirements management processes at a large company that develops embedded systems for a global market. Our respondents shared their opinions about the current set of requirements management process metrics as well as what additional metrics they envisioned as useful. We present a set of metrics that describe the quality of the requirements scoping process. The findings provide practical insights that can be used as input when introducing new measurement programs for requirements management and decision making.

Continuously achieving and maintaining competitive advantage
is the critical survival factor for software-intensive product development
companies undergoing digitalization transformation. These companies
remain uncertain if investments in business modeling is sucient to
cope with rapidly changing business models, technology, and customer
demands. We conducted a Systematic Literature Review using the snowballing
methodology to explore the eects of business modeling on business

exibility and variability in the realization. Our results conrm a
research gap regarding translating desired strategic
exibility into business
options that can eciently and eectively be implemented using
software-based variability in the realization. We conclude that more research
is needed consolidating business model innovation, experimentation,
and operationalization. Building on theories for learning and knowledge
creation, we propose a framework for describing change and analyzing
strategic, tactical and operational choices in business model experimentation.

In this study, we investigate the state of the literature and practice about Value-Based Requirements Engineering. We focus on identifying what models for VBRE were presented and what challenges were discussed. We triangulate our results with industrial practitioners by conducting an industrial survey with 59 respondents. We identified 26 primary and 3 secondary studies and synthesized the findings using content analysis. VBRE was identified to be having a positive impact among survey practitioners. However, challenges like aligning product, project and organization opinions, selecting a most valuable requirement for a particular release, and including time-dependent requirements were identified to be impacting the organizations. The results from the study also suggest that, value dimensions like stakeholder value and customer value were not so frequently discussed in RE processes in both literature and among our industry respondents.

Background: Software testing benefits from the usage of Knowledge Management (KM) methods and principles. Thus, there is a need to adopt KM to the software testing core processes and attain the benefits that it provides in terms of cost, quality, etc. Aim: To investigate the usage and implementation of KM for software testing. The major objectives include 1. To identify various software testing aspects that receive more attention while applying KM. 2. To analyse multiple software testing techniques, i.e. test design, test execution and test result analysis and highlight KM involvement in these. 3. To gather challenges faced by industry due to the lack of KM initiatives in software testing. Method: A Systematic Literature Review (SLR) was conducted utilizing the guidelines for snowballing reviews by Wohlin. The identified studies were analysed in relation to their rigor and relevance to assess the quality of the results. Results: The initial resulting set provided 4832 studies. From these, 35 peer-reviewed papers were chosen among which 31 are primary, and 4 are secondary studies. The literature review results indicated nine testing aspects being in focus when applying KM within various adaptation contexts and some benefits from KM application. Several challenges were identified, e.g., improper selection and application of better-suited techniques, a low reuse rate of software testing knowledge, barriers in software testing knowledge transfer, no possibility to quickly achieve the most optimum distribution of human resources during testing, etc. Conclusions: The study brings supporting evidence that the application of KM in software testing is necessary, e.g., to increase test effectiveness, select and apply testing techniques. The study outlines the testing aspects and testing techniques that benefit their users.

[Context and motivation] Quality requirements (QRs) are inherently difficult to manage as they are often subjective, context-dependent and hard to fully grasp by various stakeholders. Furthermore, there are many sources that can provide input on important QRs and suitable levels. Responding timely to customer needs and realizing them in product portfolio and product scope decisions remain the main challenge. [Question/problem] Data-driven methodologies based on product usage data analysis gain popularity and enable new (bottom-up, feedback-driven) ways of planning and evaluating QRs in product development. Can these be efficiently combined with established top-down, forward-driven management of QRs? [Principal idea / Results] We propose a model for how to handle decisions about QRs at a strategic and operational level, encompassing product decisions as well as business intelligence and usage data. We inferred the model from an extensive empirical investigation of five years of decision making history at a large B2C company. We illustrate the model by assessing two industrial case studies from different domains. [Contribution] We believe that utilizing the right approach in the right situation will be key for handling QRs, as both different groups of QRs and domains have their special characteristics.

Selecting sourcing options for software assets and components is an important process that helps companies to gain and keep their competitive advantage. The sourcing options include: in-house, COTS, open source and outsourcing. The objective of this paper is to further refine, extend and validate a solution presented in our previous work. The refinement includes a set of decision-making activities, which are described in the form of a process-line that can be used by decision-makers to build their specific decision-making process. We conducted five case studies in three companies to validate the coverage of the set of decision-making activities. The solution in our previous work was validated in two cases in the first two companies. In the validation, it was observed that no activity in the proposed set was perceived to be missing, although not all activities were conducted and the activities that were conducted were not executed in a specific order. Therefore, the refinement of the solution into a process-line approach increases the flexibility and hence it is better in capturing the differences in the decision-making processes observed in the case studies. The applicability of the process-line was then validated in three case studies in a third company.

— Requirements Engineering (RE) has grown from its humble beginnings to embrace a wide variety of techniques, drawn from many disciplines, and the diversity of tasks currently performed under the label of RE has grown beyond that encompassed by software development. We briefly review how RE has evolved and observe that RE is now a collection of best practices for pragmatic, outcome-focused critical thinking – applicable to any domain. We discuss an alternative perspective on, and description of, the discipline of RE and advocate for the evolution of RE toward a discipline that supports the application of RE practice to any domain. We call upon RE practitioners to proactively engage in alternative domains and call upon researchers that adopt practices from other domains to actively engage with their inspiring domains. For both, we ask that they report upon their experience so that we can continue to expand RE frontiers.

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

— Open Source Software (OSS) has substantial impact on how software-intensive firms develop products and deliver value to the customers. These companies need both strategic and operational support on how to adapt OSS as a part of their products and how to adjust processes and organizations to increase the benefits from OSS participation. This work presents the key insights from the journey that Sony Mobile has made from a company developing proprietary software to a respected member of OSS communities. We framed the experiences into an Open Source Maturity Model that includes two scenarios: engineering-driven and business-driven open source. We outline the most important decisions, roles, processes and implications.

—When choosing components for software intensive systems decisions are made on multiple levels. On the highest level, the component's origin or source is chosen (e.g. In-house versus Components Off-The-Shelf), which answers the question where to get a component from. In this study we investigate how practitioners choose among the component sourcing options. The case survey method has been used to elicit and synthesize the cases. The case survey method combines the advantages of surveys (capturing a larger set of cases) and case studies (capturing rich information about each case). Overall, 22 decision cases have been obtained. Decisions were prepared in a group of people, while the actual decision was individually made by managers or decision makers. Cost, performance, and system reliability stand out as the most common criteria. More than two decision criteria are frequently considered, which has to be taken into account when supporting sourcing decisions. The final decision was perceived negatively in nine cases and positively in seven cases, while in the remaining cases it was perceived as neither positive nor negative. There exists a mismatch between industrial processes and the solution proposed with respect to number of considered criteria and methods utilized for decision making.

—Requirements Engineering has recently been greatly influenced by the way how firms use Open Source Software (OSS) and Software Ecosystems (SECOs) as a part of their product development and business models. This is further emphasized by the paradigm of Open Innovation, which highlights how firms should strive to use both internal and external resources to advance their internal innovation and technology capabilities. The evolution from market-driven requirements engineering and management processes, has reshaped the understanding of what a requirement is, and how it is documented and used. In this work, we suggest a model for analyzing and managing requirements that is designed in the context of OSS and SECOs, including the advances and challenges that it brings. The model clarifies how the main stages of requirements engineering and management processes can be adjusted to benefit from the openness that the new context offers. We believe that the model is a first step towards the inevitable adaptation of requirements engineering to an open and informal arena, where processes and collaboration are decentralized, transparency and governance are the key success factors.

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

Safety standards prescribe change impact analysis (CIA) during evolution of safety-critical software systems. Although CIA is a fundamental activity , there is a lack of empirical studies about how it is performed in practice. We present a case study on CIA in the context of an evolving automation system , based on 14 interviews in Sweden and India. Our analysis suggests that engineers on average spend 50-100 hours on CIA per year, but the effort varies considerably with the phases of projects. Also, the respondents presented different connotations to CIA and perceived the importance of CIA differently. We report the most pressing CIA challenges, and several ideas on how to support future CIA. However, we show that measuring the effect of such improvement solutions is non-trivial, as CIA is intertwined with other development activities. While this paper only reports preliminary results, our work contributes empirical insights into practical CIA.

Companies developing software are constantly striving to gain or keep their competitive advantage on the market. To do so, they should balance what to develop themselves and what to get from elsewhere, which may be software components or software services. These strategic decisions need to be aligned with business objectives and the capabilities and constraints of possible options. These sourcing options include: in-house, COTS, open source and outsourcing. The objective of this paper is to present an approach to support decision-makers in selecting appropriate types of origins in a specific case that maximizes the benefits of the selected business strategy. The approach consists of three descriptive models, as well as a decision process and a knowledge repository. The three models are a decision model that comprises three cornerstones (stakeholders, origins and criteria) and is based on a taxonomy for formulating decision models in this context, and two supporting models (property models and context models).

Context. Internet of Things (IoT) technology is significantly impacting software business. Several contributions were made in the literature regarding IoT. However, the importance of various business model elements for IoT and the impact of IoT on requirements engineering activities remains greatly unexplored. This paper focuses on the impact of IoT on software business models and requirements engineering. The objectives for this research include: 1) summarizing the current business models for IoT, 2) analyzing the impact of IoT on software business models 3) analyzing the impact of IoT on requirements engineering. We conducted a systematic snowballing literature review, followed by an industrial survey. We identified 21 peer reviewed papers which were analyzed in relation to their rigor and relevance and received 56 survey responses. The results of the literature review indicate 9 business model elements that IoT literature focus on. Morevoer, 4 business model aspects were described with respect to the business model structure, context and governance. The industrial survey results highlighted that value proposition , followed by customer segmentation and revenue streams were the most important business model elements for IoT. Moreover, the survey results suggest that requirement management, requirement prioritization and requirement modeling and analysis are highly impacted by IoT.

—In many application domains, critical systems must comply with safety standards. This involves gathering safety evidence in the form of artefacts such as safety analyses, system specifications, and testing results. These artefacts can evolve during a system's lifecycle, creating a need for impact analysis to guarantee that system safety and compliance are not jeopardised. Although extensive research has been conducted on change impact analysis and on safety evidence management, the knowledge about how safety evidence change impact analysis is addressed in practice is limited. This paper reports on a survey targeted at filling this gap by analysing the circumstances under which safety evidence change impact analysis is addressed, the tool support used, and the challenges faced. We obtained 97 valid responses representing 16 application domains, 28 countries, and 47 safety standards. The results suggest that most practitioners deal with safety evidence change impact analysis during system development and mainly from system specifications. Furthermore, the level of automation in the process is low and insufficient tool support is the most frequent challenge. Other notable findings include that the different artefact types used as safety evidence seem to co-evolve, the evolution of safety case should probably be better managed, and no commercial impact analysis tool has been reported as used for all artefact types. Finally, we identified over 20 areas where the state of the practice in safety evidence change impact analysis can be improved.

Context: Requirements scoping is one of the key activities in requirements management but also a major risk for project management. Continuously changing scope may create a congestion state in handling the requirements inflow which causes negative consequences, e.g. delays or scope creep. Objectives: In this paper, we look at requirements scoping literature outside Software Product Line (SPL) by exploring the current literature on the phenomenon, summarizing publication trends, performing thematic analysis and analyzing the strength of the evidence in the light of rigor and relevance assessment. Method: We run a Systematic Mapping Study (SMS) using snowballing procedure, supported by a database search for the start set identification, and identified 21 primary studies and 2 secondary studies. Results: The research interest in this area steadily increases and includes mainly case studies, validation or evaluation studies. The results were categorized into four themes: definitions, negative effects associated with scoping, challenges and identified methods/tools. The identified scope management techniques are also matched against the identified requirements scoping challenges.

Making the right decisions is an essential part of software ecosystem governance. Decisions related to the governance of a software ecosystem can influence the health of the ecosystem and can result in fostering the success or greatly contributing to the failure of the ecosystem. However, very few studies touch upon the decision making of software ecosystem governance. In this paper, we propose decomposing software ecosystem governance into three activities: input or data collection, decision making, and applying actions. We focus on the decision making activity of software ecosystem governance and review related literature consisted of software ecosystem governance, organizational decision making , and IT governance. Based on the identified studies, we propose a framework for defining the decision making strategies in the governance of software ecosystems. We identify five decision areas for software ecosystem governance and four archetypes describing the way decisions are taken for each decision area. We explain this matrix-based framework by providing examples from existing software ecosystems.

Context: To remain competitive, innovative and to grow, companies must change from cost-based decision-making to value-based decision-making where the decisions taken maximize software value and support company's overall value creation. Objective: The objective of this paper is to complement and expand an existing classification of value aspects within the context of product management and development with additional aspects relating to value within the context of project management and development. Method: In this study, we present the results from a snowballing literature review that focuses on software value in software project management. In the research for relevance literature we focus on software value aspects different than cost as cost is widely used in project management literature to estimate value. Results: We have identified nine primary studies in two snowball iterations. From these studies, we derived three categories of value aspects: financial, risk analysis and process improvement based on value identification.

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 K. Wnuk is with the TRANSACTIONS OF SOFTWARE ENGINEERING , VOL. XX, NO. XX, DATE 2 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+ are 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.

SUMMARY Lead time, defined as the duration between the moment a request was filed to 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 requires 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.

Free software is often declared to be a positive movement that makes technology accessible to those who might not otherwise have access. While the positive effects, to one degree or another, have often been discussed there has been relatively little discussion of the possibly negative effects of the free software movements. In general, these approaches have led to ever-increasing concentration of economic power in a smaller number of entities, the reduction of margins to the point where there is little economic incentive to investment and a general casino-like approach to software development: build it, then build a customer base and then try to find a way to monetize the customer base rather than the product. The resulting conditioning of the customer base has led to a significant reduction in the availability of venture capital for software products and a corresponding increase in the availability of venture capital for software as a means to make the customer (and not the software) the product through data analytic approaches. This short paper discusses these observed effects of free software on the software economy and possible effects on requirements engineering practice.

Test-Driven Development (TDD) is a software development approach where test cases are written before actual development of the code in iterative cycles. Context: TDD has gained attention of many software practitioners during the last decade since it has contributed several benefits to the software development process. However, empirical evidence of its dominance in terms of internal code quality, external code quality and productivity is fairly limited. Objective: The aim behind conducting this controlled experiment with professional Java developers is to see the impact of Test-Driven Development (TDD) on internal code quality, external code quality and productivity compared to Test-Last Development (TLD). Results: Experiment results indicate that values found related to number of acceptance test cases passed, McCabe's Cyclomatic complexity, branch coverage, number of lines of code per person hours, number of user stories implemented per person hours are statistically insignificant. However, static code analysis results were found statistically significant in the favor of TDD. Moreover, the results of the survey revealed that the majority of developers in the experiment prefer TLD over TDD, given the lesser required level of learning curve as well as the minimum effort needed to understand and employ TLD compared to TDD.

Context: Involving perspectives into risk analysis brings a potential to increase the efficiency of the risks analysis task and the confidence in the identified risks. Objective: The objective of the research carried out in this study is to investigate the effectiveness of perspective-based risk analysis (PBRA) method in comparison with a traditional risk analysis (TRA) method. Method: In this paper, we opted for an experimental design to investigate if the Perspective-Based Risk Analysis (PBRA) method that involves different views and perspectives is more effective and offers higher confidence than the Traditional Risks Analysis (TRA) method. 43 subjects performed risks analysis of a software-controlled train door system using either TRA or PBRA. We measured the effectiveness of the methods by counting the number of relevant and non-relevant risks. Using a questionnaire, we also assessed the difficulty of the methods and the confidence of the subjects concerning the correctness of the identified risks. Conclusions: The found results suggest that PBRA helps to identify more relevant risks than TRA. On the other hand, our experiment failed to provide supporting evidence that PBRA helps to identify fewer non-relevant risks. Contrary to expectations, this study did find with a statistical significance that PBRA is more difficult to use than TRA.

Background. Software ecosystems emerged as means for several actors to jointly provide more value to the market than any of them can do on its own. Recently, software ecosystems are more often used to support the development of hardware-dependent solutions.
Objectives. This work aims at studying barriers and bridges to participation in an ecosystem with substantial hardware dependencies.
Method. We conducted an interview-based case study of an ecosystem around Axis' network video surveillance systems, interviewing 10 internal experts and 8 external representatives of 6 companies, complemented by document studies
at Axis.
Results. Major bridges to the ecosystem include end customer demands, open and transparent communication and relationship, as well as internal and external standardizations. Barriers include the two-tier business model, entry barriers and execution performance issues. Approximately half of the identiiied bridges and barriers could be considered hardware-dependent ecosystems specific.
Conclusion. Our results suggest that ecosystem leaders should share their sales channels with the ecosystem participants and focus on good communication and relationships as the dominant factors for the ecosystem participation. Moreover,
we report that internal and external standardization can play a dual role, not only ease the development but also enable additional sales channels and new opportunities for the ecosystem participants. At the same time, the business model selected by the ecosystem leaders and performance, are identified as the main barriers to ecosystem participation. We believe that the business model barrier may be much more important for similar hardware-dependent software ecosystems.

Streszczenie Inżynieria wymagań jest ważnym działem inżynierii oprogramowania. Znaczenie inżynierii wymagań i prawidłowego przebiegu procesów zarządzania wymaganiami jest często kluczowym czynnikiem sukcesu dla projektów informatycznych. Znane są przypadki, gdzie porażka projektu wynikała z błędów podczas analizy wymagań. [1, 2, 3, 4] Świadomość i znajomość tych procesów dla współczesnych inżynierów informatyków nie zawsze jest wystarczająca. W artykule został dokonany przegląd nauczania inżynierii wymagań w programach nauczania wybranych uczelni wyższych kształcących studentów na kierunku informatyka oraz metody kształce-nia w tym zakresie. W ostatnich latach obserwuje się rozwój edukacji inżynierii wymagań nie tylko na wyż-szych uczelniach, ale również w kształceniu ustawicznym. Powstają nowe inicjatywy i organizacje szerzące wiedzę i dobre praktyki inżynierii wymagań. Na rynku pojawiają się też certyfikaty z tego obszaru wiedzy. W artykule przedstawiono jedną z takich organizacji-International Requirements Engineering Board (IREB) oraz jej podejście do procesów inżynierii wymagań i certyfikacji dostępnej od 2012 roku również w Polsce, a certyfikat IREB CPRET ma około 11 000 osób [18] Inżynieria wymagań oprogramowania jest relatywnie nowym pojęciem w informatyce. Zostało ono stworzone w celu określenia wszystkich czynności związanych z szeroko rozumianym pozyskiwaniem, doku-mentowaniem i zarządzaniem wymaganiami dla systemów komputerowych. Słowo " inżynieria " w tym kontek-ście należy rozumieć jako systematyczną i zdefiniowaną działalność zapewniająca powodzenie tych procesów. Widoczne jest tu zatem odmienne do tradycyjnego podejścia, w którym inżynieria rozumiana jest jako " używa-nie właściwości materii, energii oraz obiektów abstrakcyjnych dla tworzenia konstrukcji, maszyn i produktów, przeznaczonych do wykonywania określonych funkcji lub rozwiązania określonego problemu " [5]. W tradycyjnych podejściach do prowadzenia projektów informatycznych, takich jak V-model czy model kaskadowy zakłada się, że wszystkie wymagania zostaną zdefiniowane, a cały proces zakończy się, przed fazą projektowania i implementacji. Wymaga się, aby wszystkie wymagania zostały zdefiniowane i odpowiednio dobrze opisane. Nie dopuszcza się możliwości zmiany wymagań po ich pierwotnym ustaleniu, choć na przykład Royce dopuszcza iteracje i podkreśla rolę sprzężenia zwrotnego w procesie wytwarzania w modelu kaskadowym [19]. Metodyki zwinne określane także jako lekkie, zakładają inne podejście do pozyskiwania wymagań. W projektach prowadzonych zgodnie z ich wytycznymi dopuszcza się zmiany w trakcie trwania projektu jako jego naturalny element. W początkowej fazie definiowane się wymagania zgodne z obecnym stanem wiedzy. W czasie trwania projektu mogą one ulec zmianie, co kontrolowane jest przez wyznaczonych do tego członków zespołu.

Large market-driven software companies face new challenges in requirements
engineering and management that emerged due to their recent extensive
growth. At the same time, the pressure generated by competitors’
and users’ expectations demands being more competitive, creative and
flexible to more quickly respond to a rapidly changing market situation.
In the pursuit of staying competitive in this context, new ideas on how
to improve the current software engineering practice are requested to help
maintaining the engineering efficiency while coping with growing size and
complexity of requirements engineering processes and their products.
This thesis focuses on visualizing, analyzing and managing the scope
of software releases in large-scale requirements management for developing
software products to open markets. In particular, this thesis focuses on
the following requirements management activities in the mentioned context,
namely: scope management, and requirements consolidation. The
goals of the research effort in this thesis are to provide effective methods in
supporting mentioned requirements management activities in a situation
when the size of them and their complexity require large time and skills
efforts.
Based on empirical research, where both quantitative and qualitative
approaches were utilized, this thesis reports on improved understanding
of requirements scoping in very-large projects by investigating, factors affecting
decision making, causes and effects of oversoping and presents visualization
techniques to assist scope management for large-scale software
product development contexts. The technical solutions reported in this
thesis where empirically evaluated in case studies in a large-scale context
and designed in close collaboration with our industry partners. Additionally,
the benefits of using linguistic methods for requirements consolidation
are investigated in a replicated experimental study based on a relevant
industry scenario.

Large market-driven software companies face new challenges in requirements
engineering and management that emerged due to their recent extensive
growth. At the same time, the pressure generated by competitors’
and users’ expectations demands being more competitive, creative and
flexible to more quickly respond to a rapidly changing market situation.
In the pursuit of staying competitive in this context, new ideas on how
to improve the current software engineering practice are requested to help
maintaining the engineering efficiency while coping with growing size and
complexity of requirements engineering processes and their products.
This thesis focuses on understanding and supporting large-scale requirements
management for developing software products to open markets.
In particular, this thesis focuses on the following requirements management
activities in the mentioned context, namely: scope management,
variability management and requirements consolidation. The goals of the
research effort in this thesis are to provide effective methods in supporting
mentioned requirements management activities in a situation when the
size of them and their complexity require large time and skills efforts.
Based on empirical research, where both quantitative and qualitative
approaches were utilized, this thesis reports on possible improvements for
managing variability and presents visualization techniques to assist scope
management for large-scale software product development contexts. Both
reported ideas are empirically evaluated in case studies in a large-scale
context. Additionally, the benefits of using linguistic methods for requirements
consolidation are investigated in a replicated experimental study
based on a relevant industry scenario.

Every student that is conducting the master thesis project should meet the educational objectives. One of those objectives is to gain domain knowledge. As students mostly carry limited industrial experience and gain literature only from the courses they studied before starting the master thesis project, they need to obtain the necessary domain knowledge from surveying the literature within the given subject. However, identification of the relevant papers is challenging without previous experience and domain knowledge. In this paper, we study how the use of the snowballing literature review impacts the domain knowledge confidence of the master thesis students and help them to achieve educational objectives in their thesis reports. We also study their thesis reports to estimate the level of cognitive complexity in their writing. The snowballing literature review method has become popular in software engineering. It starts with a " start set " of papers that can be identified with the help of the thesis supervisor and analyzes the references and citations of these papers. One can make an assumption that if a senior researcher helps to identify the " start set " the students should get a good overview of a given domain with the help of snowballing. We interview master thesis students and also analyze their final thesis reports and their evaluation scores to better understand how well they achieved the educational objectives and reached higher cognitive complexity levels.

Every student that is conducting the master thesis project should meet the educational objectives. One of those objectives is to gain domain knowledge. As students mostly carry limited industrial experience and gain literature only from the courses they studied before starting the master thesis project, they need to obtain the necessary domain knowledge from surveying the literature within the given subject. However, identification of the relevant papers is challenging without previous experience and domain knowledge. In this paper, we study how the use of the snowballing literature review impacts the domain knowledge confidence of the master thesis students and help them to achieve educational objectives in their thesis reports. We also study their thesis reports to estimate the level of cognitive complexity in their writing. The snowballing literature review method has become popular in software engineering. It starts with a " start set " of papers that can be identified with the help of the thesis supervisor and analyzes the references and citations of these papers. One can make an assumption that if a senior researcher helps to identify the " start set " the students should get a good overview of a given domain with the help of snowballing. We interview master thesis students and also analyze their final thesis reports and their evaluation scores to better understand how well they achieved the educational objectives and reached higher cognitive complexity levels.

Industry-academia collaboration is one of the cornerstones of empirical software engineering. The role of researchers should be developing new practices and principles that enable industry in meeting the engineering challenges today and in the future. This chapter describes the third generation of industrial co-production in software engineering that includes seven steps. The co-production model and experiences associated with its use represent deep and long-term co-production with over thirty companies, many of which are still active partners in SERL

This booklet presents Industrial Open Source, industry proven and standardized patterns for how to manage an Open Source transformation. Use it as a guide for an Open Source journey. In particular you will learn:
• How to create more business – through new and alternative revenue
streams.
• Why contribution is vital – to secure that value is added to your products
• Why compliance is a necessity – as your ticket to participate.