Software fault prediction can play an important role in ensuring software quality through efficient resource allocation. This could, in turn, reduce the potentially high consequential costs due to faults. Predicting faults might be even more important with the emergence of short-timed and multiple software releases aimed at quick delivery of functionality. Previous research in software fault prediction has indicated that there is a need i) to improve the validity of results by having comparisons among number of data sets from a variety of software, ii) to use appropriate model evaluation measures and iii) to use statistical testing procedures. Moreover, cross-release prediction of faults has not yet achieved sufficient attention in the literature. In an attempt to address these concerns, this paper compares the quantitative and qualitative attributes of 7 traditional and machine-learning techniques for modeling the cross-release prediction of fault count data. The comparison is done using extensive data sets gathered from a total of 7 multi-release open-source and industrial software projects. These software projects together have several years of development and are from diverse application areas, ranging from a web browser to a robotic controller software. Our quantitative analysis suggests that genetic programming (GP) tends to have better consistency in terms of goodness of fit and accuracy across majority of data sets. It also has comparatively less model bias. Qualitatively, ease of configuration and complexity are less strong points for GP even though it shows generality and gives transparent models. Artificial neural networks did not perform as well as expected while linear regression gave average predictions in terms of goodness of fit and accuracy. Support vector machine regression and traditional software reliability growth models performed below average on most of the quantitative evaluation criteria while remained on average for most of the qualitative measures.

A large percentage of the cost of rework can be avoided by finding more faults earlier in a software test process. Therefore, determination of which software test phases to focus improvement work on has considerable industrial interest. We evaluate a number of prediction techniques for predicting the number of faults slipping through to unit, function, integration, and system test phases of a large industrial project. The objective is to quantify improvement potential in different test phases by striving toward finding the faults in the right phase. The results show that a range of techniques are found to be useful in predicting the number of faults slipping through to the four test phases; however, the group of search-based techniques (genetic programming, gene expression programming, artificial immune recognition system, and particle swarm optimization-based artificial neural network) consistently give better predictions, having a representation at all of the test phases. Human predictions are consistently better at two of the four test phases. We conclude that the human predictions regarding the number of faults slipping through to various test phases can be well supported by the use of search-based techniques. A combination of human and an automated search mechanism (such as any of the search-based techniques) has the potential to provide improved prediction results.

The Agile manifesto focuses on the delivery of valuable software. In Lean, the principles emphasise value, where every activity that does not add value is seen as waste. Despite the strong focus on value, and that the primary critical success factor for software intensive product development lies in the value domain, no empirical study has investigated specifically what value is. This paper presents an empirical study that investigates how value is interpreted and prioritised, and how value is assured and measured. Data was collected through semi-structured interviews with 23 participants from 14 agile software development organisations. The contribution of this study is fourfold. First, it examines how value is perceived amongst agile software development organisations. Second, it compares the perceptions and priorities of the perceived values by domains and roles. Third, it includes an examination of what practices are used to achieve value in industry, and what hinders the achievement of value. Fourth, it characterises what measurements are used to assure, and evaluate value-creation activities.

Context: The principal focus of lean is the identification and elimination of waste from the process with respect to maximizing customer value. Similarly, the purpose of agile is to maximize customer value and minimize unnecessary work and time delays. In both cases the concept of waste is important. Through an empirical study, we explore how waste is approached in agile software development organizations. Objective: This paper explores the concept of waste in agile/lean software development organizations and how it is defined, used, prioritized, reduced, or eliminated in practice Method: The data were collected using semi-structured open-interviews. 23 practitioners from 14 embedded software development organizations were interviewed representing two core roles in each organization. Results: Various wastes, categorized in 10 different categories, were identified by the respondents. From the mentioned wastes, not all were necessarily waste per se but could be symptoms caused by wastes. From the seven wastes of lean, Task-switching was ranked as the most important, and Extra-features, as the least important wastes according to the respondents’ opinion. However, most companies do not have their own or use an established definition of waste, more importantly, very few actively identify or try to eliminate waste in their organizations beyond local initiatives on project level. Conclusion: In order to identify, recognize and eliminate waste, a common understanding, and a joint and holistic view of the concept is needed. It is also important to optimize the whole organization and the whole product, as waste on one level can be important on another, thus sub-optimization should be avoided. Furthermore, to achieve a sustainable and effective waste handling, both the short-term and the long-term perspectives need to be considered. © 2018 Elsevier B.V.

The increased demand for Remotely Piloted Aircraft Systems (RPAS) in Beyond Visual Line-Of-Sight (BVLOS) operations gives rise to a set of concerns regarding cybersecurity that, if not addressed, can lead to the unsafe operation of RPASs. To assist the airworthiness evaluation that is performed by Civil Aviation Authorities (CAAs), we identified several processes that are used to evaluate the cybersecurity of RPAS. We conducted a Systematic Literature Review (SLR) by selecting 30 papers (out of 211 screened) that were published during the past five years. The results of our SLR indicate the importance of cybersecurity to the safe operation of RPAS. It is evident that there is a lack of a systematic process to enable a cybersecurity review of RPAS. We observe that common cyber threats to RPAS are related to jamming, spoofing, and DOS/DDOS (Denial of Service/Distributed Denial of Service). Processes relevant to the assessment of RPAS cybersecurity exist, however they differ in safety concerns from our perspective. In addition, with only one exception, the methods have not been used, and/or the use has not been reported as pertaining to industrial application. The most frequently cited vulnerabilities are those related to GPS and datalinks. 

Systems that use Machine Learning (ML) have become commonplace for companies that want to improve their products and processes. Literature suggests that Requirements Engineering (RE) can help address many problems when engineering ML-enabled systems. However, the state of empirical evidence on how RE is applied in practice in the context of ML-enabled systems is mainly dominated by isolated case studies with limited generalizability. We conducted an international survey to gather practitioner insights into the status quo and problems of RE in ML-enabled systems. We gathered 188 complete responses from 25 countries. We conducted quantitative statistical analyses on contemporary practices using bootstrapping with confidence intervals and qualitative analyses on the reported problems involving open and axial coding procedures. We found significant differences in RE practices within ML projects. For instance, (i) RE-related activities are mostly conducted by project leaders and data scientists, (ii) the prevalent requirements documentation format concerns interactive Notebooks, (iii) the main focus of non-functional requirements includes data quality, model reliability, and model explainability, and (iv) main challenges include managing customer expectations and aligning requirements with data. The qualitative analyses revealed that practitioners face problems related to lack of business domain understanding, unclear goals and requirements, low customer engagement, and communication issues. These results help to provide a better understanding of the adopted practices and of which problems exist in practical environments. We put forward the need to adapt further and disseminate RE-related practices for engineering ML-enabled systems. © The Author(s), under exclusive license to Springer Nature Switzerland AG 2024.

Modern software development relies on a combination of development and re-use of technical asset, e.g. software components, libraries and APIs.In the past, re-use was mostly conducted with internal assets but today external; open source, customer off-the-shelf (COTS) and assets developed through outsourcing are also common.This access to more asset alternatives presents new challenges regarding what assets to optimally chose and how to make this decision.To support decision-makers, decision-theory has been used to develop decision models for asset selection.However, very little industrial data has been presented in literature about the usefulness, or even perceived usefulness, of these models.Additionally, only limited information has been presented about what model characteristics that determine practitioner preference towards one model over another.

Objective: The objective of this work is to evaluate what characteristics of decision models for asset selection that determine industrial practitioner preference of a model when given the choice of a decision-model of high precision or a model with high speed.

Method: An industrial questionnaire survey is performed where a total of 33 practitioners, of varying roles, from 18 companies are tasked to compare two decision models for asset selection.Textual analysis and formal and descriptive statistics are then applied on the survey responses to answer the study's research questions.

Results: The study shows that the practitioners had clear preference towards the decision model that emphasised speed over the one that emphasised decision precision.This conclusion was determined to be because one of the models was perceived faster, had lower complexity, had, was more flexible in use for different decisions, was more agile how it could be used in operation, its emphasis on people, its emphasis on ``good enough'' precision and ability to fail fast if a decision was a failure.Hence, seven characteristics that the practitioners considered important for their acceptance of the model.

Conclusion: Industrial practitioner preference, which relates to acceptance, of decision models for asset selection is dependent on multiple characteristics that must be considered when developing a model for different types of decisions such as operational day-to-day decisions as well as more critical tactical or strategic decisions.The main contribution of this work are seven identified characteristics that can serve as industrial requirements for future research on decision models for asset selection.

Knowledge translation is defined, in health sciences, as 'the exchange, synthesis and ethically sound application of research results in practice'. The objective of this paper is to implement and conduct a feasibility evaluation of a knowledge translation framework in software engineering. We evaluated the outcome of the knowledge translation framework in an industrial setting, along with the effectiveness of the interventions undertaken as part of knowledge translation in a multi-case study. The results of the evaluation suggest that the practitioners perceive the knowledge translation framework to be valuable and useful. In conclusion, this paper contributes towards the reporting of a systematic implementation of knowledge translation and evaluating its use in software engineering. © 2019 IEEE.

Usage of software engineering research in industrial practice is a well-known challenge. Synthesis of knowledge from multiple research studies is needed to provide evidence-based decision-support for industry. The objective of this paper is to present a vision of how a knowledge translation framework may look like in software engineering research, in particular how to translate research evidence into practice by combining contextualized expert opinions with research evidence. We adopted the framework of knowledge translation from health care research, adapted and combined it with a Bayesian synthesis method. The framework provided in this paper includes a description of each step of knowledge translation in software engineering. Knowledge translation using Bayesian synthesis intends to provide a systematic approach towards contextualized, collaborative and consensus-driven application of research results. In conclusion, this paper contributes towards the application of knowledge translation in software engineering through the presented framework. © 2019 Association for Computing Machinery.

Context: Review of software artifacts, such as source or test code, is a common practice in industrial practice. However, although review guidelines are available for source and low-level test code, for GUI-based testing artifacts, such guidelines are missing. Objective: The goal of this work is to define a set of guidelines from literature about production and test code, that can be mapped to GUI-based testing artifacts. Method: A systematic literature review is conducted, using white and gray literature to identify guidelines for source and test code. These synthesized guidelines are then mapped, through examples, to create actionable, and applicable, guidelines for GUI-based testing artifacts. Results: The results of the study are 33 guidelines, summarized in nine guideline categories, that are successfully mapped as applicable to GUI-based testing artifacts. Of the collected literature, only 10 sources contained test-specific code review guidelines. These guideline categories are: perform automated checks, use checklists, provide context information, utilize metrics, ensure readability, visualize changes, reduce complexity, check conformity with the requirements and follow design principles and patterns. Conclusion: This pivotal set of guidelines provides an industrial contribution in filling the gap of general guidelines for review of GUI-based testing artifacts. Additionally, this work highlights, from an academic perspective, the need for future research in this area to also develop guidelines for other specific aspects of GUI-based testing practice, and to take into account other facets of the review process not covered by this work, such as reviewer selection. © 2023 The Author(s)

The management and coordination of globally distributed development poses many new challenges, including compensating for informal implicit communication, which is aggravated by heterogeneous social and engineering traditions between development sites. Although much research has gone into identifying challenges and working with practical solutions, such as tools for communication, little research has focused on comparing communication mechanisms in terms of their ability to provide large volumes of rich information in a timely manner. Data was collected through in-depth interviews with eleven practitioners and twenty-eight responses through a web-based questionnaire from three product lines at an international software development organization. This paper assesses the relative importance of ten commonly used communication mechanisms and practices across local and global development sites. The results clearly indicate that some communication mechanisms are more important than others in providing large volumes of rich information in a timely manner. The prevalence of architecture in providing rich information in large volumes for both local and global communication can be clearly observed.

The necessity of software as stand-alone products, and as central parts of non-traditional software products have changed how software products are developed. It started with the introduction of the agile manifesto and has resulted in a change of how software process improvements (SPI) are conducted. Although there are agile SPI methods and several agile practices for evaluating and improving current processes and ways-of-working, no method or practices for evaluating the backlog exists. To address this gap, the Backlog Assessment Method (BAM) was developed and applied in collaboration with Telenor Sweden. BAM enables agile organizations to assess backlogs, and assure that the backlog items are good-enough for their needs and well aligned with the decision process. The results from the validation show that BAM is feasible and relevant in an industrial environment, and it indicates that BAM is useful as a tool to perform analysis of items in a specific backlog. © The Author(s) 2019.

Conway’s law assumes a strong association between the system’s architecture and the organization’s communication structure that designs it. In the light of contemporary software development, when many companies rely on geographically distributed teams, which often turn out to be temporarily composed and thus having an often changing communication structure, the importance of Conway’s law and its inspired work grows. In this paper, we examine empirical research related to Conway’s law and its application for cross-site coordination. Based on the results obtained we conjecture that changes in the communication structure alone sooner or later trigger changes in the design structure of the software products to return the sociotechnical system into the state of congruence. This is further used to formulate a concept of a rubber band effect and propose a replication study that goes beyond the original idea of Conway’s law by investigating the evolution of socio-technical congruence over time.

Weak alignment of requirements engineering (RE) with verification and validation (VV) may lead to problems in delivering the required products in time with the right quality. For example, weak communication of requirements changes to testers may result in lack of verification of new requirements and incorrect verification of old invalid requirements, leading to software quality problems, wasted effort and delays. However, despite the serious implications of weak alignment research and practice both tend to focus on one or the other of RE or VV rather than on the alignment of the two. We have performed a multi-unit case study to gain insight into issues around aligning RE and VV by interviewing 30 practitioners from 6 software developing companies, involving 10 researchers in a flexible research process for case studies. The results describe current industry challenges and practices in aligning RE with VV, ranging from quality of the individual RE and VV activities, through tracing and tools, to change control and sharing a common understanding at strategy, goal and design level. The study identified that human aspects are central, i.e. cooperation and communication, and that requirements engineering practices are a critical basis for alignment. Further, the size of an organisation and its motivation for applying alignment practices, e.g. external enforcement of traceability, are variation factors that play a key role in achieving alignment. Our results provide a strategic roadmap for practitioners improvement work to address alignment challenges. Furthermore, the study provides a foundation for continued research to improve the alignment of RE with VV.

Context: Component-based software engineering (CBSE) is a common approach to develop and evolve contemporary software systems. When evolving a system based on components, make-or-buy decisions are frequent, i.e., whether to develop components internally or to acquire them from external sources. In CBSE, several different sourcing options are available: (1) developing software in-house, (2) outsourcing development, (3) buying commercial-off-the-shelf software, and (4) integrating open source software components. Objective: Unfortunately, there is little available research on how organizations select component sourcing options (CSO) in industry practice. In this work, we seek to contribute empirical evidence to CSO selection. Method: We conduct a cross-domain survey on CSO selection in industry, implemented as an online questionnaire. Results: Based on 188 responses, we find that most organizations consider multiple CSOs during software evolution, and that the CSO decisions in industry are dominated by expert judgment. When choosing between candidate components, functional suitability acts as an initial filter, then reliability is the most important quality. Conclusion: We stress that future solution-oriented work on decision support has to account for the dominance of expert judgment in industry. Moreover, we identify considerable variation in CSO decision processes in industry. Finally, we encourage software development organizations to reflect on their decision processes when choosing whether to make or buy components, and we recommend using our survey for a first benchmarking. © 2019

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

Component-based software engineering is a common approach in the development and evolution of contemporary software systems. Different component sourcing options are available, such as: (1) Software developed internally (in-house), (2) Software developed outsourced, (3) Commercial off-the-shelf software, and (4) Open-Source Software. However, there is little available research on what attributes of a component are the most important ones when selecting new components. The objective of this study is to investigate what matters the most to industry practitioners when they decide to select a component. 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 results of this exploratory analysis showed that cost was clearly considered to be the most important attribute for component selection. Other important attributes for the practitioners were: support of the component, longevity prediction, and level of off-the-shelf fit to product. Moreover, several practitioners still consider in-house software development to be the sole option when adding or replacing a component. On the other hand, there is a trend to complement it with other component sourcing options and, apart from cost, different attributes factor into their decision. Furthermore, in our analysis, nonparametric tests and biplots were used to further investigate the practitioners' inherent characteristics. It seems that smaller and larger organizations have different views on what attributes are the most important, and the most surprising finding is their contrasting views on the cost attribute: larger organizations with mature products are considerably more cost aware.

Background: Requirements engineering is of a principal importance when starting a new project. However, the number of the requirements involved in a single project can reach up to thousands. Controlling and assuring the quality of natural language requirements (NLRs), in these quantities, is challenging. Aims: In a field study, we investigated with the Swedish Transportation Agency (STA) to what extent the characteristics of requirements had an influence on change requests and budget changes in the project. Method: We choose the following models to characterize system requirements formulated in natural language: Concern-based Model of Requirements (CMR), Requirements Abstractions Model (RAM) and Software-Hardware model (SHM). The classification of the NLRs was conducted by the three authors. The robust statistical measure Fleiss' Kappa was used to verify the reliability of the results. We used descriptive statistics, contingency tables, results from the Chi-Square test of association along with post hoc tests. Finally, a multivariate statistical technique, Correspondence analysis was used in order to provide a means of displaying a set of requirements in two-dimensional graphical form. Results: The results showed that software requirements are associated with less budget cost than hardware requirements. Moreover, software requirements tend to stay open for a longer period indicating that they are 'harder' to handle. Finally, the more discussion or interaction on a change request can lower the actual estimated change request cost. Conclusions: The results lead us to a need to further investigate the reasons why the software requirements are treated differently from the hardware requirements, interview the project managers, understand better the way those requirements are formulated and propose effective ways of Software management. © 2019 IEEE.

[Context and Motivation] Software requirements are affected by the knowledge and confidence of software engineers. Analyzing the interrelated impact of these factors is difficult because of the challenges of assessing knowledge and confidence. [Question/Problem] This research aims to draw attention to the need for considering the interrelated effects of confidence and knowledge on requirements quality, which has not been addressed by previous publications. [Principal ideas/results] For this purpose, the following steps have been taken: 1) requirements quality was defined based on the instructions provided by the ISO29148:2011 standard, 2) we selected the symptoms of low qualified requirements based on ISO29148:2011, 3) we analyzed five Software Requirements Specification (SRS) documents to find these symptoms, 3) people who have prepared the documents were categorized in four classes to specify the more/less knowledge and confidence they have regarding the symptoms, and 4) finally, the relation of lack of enough knowledge and confidence to symptoms of low quality was investigated. The results revealed that the simultaneous deficiency of confidence and knowledge has more negative effects in comparison with a deficiency of knowledge or confidence. [Contribution] In brief, this study has achieved these results: 1) the realization that a combined lack of knowledge and confidence has a larger effect on requirements quality than only one of the two factors, 2) the relation between low qualified requirements and requirements engineers’ needs for knowledge and confidence, and 3) variety of requirements engineers’ needs for knowledge based on their abilities to make discriminative and consistent decisions. © 2021, Springer Nature Switzerland AG.

Technology and knowledge have been recognized as main sources of competitive advantage of corporations, industries and nations, particularly in the software domain. They have led to the creation of local ecosystems devoted to development and transfer activities, which ensure not only personal and institutional motivation/recognition, but also social and economic gains. An open (ended) debate panel is proposed in order to develop greater awareness and seek deeper understanding of such activities from Requirements Engineering research to industrial practice. The panel involves researchers and practitioners with the perspective of eliciting: (i) experiences in knowledge and technology development and transfer; (ii) awareness and effectiveness of models and patterns; and (iii) factors for having successful collaboration between research institutions and industry. The organizers also plan to run a survey during and after the conference, summarizing their conclusions in specific post-conference reports.

Software inspections have proved to be an effective means to find faults in different software artifacts, and the application of software inspections on requirements specifications is believed to give a high return on investment as problems are caught early. However, despite the existing evidence of positive effects requirements inspections are not a common practice in industry. The reason is believed to be the cost associated with inspections as a technology. This paper presents an evaluation of test-case driven inspections (TCD) - an emerging inspection technique that aims to cut costs associated with traditional requirements inspections. To formally test the efficiency and effectiveness of TCD inspections an experiment was conducted, in a controlled environment, where checklist based inspections was used as a point of reference. The experiment results indicate that TCD inspections perform better when it comes to effectiveness in finding major faults in a requirements specification.

The need of understanding and supporting requirements engineering decisions in market-driven product development is motivated by the complexity and economical impact of these decisions. While being a key for success, correct and timely decisions are dependent on the availability and the quality of decision material (requirements, business cases, costvalue estimations etc). This paper presents a needsoriented framework (NORM) for identifying and assuring the creation of appropriate decision material for RE decisions. NORM is based on analysis of the applied RE process and characteristics of separate RE decisions, focusing mainly on pre-project activities. The framework is developed in close cooperation with industry with the intention to ensure that resources are spent on producing just-the-necessary information at the right time and to be able to monitor and control this production effort.

Agile development methods such as XP, SCRUM, Lean Software Development and others have gained much popularity during the last years. Agile methodologies promise faster time-to-market, satisfied customers and high quality software. While these prospects are appealing, the suitability of agile practices to different domains and business contexts still remains unclear. In this paper we investigate the applicability of agile principles in the context of market-driven software product development (MDPD), focusing on pre-project activities. This paper presents results of a comparison between typical properties of agile methods to the needs of MDPD, as well as findings of a case study conducted at Ericsson, an early adopter of agile product development. The results show misalignment between the agile principles and needs of pre-project activities in market-driven development. This misalignment threatens to subtract from the positive aspects of agile development, but maybe more importantly, threaten the overall product development by disabling effective product management.

In market-driven software product development, requirements that can potentially go into a product or a product release represent different kinds of investments. Requirements differ in the type of value that they provide and level of risk associated to investing in them. In this paper we investigate how business risk associated with different requirement types is considered by the decision makers and how it affects requirement selection decisions. The results of the conducted case study indicate that due to lacking methods for handling the requirements business risk, requirements with low level of risk are preferred over other type of requirements such as innovations and architectural improvements.

This technical report presents RefA, a reference architecture for security-compliant DevOps. RefA consists of a set of models that illustrate the artefacts and practice areas to consider when implementing secure DevOps lifecycles. In addition, RefA describes people, proceses, and technology aspects to be considered in each practice area. Practitioners can use RefA for the purposes of designing and assessing security compliance of their DevOps lifecycles, while researchers may use RefA as a reference for setting up research roadmaps. RefA models result from combining the profound analysis of the IEC 62443-4-1 standard for secure industrial products development, continuous software engineering literature review, and observations made in practice in context of a large industrial company during the past 5 years. The manuscript constitutes original, previously unpublished research.

Search-based software testing (SBST) has shown a potential to decrease cost and increase quality of testingrelated software development activities. Research in SBST has so far mainly focused on the search for isolated tests that are optimal according to a fitness function that guides the search. In this paper we make the case for fitness functions that measure test fitness in relation to existing or previously found tests; a test is good if it is diverse from other tests. We present a model for test variability and propose the use of a theoretically optimal diversity metric at variation points in the model. We then describe how to apply a practically useful approximation to the theoretically optimal metric. The metric is simple and powerful and can be adapted to a multitude of different test diversity measurement scenarios. We present initial results from an experiment to compare how similar to human subjects, the metric can cluster a set of test cases. To carry out the experiment we have extended an existing framework for test automation in an object-oriented, dynamic programming language.

[Context:] The quality of requirements engineeringartifacts, e.g. requirements specifications, is acknowledged tobe an important success factor for projects. Therefore, manycompanies spend significant amounts of money to control thequality of their RE artifacts. To reduce spending and improvethe RE artifact quality, methods were proposed that combinemanual quality control, i.e. reviews, with automated approaches.[Problem:] So far, we have seen various approaches to auto-matically detect certain aspects in RE artifacts. However, westill lack an overview what can and cannot be automaticallydetected. [Approach:] Starting from an industry guideline forRE artifacts, we classify 166 existing rules for RE artifacts alongvarious categories to discuss the share and the characteristics ofthose rules that can be automated. For those rules, that cannotbe automated, we discuss the main reasons. [Contribution:] Weestimate that 53% of the 166 rules can be checked automaticallyeither perfectly or with a good heuristic. Most rules need onlysimple techniques for checking. The main reason why some rulesresist automation is due to imprecise definition. [Impact:] Bygiving first estimates and analyses of automatically detectable andnot automatically detectable rule violations, we aim to provide anoverview of the potential of automated methods in requirementsquality control.

REQUIREMENTS ENGINEERING (RE) is a critical area in software development, as figuring out what to develop and include in a product is a cornerstone activity which all others depend upon. Countless studies of unsuccessful development projects report that lack in RE is often a core-contributing failure factor. 13 Central in RE is the role that coordinates all its related activities, usually named requirements engineer.

Still, empirical evidence on the way companies implement this role is scarce. In this article, we present the results of an interview-based descriptive study involving 24 IT professionals from 12 companies. As a main outcome, we can affirm that all companies assign IT professionals to the requirements engineer role in their projects, but in many different ways, which might impact efficiency of the function. Furthermore, we uncover that requirements engineers often perform other tasks ranging from project’s go vs. no-go decisions to test suite design in addition to handling requirements. Last, the study highlights their need to communicate with many other roles inside the company, from domain experts to system architects.

Requirements specification is a core activity in the requirements engineering phase of a software development project. Researchers have contributed extensively to the field of requirements specification, but the extent to which their proposals have been adopted in practice remains unclear. We gathered evidence about the state of practice in requirements specification by focussing on the artefacts used in this activity, the application of templates or guidelines, how requirements are structured in the specification document, what tools practitioners use to specify requirements, and what challenges they face. We conducted an interview-based survey study involving 24 practitioners from 12 different Swedish IT companies. We recorded the interviews and analysed these recordings, primarily by using qualitative methods. Natural language constitutes the main specification artefact but is usually accompanied by some other type of instrument. Most requirements specifications use templates or guidelines, although they seldom follow any fixed standard. Requirements are always structured in the document according to the main functionalities of the system or to project areas or system parts. Different types of tools, including MS Office tools, are used, either individually or combined, in the compilation of requirements specifications. We also note that challenges related to the use of natural language (dealing with ambiguity, inconsistency, and incompleteness) are the most frequent challenges that practitioners face in the compilation of requirements specifications. These findings are contextualized in terms of demographic factors related to the individual interviewees, the organization they are affiliated with, and the project they selected to discuss during our interviews. A number of our findings have been previously reported in related studies. These findings show that, in spite of the large number of notations, models and tools proposed from academia for improving requirements specification, practitioners still mainly rely on plain natural language and general-purpose tool support. We expect more empirical studies in this area in order to better understand the reason of this low adoption of research results.

Requirements engineering focuses on good specification practices but has yet to find working solutions for effective requirements communication. Inadequate communication and tacit assent to a demanding customer's requests make it hard to fully understand a project's requirements. A negotiation process, called handshaking with implementation proposals, has been used to communicate requirements effectively—even in situations where almost no written requirements exist and where distance separates the customer from developers. Handshaking is an efficient, flexible technique that uses architectural options to understand requirements, to make implementation decisions that create value, and to establish the foundation for a stable project. This article describes the communication challenges, solutions, and lessons learned in developing the handshaking process and applying it in industrial practice.

Product development organizations often distribute the responsibilities for requirements engineering over several roles. The collaboration of product management, concerned with market needs, and product development, concerned with the technological aspects of a product, is well established. Such shared responsibility provides advantages in the utilization of specific knowledge, skills, and resources. However, the collaboration leads to increased demands on coordination. Novel concepts and models need to be investigated to support such collaborative requirements engineering. In this paper we focus on requirements communication from product management to a development team by proposing and evaluating the model of goaloriented requirements communication. The model explains how efficiency and effectiveness of requirements communication can be increased and allows the utilization of established requirements engineering knowledge in a new way to address the task of requirements communication.

Handshaking between product management and R&D is key to the success of product development projects. Traditional requirements engineering processes build on good quality requirements specifications, which typically are not achievable in practical circumstances, especially not in distributed development where daily communication cannot easily be achieved to support the understanding of the specification and tacit knowledge cannot easily be spread. Projects thus risk misunderstanding requirements and are likely to deliver inadequate solutions. This paper presents an approach that uses downstream engineering artifacts, design decisions, to improve upstream information, a project’s requirements. During its preliminary validation, the approach yielded promising results. It is well suited for distributed software projects, where the negotiation on requirements and solution design need to be made explicit and potential problems and misunderstandings caught at early stages.

Software startups are newly created companies with no operating history and oriented towards producing cutting-edge products. However, despite the increasing importance of startups in the economy, few scientific studies attempt to address software engineering issues, especially for early-stage startups. If anything, startups need engineering practices of the same level or better than those of larger companies, as their time and resources are more scarce, and one failed project can put them out of business. In this study we aim to improve understanding of the software development strategies employed by startups. We performed this state- of-practice investigation using a grounded theory approach. We packaged the results in the Greenfield Startup Model (GSM), which explains the priority of startups to release the product as quickly as possible. This strategy allows startups to verify product and market fit, and to adjust the product trajectory according to early collected user feedback. The need to shorten time-to-market, by speeding up the development through low-precision engineering activities, is counterbalanced by the need to restructure the product before targeting further growth. The resulting implications of the GSM outline challenges and gaps, pointing out opportunities for future research to develop and validate engineering practices in the startup context.

An impressive number of new startups are launched every day as a result of growing new markets, accessible technologies, and venture capital. New ventures such as Facebook, Supercell, Linkedin, Spotify, WhatsApp, and Dropbox, to name a few, are good examples of startups that evolved into successful businesses. However, despite many successful stories, the great majority of them fail prematurely. Operating in a chaotic and rapidly evolving domain conveys new uncharted challenges for startuppers. In this study, the authors characterize their context and identify common software development startup practices.

— A little rebellion now and then is a good thing. This short position statement describes my views on some of the challenges associated with many conferences, the Requirements Engineering Conference being among them. The main concepts are; the goals, as well as criteria for paper selection for the conference should be defined explicitly, and shared with the community. Industry involvement in the conference should be increased, but the focus of all tracks should be quality – what constitutes quality however needs to be defined and agreed on. Industrial validation of research results have to be more than an intention. Last but not least, how papers are presented and discussed needs to change, focusing on quality over quantity.

SOFTWARE IS A cornerstone of the economy, historically led by companies like Apple, Google, and Microsoft. However, the past decade has seen software become increasingly pervasive, while traditionally hardware-intensive products are increasingly dependent on software, meaning that major global companies like ABB, Ericsson, Scania, and Volvo are likewise becoming soft(er).(10) Where software was bundled with hardware it is now increasingly the main product differentiator.(10) This shift has radical implications, as software delivers notable advantages, including a faster pace of release and improved cost effectiveness in terms of development, ease of update, customization, and distribution. These characteristics of software open a range of possibilities, though software's inherent properties also pose several significant challenges in relation to a company's ability to create value.(10) To investigate them, we conducted in-depth interviews from 2012 to 2016 with 13 senior product managers in 12 global companies.

The field of Empirical Software Engineering has undergone a much-needed expansion the last decade, and papers of all shapes and sizes are more or less mandated to have an "empirical" part to be published in premiere venues. The positive trend has researchers realizing the benefits, but also the investments needed, inherent to industry collaboration. That is, real practitioners, involved in the development of software intensive product, system, and service development. This paper shortly summarizes lessons learned from over ten years experience of industrial collaboration, and knowledge and technology exchange between applied researchers and industry.

Market-Driven Requirements Engineering (MDRE) handles the continuous flow of requirements in an engineering effort, and is not limited to a development instance but part of technical product management as a whole. The market-driven environment generates large amounts of requirements from multiple sources, internal and external, threatening to overload the technical management of products. MDRE involves requirements analysis, resource estimation, prioritization, and ultimately release planning. These activities allow for effectively deciding which customers get what features and quality at what point in time, making the accuracy and efficiency of MDRE a major determinant of the success of a product. This thesis presents research aimed at supporting technical product management in MDRE, based on needs identified in industry. One contribution of the thesis is the development and validation of a process assessment and improvement planning framework, making the identification of process improvement issues possible. The major characteristics of the framework can be described as resource efficiency and relative accuracy by utilizing multiple perspectives and data point triangulation. As a complement to the assessment, the improvement planning enables industry professionals to focus their efforts on one improvement package at a time, supporting step-by-step evolution with less time to return on investment. Challenges identified during process assessment using the framework resulted in the development of the Requirements Abstraction Model (RAM), which is the central contribution of the thesis. RAM employs multiple levels of abstraction for requirements elicitation, analysis, refinement and management. The model offers the possibility for early requirements triage using product strategies/roadmaps, as well as supporting a structured and repeatable way to perform continuous requirements engineering. This enables product managers to specify requirements that can be traced across abstraction levels, from abstract requirements that can be used by managers, to refined requirements specific enough to be used for estimation and input to development efforts. RAM was engineered based on industry needs, validated and refined through several empirical evaluations, utilizing both academia and industry as laboratory. This involved close collaboration with industrial partners, Danaher Motion Särö AB and ABB Robotics, where the model was introduced. Monitoring the process improvement (introduction of RAM) indicated substantial improvements, both in accuracy of the work performed using RAM, and in the quality of the requirements produced, with only moderate increase in effort. Another contribution in the thesis is a compilation of lessons learned from practical handson experience of technology and knowledge transfer from academia to industry, with focus of producing industry relevant usable and useful results. The main contribution of the thesis is improving the practice of product management by providing and evaluating frameworks for software process improvement and market-driven requirements engineering. The results of the research presented in the thesis are aimed at supporting technical product management taking the unique challenges of market-driven development into account.

Requirements Engineering (RE) is a crucial part of any product management and product development activity, and as such deficiencies in the RE process may have severe consequences. There are reports from industry that point towards inadequate requirements being one of the leading sources for project failure. Software Process Improvement (SPI) is generally seen as the main tool to address process deficiencies in general and within RE. Assessments lead to establishing plans for improvements that are subsequently implemented and evaluated, and then the SPI cycle starts again, in an optimal case being incremental and continuous. Most well known SPI frameworks, e.g. CMM, CMMI, SPICE and QIP, are based on these general principles. There are however several factors that can have a negative impact on SPI efforts in general, and in the case of SPI targeted at RE in particular. Time and cost are two fundamental factors that can effectively “raise the bar” for SPI efforts being initiated at all. This is the particular case for Small and Medium sized Enterprises (SMEs) with limited resources, and a limited ability to wait for the return on their investment. Other issues include commitment and involvement in the SPI work by the ones affected by the changes, coverage of the RE area in SPI frameworks, and the ability to focus improvements to areas where they are needed the most. The research presented in this thesis is based on actual needs identified in industry, and all of the proposed solutions have also been validated in industry to address issues of applicability and usability. In general, the goal of the research is to “lower the bar”, i.e. enabling SMEs to initiate and perform SPI activities. It is accomplished through the presentation and validation of two assessment methods that targets RE, one aimed at both fast and low-cost benchmarking of current practices, and the other designed to produce tangible improvement proposals that can be used as input to an improvement activity, i.e. producing a relatively accurate assessment but taking limited time and resources into account. Further, to offer a structured way in which SMEs can focus their SPI efforts, a framework is introduced that can be used to package improvement proposals with regards to their relative priority taking dependencies into account. This enables SMEs to choose what to do first based on their needs, as well as a way to control time to return on their investment by controlling the size of the undertaking. As a result of industry validation of the assessment method and packaging framework, several improvement proposals were identified and prioritized/packaged. As a part of a process improvement effort (based on an improvement proposal package) an RE model was developed that was appropriate for SMEs faced with a market-driven product centered development situation. The model, called Requirements Abstraction Model (RAM), addresses the structuring and specification of requirements. The main feature of the model is that it not only offers a structured way in which requirements can be specified, but it also takes a requirement’s abstraction level into account, using abstraction for the work-up instead of putting all requirements in one repository independent of abstraction level. The RAM was developed to support primarily the product management effort, recognizing that RE from this perspective is not project initiated but rather project initiating. The model assists product managers to take requirements on varying abstraction levels and refining them to the point of being good-enough to offer decision support for management, and at the same time being good-enough for project initiation. The main contribution of the thesis is to present SMEs with “tools” that help them commit to and perform SPI activities. Moreover, the thesis introduces the RAM model that was developed based on needs identified in industry, and subsequently piloted in industry to assure usability.

When software development teams modify their requirements engineering process as an independent variable, they often examine the implications of these process changes by assessing the quality of the products of the requirements engineering process, e.g., a software requirements specification (SRS). Using the quality of the SRS as the dependent variable is flawed. As an alternative, this paper presents a framework of dependent variables that serves as a full range for requirements engineering quality assessment. In this framework, the quality of the SRS itself is just the first level. Other higher, and more significant levels, include whether the project was successful and whether the resulting product was successful. And still higher levels include whether or not the company was successful and whether there was a positive or negative impact on society as a whole. © 2007 Elsevier B.V. All rights reserved.

Software product management steers the success of a product in all its lifecycle stages by thoughtful application of planning, coordination, and control. The third international workshop on software product management (IWSPM´09) was held in conjunction with the International Conference on Requirements Engineering (RE'09) in Atlanta USA. The aim was to bring researchers and industry practitioners together to discuss the area and unique challenges of software and technology product management. Selected challenges put forward by accepted papers from both industry and academia were analyzed. The session discussions focused on identifying future needs for research, the relevance of which was assured by good industry presence at the workshop. The workshop homepage can be found http://2009.iwspm.org

GREW´07 was held in conjunction with the International Conference on Global Software Engineering in Munich Germany. The aim was to bring researchers and industry practitioners together to discuss the area of global product development from a requirements engineering and product management perspective. The workshop aimed to analyze selected challenges put forward by accepted papers from both industry and academia. The session discussions then focused on identifying future needs for research, the relevance of which was assured by good industry presence at the workshop. The workshop resulted in a number of findings that can play an important role to further develop the field of global product management and requirements engineering.

The product development environment facing most companies today requires a long-term perspective featuring the conception and development of long-term innovations. This can be hard when close quarter bottom-line results dominate. Without innovation, competitive advantages decrease over time. This is especially true for companies producing software-intensive systems. Software is becoming a large part of the competitive advantage of traditionally hardware-focused systems such as cars, robots, or power systems, where feature sets traditionally offered and controlled by hardware are transferred to software. As software's impact and influence grows, so do the possibilities for innovation and increasing the competitive advantage through software. Star Search is a lightweight innovation model based on best practices from innovation management literature as well as two industry cases. It employs face-to-face screening and idea refinement using heterogeneous audition teams. Star Search was developed in collaboration with, and subsequently piloted at, two companies. It has helped increase the long-term perspective of product development by increasing the level of new ideas that make it to product planning and development

Technology transfer, and thus industry-relevant research, involves more than merely producing research results and delivering them in publications and technical reports. It demands close cooperation and collaboration between industry and academia throughout the entire research process. During research conducted in a partnership between Blekinge Institute of Technology and two companies, Danaher Motion Saro AB (DHR) and ABB, we devised a technology transfer model that embodies this philosophy. We initiated this partnership to conduct industry-relevant research in requirements engineering and product management. Technology transfer in this context is a prerequisite: it validates academic research results in a real setting, and it provides a way to improve industry development and business processes

Software requirements are often formulated on different levels and hence they are difficult to compare to each other. To address this issue, a model that allows for placing requirements on different levels has been developed. The model supports both abstraction and refinement of requirements, and hence requirements can both be compared with each other and to product strategies. Comparison between requirements will allow for prioritization of requirements, which in many cases is impossible if the requirements are described on different abstraction levels. Comparison to product strategies will enable early and systematic acceptance or dismissal of requirements, minimizing the risk for overloading. This paper presents an industrial evaluation of the model. It has been evaluated in two different companies, and the experiences and findings are presented. It is concluded that the requirements abstraction model provides helpful improvements to the industrial requirements engineering process.