Boundary artefacts are shared artefacts that support collaboration by allowing different groups to interpret the same information in different ways. Software development activities benefit from them, as a single artefact can support stakeholders across different organisational boundaries. When these artefacts contain inconsistencies, such as incorrect information, practitioners’ trust in them may decrease, leading to inefficiencies in task execution. This study developed and evaluated a guideline to support the creation of boundary artefacts in software engineering contexts. We conducted a longitudinal, multi-phase study embedded in an industrial setting. The guideline was developed based on a literature review and prior findings from a previous case study and was then submitted for practitioner evaluation. A post-implementation analysis of the guideline was carried out after a period without researcher intervention. Our guideline consists of 10 principles grouped into three categories: (1) Scope: stakeholders, boundaries, and terminology; (2) Structure: artefact format, transference, granularity, and additions; and (3) Management: evaluation, ownership, governance, and integration. Practitioner evaluations suggested that these principles support the creation of reliable, predictable, and functional boundary artefacts. However, practitioners also noted challenges during use, including the time-consuming nature of the activity and difficulties in understanding the concept of boundary artefact. Overall, the guideline was well received. After the non-intervention period, it was adopted as a standard by the partner company for artefacts such as security testing, standards documentation, and requirements specifications. Adoption challenges persisted, including cultural barriers and comprehension issues. Further applications across different artefacts could clarify how the principles influence their reliability, functionality, and predictability.

Abstract Context Generative AI (GenAI) is increasingly adopted in software development for tasks such as document generation, data analysis, and code generation. However, evaluating the quality of GenAI applications becomes challenging, as traditional quality measurements may not be fully applicable. Objective In this study, we explore how practitioners evaluate the quality of GenAI applications and investigate quality evaluation techniques. Method We conducted a multi-case study in three industrial projects from software development companies. We examined four GenAI application domains: document generation, data analysis and insight generation, customer service, and code generation. Data were collected through three workshops and 23 semi-structured interviews with industrial practitioners. Results We identified fourteen GenAI use cases and 28 metrics currently used to evaluate the quality of GenAI applications’ outputs. We synthesized the identified metrics’ usage patterns and challenges based on the collected data. Conclusions This study presents practical insights into using metrics to measure GenAI-based system qualities in real industrial settings. Our findings indicate that practitioners use custom-built and context-specific metrics; combining these with academic metrics can strengthen GenAI system quality evaluation.

Context: Software systems in regulated domains must continually adapt to legal changes, yet practitioners often handle updates manually with limited support, making compliance work costly and error prone. Recent advances in LLMs prompt the question of how automation can reliably assist this process. Objectives: We aim to (1) characterize the nature of regulatory changes and derive a systematic taxonomy, (2) understand through the lens of practitioners where automation is most useful, and (3) assess the feasibility of using LLMs for detecting and classifying regulatory changes. Method: We conducted a mixed-methods study grounded in the German social security (DEÜV) in collaboration with practitioners from a FinTech company. First, we developed a taxonomy of regulatory changes through manual document analysis of four Regulatory Implementation Specifications (RIS), followed by a workshop and expert interviews. Second, we validated the taxonomy and elicited challenges through semi-structured practitioner interviews. Third, we built a gold-standard dataset of 93 annotated change instances and evaluated seven state-of-the-art LLMs within an automated detection and classification pipeline. Results: The taxonomy defines five change scopes and four optional context dimensions. Practitioners found it intuitive and useful for filtering relevant changes, particularly Data and Field updates, but reported challenges such as tight deadlines, legal ambiguity, limited traceability, and overlapping categories. In automation, proprietary LLMs performed best, while performance dropped on narrative or weakly structured documents, highlighting sensitivity to document format. Conclusion: The proposed taxonomy provides a practical lens for organizing regulatory change information, and LLMs can support the identification and classification of recurring, structurally explicit changes. Their limitations on context-dependent and infrequent categories suggest that automation should complement, rather than replace, expert assessment, motivating future work on human-in-the-loop compliance tooling across broader regulatory ecosystems.

Generative Artificial Intelligence (GenAI) is increasingly integrated into software products to enable new features and user capabilities, from early exploration to operational deployment. GenAI adoption as a component within a software system introduces quality risks because GenAI outputs are probabilistic, prompt-sensitive, and may drift after release. Organizations, therefore, need to decide what to evaluate, when to evaluate, and who owns quality evaluation activities across software design, development, and operations. ISO/IEC 25059 standard distinguishes between software product quality (e.g., usability) and quality-in-use (e.g., satisfaction) for AI-enabled software, yet it provides limited operational guidance for these evaluation activities. We therefore investigate how industrial software teams adopt and use GenAI models in the software systems they build and operate, and how they evaluate system qualities when deciding to adopt GenAI during development and after deployment. We do not benchmark the underlying GenAI model itself. In this study, we conducted 19 semi-structured interviews in two software development companies. We triangulated the interviews with archival data (15 internal documents and 184 internal wiki/web pages) to capture GenAI adoption steps, quality concerns, evaluation practices, and role responsibilities. Our findings describe a three-phase adoption process – Ideation, Development, and Operation – highlighting where quality evaluations occur, which criteria are used, and how evaluation responsibilities are distributed. Based on observed practices and using ISO/IEC 25059 as an organizing lens, we synthesize a process-oriented quality evaluation framework. This framework maps metrics to explicit gatekeeping, validation, and monitoring checkpoints, bridging abstract ISO quality characteristics with engineering workflows. We applied the framework in a GenAI-enabled software product (SE4AI) use case and reported how it supported structured evaluation activities. We also observed that quality evaluations span legal, security, development, QA, and operations, but ownership is fragmented across phases. We therefore propose a GenAI Quality Lead responsibility (often assignable to an existing senior role) to coordinate criteria, evidence, and traceability across quality evaluation activities. The results contribute to Software Engineering for AI (SE4AI) by clarifying how teams can measure qualities when building software that adopts and uses GenAI.

Machine learning (ML)-enabled systems are being increasingly adopted by companies aiming to enhance their products and operational processes. This paper aims to deliver a comprehensive overview of the current status quo of engineering ML-enabled systems and lay the foundation to steer practically relevant and problem-driven academic research. We conducted an international survey to collect insights from practitioners on the current practices and problems in engineering ML-enabled systems. We received 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 using open and axial coding procedures. Our survey results reinforce and extend existing empirical evidence on engineering ML-enabled systems, providing additional insights into typical ML-enabled systems project contexts, the perceived relevance and complexity of ML life cycle phases, and current practices related to problem understanding, model deployment, and model monitoring. Furthermore, the qualitative analysis provides a detailed map of the problems practitioners face within each ML life cycle phase and the problems causing overall project failure. The results contribute to a better understanding of the status quo and problems in practical environments. We advocate for the further adaptation and dissemination of software engineering practices to enhance the engineering of ML-enabled systems. • International survey gathering insights from 188 practitioners across 25 countries. • Overview of current practices and challenges in engineering ML-enabled systems. • Inferential quantitative analysis reporting the status quo with confidence intervals. • Qualitative analysis mapping ML life cycle challenges and causes of project failure.

Context: As the diversity and complexity of regulations affecting Software-Intensive Products and Services (SIPS) is increasing, software engineers need to address the growing regulatory scrutiny. We argue that, as with any other non-negotiable requirements, SIPS compliance should be addressed early in SIPS engineering—i.e., during requirements engineering (RE). Objectives: In the conditions of the expanding regulatory landscape, existing research offers scattered insights into regulatory compliance of SIPS. This study addresses the pressing need for a structured overview of the state of the art in software RE and its contribution to regulatory compliance of SIPS. Method: We conducted a systematic mapping study to provide an overview of the current state of research regarding challenges, principles, and practices for regulatory compliance of SIPS related to RE. We focused on the role of RE and its contribution to other SIPS lifecycle process areas. We retrieved 6914 studies published from 2017 (January 1) until 2023 (December 31) from four academic databases, which we filtered down to 280 relevant primary studies. Results: We identified and categorized the RE-related challenges in regulatory compliance of SIPS and their potential connection to six types of principles and practices addressing challenges. We found that about 13.6% of the primary studies considered the involvement of both software engineers and legal experts in developing principles and practices. About 20.7% of primary studies considered RE in connection to other process areas. Most primary studies focused on a few popular regulation fields (privacy, quality) and application domains (healthcare, software development, avionics). Our results suggest that there can be differences in terms of challenges and involvement of stakeholders across different fields of regulation. Conclusion: Our findings highlight the need for an in-depth investigation of stakeholders’ roles, relationships between process areas, and specific challenges for distinct regulatory fields to guide research and practice.

Context : Generative Artificial Intelligence (GenAI) and the use of Large Language Models (LLMs) have revolutionized tasks that previously required significant human effort, which has attracted considerable interest from industry stakeholders. This growing interest has accelerated the integration of AI models into various industrial applications. However, the model integration introduces challenges to product quality, as conventional quality measuring methods may fail to assess GenAI systems. Consequently, evaluation techniques for GenAI systems need to be adapted and refined. Examining the current state and applicability of evaluation techniques for the GenAI system outputs is essential. Objective : This study aims to explore the current metrics, methods, and processes for assessing the outputs of GenAI systems and the potential of risky outputs. Method : We performed a snowballing literature review to identify metrics, evaluation methods, and evaluation processes from 43 selected papers. Results : We identified 28 metrics and mapped these metrics to four quality characteristics defined by the ISO/IEC 25023 standard for software systems. Additionally, we discovered three types of evaluation methods to measure the quality of system outputs and a three-step process to assess faulty system outputs. Based on these insights, we suggested a five-step framework for measuring system quality while utilizing GenAI models. Conclusion : Our findings present a mapping that visualizes candidate metrics to be selected for measuring quality characteristics of GenAI systems, accompanied by step-by-step processes to assist practitioners in conducting quality assessments.

Artificial Intelligence can make manufacturing organisations more effective and efficient, but it is not clear which AI tasks hold the greatest potential. Make-to-order manufacturers must constantly adapt to customers’ unique and rapidly changing needs, and therefore have different challenges than make-to-stock manufacturers. Our ambition is to develop an AI-enabled software system to support manufacturing organisations in improving their processes. To this end, we first seek to understand the data and technology requirements for key AI-enabled tasks in a make-to-order setting and determine the level of performance and explainability needed to address them. We perform a multiple case study of five make-to-order packaging manufacturers, interviewing personnel from sales, production, and supply chain to identify and prioritise operational challenges suitable for AI approaches. Demand forecasting emerges as the most important task, followed by predictive maintenance, quality inspection, complex decision risk estimation, and production planning. Participants emphasise the importance of explainable techniques to ensure trust in the systems. The results highlight a need for a greater control of the production process and a better understanding of customer needs. Although most of the tasks could be solved with current techniques, some, such as intermittent demand forecasting and complex decision risk estimation, would require further development. The study clarifies the potential of AI-enabled systems in make-to-order manufacturing and outlines the steps required to realise it.

ABSTRACT Recent studies have shown that many software developers do not have sufficient knowledge and understanding of how to develop a privacy‐friendly system. This may become a challenge in developing systems complying with data protection laws. To address this issue, we investigated the factors that influence developers' decision‐making when developing privacy‐sensitive systems. We conducted an empirical study by means of a survey with 109 practitioners. Our data analysis is based on the principles of social cognitive theory, which includes personal, behavioral, and external environmental factors. We identified six personal, five behavioral, and five external environment factors that affect how developers make decisions regarding privacy, including confusion between privacy and security and reliance on informal practices and organizational support gaps. These findings contribute to understanding how practitioners and companies consider privacy, showing improvements in formal training and structured support over previous studies yet highlighting persistent challenges in consistent privacy integration.

Adversarial Machine Learning (AML) discusses the act of attacking and defending Machine Learning (ML) Models, an essential building block of Artificial Intelligence (AI). ML is applied in many software-intensive products and services and introduces new opportunities and security challenges. AI and ML will gain even more attention from the industry in the future, but threats caused by already-discovered attacks specifically targeting ML models are either overseen, ignored, or mishandled. Current AML research investigates attack and defense scenarios for ML in different industrial settings with a varying degree of maturity with regard to academic rigor and practical relevance. However, to the best of our knowledge, a synthesis of the state of academic rigor and practical relevance is missing. This literature study reviews studies in the area of AML in the context of industry, measuring and analyzing each study’s rigor and relevance scores. Overall, all studies scored a high rigor score and a low relevance score, indicating that the studies are thoroughly designed and documented but miss the opportunity to include touch points relatable for practitioners.

Abstract Context Non-functional requirements (NFRs) (also referred to as system qualities) are essential for developing high-quality software. Notwithstanding its importance, NFR testing remains challenging, especially in terms of automation. Compared to manual verification, automated testing shows the potential to improve the efficiency and effectiveness of quality assurance, especially in the context of Continuous Integration (CI). However, studies on how companies manage automated NFR testing through CI are limited. Objective This study examines how automated NFR testing can be enabled and supported using CI environments in software development companies. Method We performed a multi-case study at four companies by conducting 22 semi-structured interviews with industrial practitioners. Results Maintainability,reliability,performance,securityandscalability, were found to be evaluated with automated tests in CI environments. Testing practices, quality metrics, and challenges for measuring NFRs were reported. Conclusions This study presents an empirically derived model that shows how data produced by CI environments can be used for evaluation and monitoring of implemented NFR quality. Additionally, the manuscript presents explicit metrics, CI components, tools, and challenges that shall be considered while performing NFR testing in practice.

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

The software value chain is knowledge-based since it is highly dependant on people. Consequently, a lack of practice in managing knowledge as a resource may jeopardise its application in software development. Knowledge-Based Resources (KBRs) relate to employees’ intangible knowledge that is deemed to be valuable to a company’s competitive advantage. In this study, we apply a grounded theory approach to examine the role of KBRs in Agile Software Development (ASD). To this aim, we collected data from 18 practitioners from five companies. We develop the Knowledge-Push theory, which explains how KBRs boost the need for change in ASD. Our results show that the practitioners who participated in the study utilise, as primary strategies, task planning, resource management, and social collaboration. These strategies are implemented through the team environment and settings and incorporate an ability to codify and transmit knowledge. However, this process of codification is non-systematic, which consequently introduces inefficiency in the domain of knowledge resource utilisation, resulting in potential knowledge waste. This inefficiency can generate negative implications for software development, including meaningless searches in databases, frustration because of recurrent problems, the unnecessary redesign of solutions, and a lack of awareness of knowledge sources.

Developing software-intensive products or services usually involves a plethora of software artefacts. Assets are artefacts intended to be used more than once and have value for organisations; examples include test cases, code, requirements, and documentation. During the development process, assets might degrade, affecting the effectiveness and efficiency of the development process. Therefore, assets are an investment that requires continuous management. Identifying assets is the first step for their effective management. However, there is a lack of awareness of what assets and types of assets are common in software-developing organisations. Most types of assets are understudied, and their state of quality and how they degrade over time have not been well-understood. We performed an analysis of secondary literature and a field study at five companies to investigate and identify assets to fill the gap in research. The results were analysed qualitatively and summarised in a taxonomy. We present the first comprehensive, structured, yet extendable taxonomy of assets, containing 57 types of assets. The taxonomy serves as a foundation for identifying assets that are relevant for an organisation and enables the study of asset management and asset degradation concepts.

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

Abstract Context: Software companies must become better at delivering software to remain relevant in the market. Continuous integration and delivery practices promise to streamline software deliveries to end-users by implementing an automated software development and delivery pipeline. However, implementing or retrofitting an organization with such a pipeline is a substantial investment, while the reporting on benefits and their relevance in specific contexts/domains are vague. Aim: In this study, we explore continuous software engineering practices from an investment-benefit perspective. We identify what benefits can be attained by adopting continuous practices, what the associated investments and risks are, and analyze what parameters determine their relevance. Method: We perform a multiple case study to understand state-of-practice, organizational aims, and challenges in adopting continuous software engineering practices. We compare state-of-practice with state-of-the-art to validate the best practices and identify relevant gaps for further investigation. Results: We found that companies start the CI/CD adoption by automating and streamlining the internal development process with clear and immediate benefits. However, upgrading customers to continuous deliveries is a major obstacle due to existing agreements and customer push-back. Renegotiating existing agreements comes with a risk of losing customers and disrupting the whole organization. Conclusions: We conclude that the benefits of CI/CD are overstated in literature without considering the contextual and domain complexities rendering some benefits infeasible. We identify the need to understand the customer and organizational perspectives further and understand the contextual requirements towards the CI/CD.

During the development and maintenance of software-intensive products or services, we depend on various artefacts. Some of those artefacts, we deem central to the feasibility of a project and the product’s final quality. Typically, these central artefacts are referred to as assets. However, despite their central role in the software development process, little thought is yet invested into what eventually characterises as an asset, often resulting in many terms and underlying concepts being mixed and used inconsistently. A precise terminology of assets and related concepts, such as asset degradation, are crucial for setting up a new generation of cost-effective software engineering practices. In this position paper, we critically reflect upon the notion of assets in software engineering. As a starting point, we define the terminology and concepts of assets and extend the reasoning behind them. We explore assets’ characteristics and discuss what asset degradation is as well as its various types and the implications that asset degradation might bring for the planning, realisation, and evolution of software-intensive products and services over time. We aspire to contribute to a more standardised definition of assets in software engineering and foster research endeavours and their practical dissemination in a common, more unified direction.

Context: The concept of software craftsmanship has early roots in computing, and in 2009, the Manifesto for Software Craftsmanship was formulated as a reaction to how the Agile methods were practiced and taught. But software craftsmanship has seldom been studied from a software engineering perspective. Objective: The objective of this article is to systematize an anatomy of software craftsmanship through literature studies and a longitudinal case study. Method: We performed a snowballing literature review based on an initial set of nine papers, resulting in 18 papers and 11 books. We also performed a case study following seven years of software development of a product for the financial market, eliciting qualitative, and quantitative results. We used thematic coding to synthesize the results into categories. Results: The resulting anatomy is centered around four themes, containing 17 principles and 47 hierarchical practices connected to the principles. We present the identified practices based on the experiences gathered from the case study, triangulating with the literature results. Conclusion: We provide our systematically derived anatomy of software craftsmanship with the goal of inspiring more research into the principles and practices of software craftsmanship and how these relate to other principles within software engineering in general.

Privacy has become a concern in Agile Software Development (ASD), either to satisfy users' needs or to comply with privacy laws. However, recent studies have shown that ASD approaches still neglect non-functional requirements (NFRs), as is the privacy case. This concern and new data protection laws that came into force recently led companies to face the challenges to understand the laws and to comply with them. In addition, research has shown that many developers do not have sufficient knowledge about how to develop privacy-sensitive software. Motivated by this scenario, this tutorial aims to draw attention to the need to understand privacy from the beginning of the software development lifecycle. Initially, we will present an overview of privacy, as well as several privacy principles. Later, we will show the main data protection laws (In-depth detailing of the General Data Protection Regulation - GDPR). Then, we will discuss how to read and evaluate privacy policies. Finally, we will present an approach for specifying privacy requirements in ASD called Privacy Criteria Method (PCM). At the end of the tutorial, participants will be able to have a critical and technical view of privacy when performing the requirements specification activity.

Abstract Software engineering is decision intensive. Evidence‐based software engineering is suggested for decision‐making concerning the use of methods and technologies when developing software. Software development often includes the reuse of software assets, for example, open‐source components. Which components to use have implications on the quality of the software (e.g., maintainability). Thus, research is needed to support decision‐making for composite software. This paper presents a roadmap for research required to support evidence‐based decision‐making for choosing and integrating assets in composite software systems. The roadmap is developed as an output from a 5‐year project in the area, including researchers from three different organizations. The roadmap is developed in an iterative process and is based on (1) systematic literature reviews of the area; (2) investigations of the state of practice, including a case survey and a survey; and (3) development and evaluation of solutions for asset identification and selection. The research activities resulted in identifying 11 areas in need of research. The areas are grouped into two categories: areas enabling evidence‐based decision‐making and those related to supporting the decision‐making. The roadmap outlines research needs in these 11 areas. The research challenges and research directions presented in this roadmap are key areas for further research to support evidence‐based decision‐making for composite software.

Context: Software start-ups are emerging as suppliers of innovation and software-intensive products. However, traditional software engineering practices are not evaluated in the context, nor adopted to goals and challenges of start-ups. As a result, there is insufficient support for software engineering in the start-up context. Objective: We aim to collect data related to engineering goals, challenges, and practices in start-up companies to ascertain trends and patterns characterizing engineering work in start-ups. Such data allows researchers to understand better how goals and challenges are related to practices. This understanding can then inform future studies aimed at designing solutions addressing those goals and challenges. Besides, these trends and patterns can be useful for practitioners to make more informed decisions in their engineering practice. Method: We use a case survey method to gather first-hand, in-depth experiences from a large sample of software start-ups. We use open coding and cross-case analysis to describe and identify patterns, and corroborate the findings with statistical analysis. Results: We analyze 84 start-up cases and identify 16 goals, 9 challenges, and 16 engineering practices that are common among start-ups. We have mapped these goals, challenges, and practices to start-up life-cycle stages (inception, stabilization, growth, and maturity). Thus, creating the progression model guiding software engineering efforts in start-ups. Conclusions: We conclude that start-ups to a large extent face the same challenges and use the same practices as established companies. However, the primary software engineering challenge in start-ups is to evolve multiple process areas at once, with a little margin for serious errors.

Abstract 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 determine practitioner preference toward one model over another. The objective of this work is to evaluate what characteristics of decision models for asset selection determine industrial practitioner preference of a model when given the choice of a decision model of high precision or a model with high speed. 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. The study shows that the practitioners had clear preference toward the decision model that emphasized speed over the one that emphasized decision precision. This conclusion was determined to be because one of the models was perceived faster, had lower complexity, was more flexible in use for different decisions, and was more agile on 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, we found seven characteristics that the practitioners considered important for their acceptance of the model. 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 the seven identified characteristics that can serve as industrial requirements for future research on decision models for asset selection.

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.

We have conducted in-depth interviews with experienced practitioners in the Safety-Critical Systems (SCS) domain in order to investigate several aspects related to requirements specification and safety analysis for SCS. We interviewed 19 practitioners from eleven SCS companies in different domains with the intention of verifying which approaches they use day-to-day, and what their perceptions are in relation to the approaches used to elicit, analyze, specify and validate safety requirements. The aim of this study is to obtain an in-depth understanding of how requirements engineering is carried out in companies that develop SCS.

Context: Software is an important part in safety-critical system (SCS) development since it is becoming a major source of hazards. Requirements-related hazards have been associated with many accidents and safety incidents. Requirements issues tend to be mitigated in companies with high processes maturity levels since they do their business in a systematic, consistent and proactive approach. However, requirements engineers need systematic guidance to consider safety concerns early in the development process. Goal: the paper investigates which safety practices are suitable to be used in the Requirements Engineering (RE) process for SCS and how to design a safety maturity model for this area. Method: we followed the design science methodology to propose Uni-REPM SCS, a safety module for Unified Requirements Engineering Process Maturity Model (Uni-REPM). We also conducted a static validation with two practitioners and nine academic experts to evaluate its coverage, correctness, usefulness, and applicability. Results: The module has seven main processes, fourteen sub-processes and 148 practices that form the basis of safety processes maturity. Moreover, we describe its usage through a tool. Conclusions: The validation indicates a good coverage of practices and well receptivity by the experts. Finally, the module can help companies in evaluating their current practices.

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.

Developing contemporary software solutions requires many processes and people working in synergy to achieve a common goal. Any misalignment between parts of the software production cycle can severe ...

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.

Background: Organizations adopting Agile Software Development (ASD) use different Knowledge Management (KM) practices to retain and share knowledge. However, it is often the case that knowledge retention is carried out in an ad-hoc way. Aims: In this study, we report our experience from proposing the Knowledge Critically Evaluation Method (KCEM) to evaluate knowledge items (KIT). Our main goal with KCEMs is to support companies to systematically retain knowledge in ASD contexts. Method: We conducted an improvement case study to develop and evaluate KCEM. This research follows the guidelines for technology transfer between industry and academia. The case and unit of analysis is Ericsson, a Swedish company that develops telecommunication solutions. Results: In this paper, we provide initial results of both lab and static validation, enriched by the lessons learned. Conclusions: The preliminary results show that KCEM is easy to understand and use, provides a different perspective on the KIT by visualizing in the criticality chart, and reduces the level of abstraction associated to a knowledge subject area.

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.

Requirements prioritization plays a vital role in software release planning, and the process requires good interaction between stakeholders. Requirement prioritization process is challenging in global software development (GSD) context, where communication and coordination are core bottlenecks. Based on the issues found in the literature and industry survey, this paper proposes a requirements prioritization technique for GSD settings based on stakeholders' weight, vote, and priority (SWVP). The technique has two phases: (1) a calculation of stakeholders' profile weights and setting up communication parameters and (2) a voting process supporting the actual prioritization, based on the weights from phase (1). The proposed technique was applied to three industrial projects. The feedback of the practitioners after using SWVP was encouraging, and the feedback results indicate that SWVP could be a practical solution for requirements prioritization in GSD contexts.

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

Start-up companies have become an important supplier of innovation and software-intensive products. The flexibility and reactiveness of start-ups enables fast development and launch of innovative products. However, a majority of software start-up companies fail before achieving any success. Among other factors, poor software engineering could be a significant contributor to the challenges experienced by start-ups. However, the state-of-practice of software engineering in start-ups, as well as the utilization of state-of-the-art is largely an unexplored area. In this study we investigate how software engineering is applied in start-up context with a focus to identify key knowledge areas and opportunities for further research. We perform a multi-vocal exploratory study of 88 start-up experience reports. We develop a custom taxonomy to categorize the reported software engineering practices and their interrelation with business aspects, and apply qualitative data analysis to explore influences and dependencies between the knowledge areas. We identify the most frequently reported software engineering (requirements engineering, software design and quality) and business aspect (vision and strategy development) knowledge areas, and illustrate their relationships. We also present a summary of how relevant software engineering knowledge areas are implemented in start-ups and identify potentially useful practices for adoption in start-ups. The results enable a more focused research on engineering practices in start-ups. We conclude that most engineering challenges in start-ups stem from inadequacies in requirements engineering. Many promising practices to address specific engineering challenges exists, however more research on adaptation of established practices, and validation of new start-up specific practices is needed.

Knowledge-intensive companies that adopt Agile Software Development (ASD) rely on efficient implementation of Knowledge Management (KM) strategies to promote different Knowledge Processes (KPs) to gain competitive advantage. This study aims to explore how companies that adopt ASD implement KM strategies utilizing practices that promote the KPs in the different organizational layers. Through a systematic literature review, we analyzed 32 primary studies, selected by automated search and snowballing in the extant literature. To analyze the data, we applied narrative synthesis. Most of the identified KM practices implement personalization strategies (81%), supported by codification (19%). Our review shows that the primary studies do not report KM practices in the strategic layer and two of them in the product portfolio layer; on the other hand, in the project layer, the studies report 33 practices that implement personalization strategy, and seven practices that implement codification. KM strategies in ASD promote mainly the knowledge transfer process with practices that stimulates social interaction to share tacit knowledge in the project layer. As a result of using informal communication, a significant amount of knowledge can be lost or not properly transferred to other individuals and, instead of propagating the knowledge, it remains inside a few individuals’ minds.

Attaining effective communication within and across organizational units is among the most critical challenges for success in software development organizations. This paper presents a novel model, supporting analysis of problems in inter-departmental communication events. The model was developed and designed based on industrial needs emphasizing flexibility, applicability and scalability. The model covers central communication aspects in order to provide a useful approximation of communication problems rather than in-depth modeling on message-by message basis. Other event-specific information, such as costs, can then be attached to enrich analysis and understanding. To exemplify and evaluate the model and collect feedback from industry, it was applied to 16 events at a Swedish automotive manufacturer where communication between two departments had broken down during development of software-intensive systems. The evaluation showed that the model helped structure and conduct systematic data collection and analysis of dysfunctional communication patterns. We found that insufficient understanding of the matters being communicated was prevalent, but also more specifically, requirements were insufficiently balanced, detailed and specified over the full system development cycle. Besides, the long-term cost for the company was analyzed in depth for each event, yielding a total estimated cost for the analyzed communication events of 11.2MUS$.

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.

Context: Requirements issues tend to be mitigated in organizations with high process maturity levels since they do their business in a systematic, consistent and proactive approach. In a Safety-Critical System (SCS), requirements problems have been associated with accidents and safety incidents. Objective: This work investigates which safety practices/actions are suitable to be used in the Requirements Engineering (RE) process of SCS and how to design a safety maturity model for this area. Method: we adopted different empirical techniques to propose Uni-REPM SCS, which consists of a safety module to be included in the Unified Requirements Engineering Process Maturity Model (Uni-REPM). Results: The safety module has seven main processes, 14 sub-processes and 148 safety actions describing principles and practices that form the basis of safety processes maturity. Conclusions: Preliminary validation with two practitioners and nine academic experts indicates that the safety module can help organizations to evaluate their current safety practices with respect to their RE process. Moreover, it also offers a step-wise improvement strategy to raise their safety maturity level.

The choice of which software component to use influences the success of a software system. Only a few empirical studies investigate how the choice of components is conducted in industrial practice. This is important to understand to tailor research solutions to the needs of the industry. Existing studies focus on the choice for off-the-shelf (OTS) components. It is, however, also important to understand the implications of the choice of alternative component sourcing options (CSOs), such as outsourcing versus the use of OTS. Previous research has shown that the choice has major implications on the development process as well as on the ability to evolve the system. The objective of this study is to explore how decision making took place in industry to choose among CSOs. Overall, 22 industrial cases have been studied through a case survey. The results show that the solutions specifically for CSO decisions are deterministic and based on optimization approaches. The non-deterministic solutions proposed for architectural group decision making appear to suit the CSO decision making in industry better. Interestingly, 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.

Abstract Background Software reuse is often seen as a cost avoidance rather than a gained value. This results in a rather one‐sided debate where issues such a resource control, release schedule, quality, or reuse in more than one release are neglected. Aims We propose a reuse value assessment framework, intended to provide a more nuanced view of the value and costs associated with different reuse candidates. Method This framework is constructed based on findings from an interview study at a large software development company. Results The framework considers the functionality, compliance to standards, provided quality, and provided support of a reuse candidate, thus enabling an informed comparison between different reuse candidates. Furthermore, the framework provides means for tracking the value of the reused asset throughout subsequent releases. Conclusions The reuse value assessment framework is a tool to assist in the selection between different reuse candidates. The framework also provides a means to assess the current value of a reusable asset in a product, which can be used to indicate where maintenance efforts would increase the utilized potential of the reusable asset.

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.

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

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.

Value stream mapping (VSM) is one of the several Lean practices, which has recently attracted interest in the software engineering community. In other contexts (such as military, health and production), VSM has achieved considerable improvements in processes and products. The goal is to capitalize on these benefits in the software intensive product development context. The primary contribution is that we are extending the definition of waste to fit in the software intensive product development context. As traditionally in VSM everything that is not considered valuable is waste, we do this practically by looking at value beyond the customer perspective and using the software value map. An evaluation has been conducted through an industrial case study. First, the instantiation and motivations for selecting certain strategies have been provided. Second, the outcome of the VSM is described in detail. The instantiation of VSM via workshops was considered good as workshops allowed active interaction and discussion stakeholders' groups that are distant from each other in the regular work. With respect to waste and improvement identification, the participants were able to identify similar improvement suggestions. In a retrospective, the value stream approach was perceived positively by the practitioners with respect to process and outcome. Copyright © 2014 John Wiley & Sons, Ltd.

SUMMARY Software Process Improvement (SPI) encompasses the analysis and modification of the processes within software development, aimed at improving key areas that contribute to the organizations' goals. The task of evaluating whether the selected improvement path meets these goals is challenging. On the basis of the results of a systematic literature review on SPI measurement and evaluation practices, we developed a framework (SPI Measurement and Evaluation Framework (SPI‐MEF)) that supports the planning and implementation of SPI evaluations. SPI‐MEF guides the practitioner in scoping the evaluation, determining measures, and performing the assessment. SPI‐MEF does not assume a specific approach to process improvement and can be integrated in existing measurement programs, refocusing the assessment on evaluating the improvement initiative's outcome. Sixteen industry and academic experts evaluated the framework's usability and capability to support practitioners, providing additional insights that were integrated in the application guidelines of the framework. Copyright © 2013 John Wiley & Sons, Ltd.

Requirements Engineering and Software Testing are mature areas and have seen a lot of research. Nevertheless, their interactions have been sparsely explored beyond the concept of traceability. To fill this gap, we propose a definition of requirements engineering and software test (REST) alignment, a taxonomy that characterizes the methods linking the respective areas, and a process to assess alignment. The taxonomy can support researchers to identify new opportunities for investigation, as well as practitioners to compare alignment methods and evaluate alignment, or lack thereof. We constructed the REST taxonomy by analyzing alignment methods published in literature, iteratively validating the emerging dimensions. The resulting concept of an information dyad characterizes the exchange of information required for any alignment to take place. We demonstrate use of the taxonomy by applying it on five in-depth cases and illustrate angles of analysis on a set of thirteen alignment methods. In addition, we developed an assessment framework (REST-bench), applied it in an industrial assessment, and showed that it, with a low effort, can identify opportunities to improve REST alignment. Although we expect that the taxonomy can be further refined, we believe that the information dyad is a valid and useful construct to understand alignment.

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.

SUMMARY In software intensive products such as cars or telecom systems, software has traditionally been associated with cost, and there has been no real perception of its value in relation to the entire product offering. However, because software is becoming a larger part of the main competitive advantage, driving innovation and product differentiation, hardware is becoming more standardized, thus the valuation of software is becoming critical. In existing literature, several value constructs and corresponding valuation/measurement solutions needed for making decisions about software product development are presented. However, the contributions are often isolated with respect to a certain perspective such as focusing on product's internal or external quality aspects only. Consequently, a complete view of value constructs relevant from different perspectives required for making decisions about software product development is missing. This paper presents a consolidated view of the software value concept utilizing the major perspectives and introduces a software value map. The created value map was evaluated through an industry case study through the development of impact evaluation patterns, which were subsequently used by professionals in industry, and experiences gathered. During industry evaluation, practitioners found substantial benefits of having a consolidated, vastly improved, and extended value aspect's view of software. Copyright © 2012 John Wiley & Sons, Ltd.

Knowledge management (KM) in software engineering and software process improvement (SPI) are challenging. Most existing KM and SPI frameworks are too expensive to deploy or do not take an organization's specific needs or knowledge into consideration. There is thus a need for scalable improvement approaches that leverage knowledge already residing in the organizations. This paper presents the Practice Selection Framework (PSF), an Experience Factory approach, enabling lightweight experience capture and use by utilizing postmortem reviews. Experiences gathered concern performance and applicability of practices used in the organization, gained from concluded projects. Project managers use these as decision support for selecting practices to use in future projects, enabling explicit knowledge transfer across projects and the development organization as a whole. Process managers use the experiences to determine if there is potential for improvement of practices used in the organization. This framework was developed and subsequently validated in industry to get feedback on usability and usefulness from practitioners. The validation consisted of tailoring and testing the framework using real data from the organization and comparing it to current practices used in the organization to ensure that the approach meets industry needs. The results from the validation are encouraging and the participants' assessment of PSF and particularly the tailoring developed was positive.

The automotive industry is facing a tremendous growth in the engineering of software-intensive systems, giving rise to various challenges. To prevent problems related to the fit of new software technologies in vehicles and the manufacturing processes, a well functioning interaction between the functions for product development and manufacturing is crucial. This is complicated by the fact that the changeable nature of software development causes unprecedented needs for collaboration and coordination between these two functions. This paper reports on a process assessment that focuses on the interface between the functions for product development and manufacturing in the development and design of software-intensive automotive systems. The main purpose of the study was to identify the key issues for improvement in the area assessed. The assessment was performed at two Swedish automotive companies where data were collected from documents and in interviews with practitioners. Nine key improvement issues were established ranging from challenges in requirements engineering to the need for knowledge transfer between manufacturing and product development. In addition, to increase the understandability of the results and map possible avenues for solution and future research, the paper provides an extensive analysis of each improvement issue in relation to the state-of-the-art.

Requirements traceability enables software engineers to trace a requirement from its emergence to its fulfillment. In this paper we examine requirements traceability definitions, challenges, tools and techniques, by the use of a systematic review performing an exhaustive search through the years 1997–2007. We present a number of common definitions, challenges, available tools and techniques (presenting empirical evidence when found), while complementing the results and analysis with a static validation in industry through a series of interviews.

SUMMARY The area of software product development of software intensive products has received much attention, especially in the area of requirements engineering and product management. Many companies are faced with new challenges when operating in an environment where potential requirements number in thousands or even tens of thousands, and where a product does not have a customer, but any number of customers or markets. The development organization carries not only all the costs of development, but also takes all the risks. In this environment traditional bespoke requirements engineering, together with traditional process assessment and improvement models fall short as they do not address the unique challenges of a market‐driven environment. This paper introduces the Market‐driven Requirements Engineering Process Model, aimed at enabling process improvement and process assurance for organizations faced with these new challenges. The model is also validated in the industry through three case studies where the model is used for process assessment and improvement suggestion. Initial results show that the model is appropriate for process improvement for organizations operating in a market‐driven environment. In addition, the model was designed to be light weight in terms of low cost and thus adapted not only for large organizations but suitable for small and medium enterprises as well. Copyright © 2011 John Wiley & Sons, Ltd.

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

BACKGROUND—Software Process Improvement (SPI) is a systematic approach to increase the efficiency and effectiveness of a software development organization and to enhance software products. OBJECTIVE—This paper aims to identify and characterize evaluation strategies and measurements used to assess the impact of different SPI initiatives. METHOD—The systematic literature review includes 148 papers published between 1991 and 2008. The selected papers were classified according to SPI initiative, applied evaluation strategies, and measurement perspectives. Potential confounding factors interfering with the evaluation of the improvement effort were assessed. RESULTS—Seven distinct evaluation strategies were identified, wherein the most common one, “Pre-Post Comparison,” was applied in 49 percent of the inspected papers. Quality was the most measured attribute (62 percent), followed by Cost (41 percent), and Schedule (18 percent). Looking at measurement perspectives, “Project” represents the majority with 66 percent. CONCLUSION—The evaluation validity of SPI initiatives is challenged by the scarce consideration of potential confounding factors, particularly given that “Pre-Post Comparison” was identified as the most common evaluation strategy, and the inaccurate descriptions of the evaluation context. Measurements to assess the short and mid-term impact of SPI initiatives prevail, whereas long-term measurements in terms of customer satisfaction and return on investment tend to be less used.

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

Abstract Current practices in the industry are moving towards the market‐driven development of software intensive products compared to customer‐specific system development. Consequently, product management is faced with several challenges that have to be addressed as a part of the market‐driven requirements engineering process. One of the important challenges is how to select the right mix of requirements, balancing short‐term and long‐term gains. One way to address this challenge is to utilize product strategies for selecting requirements. However, in order to do this the internal success‐critical stakeholders (SCS) involved in strategies creation and requirements selection need to be aligned with respect to a product's strategic goals and objectives. This paper presents a method to enable the evaluation of degree of alignment between SCS with respect to the understanding and interpretation of a product's strategy. Further, the method not only enables the evaluation of alignment, but also specifically shows misalignment, and enables the identification of leading causes. The method has been developed in collaboration with the industry and its application is shown through a case study at Ericsson AB. Copyright © 2011 John Wiley & Sons, Ltd.

We present the first results from a survey carried out over the second quarter of 2009 examining how theories in object-oriented design are understood and used by software developers. We collected 3785 responses from software developers world-wide, which we believe is the largest survey of its kind. We targeted the use of encapsulation, class size as measured by number of methods, and depth of a class in the inheritance hierarchy. We found that, while overall practitioners followed advice on encapsulation, there was some variation of adherence to it. For class size and depth there was substantially less agreement with expert advice. In addition, inconsistencies were found within the use and perception of object-oriented concepts within the investigated group of developers. The results of this survey has deep reaching consequences for both practitioners and researchers as they highlight and confirm central issues.

Agile development methods such as extreme programming (XP), SCRUM, Lean Software Development (Lean SD) 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 article we investigate the applicability of agile principles in the context of market-driven software product development (MDPD), focusing on pre-project activities. This article 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. Copyright © 2009 John Wiley & Sons, Ltd.

Increased popularity of global software engineering (GSE) has resulted in quite a number of research and industrial studies. As the area matures, an increased focus on empirically supported results leads to a greater potential impact on future research and industrial practice. However, since GSE scenarios are diverse, what works in one context might not directly apply in another. Thus it is necessary to understand, how GSE-related empirical findings should be reported to be useful for practitioners and researchers. Furthermore, itdasias important to summarize progress and get the big picture of published research to identify gaps and commonalities. In this paper we analyze differentiating factors of GSE scenarios and offer a classification scheme for describing the context of a GSE study. In addition, we report initial results of a systematic review on GSE-related empirical literature using papers from ICGSE 2006 and 2007, at the same time illustrating and evaluating the proposed scheme.

In market-driven product development large numbers of requirements threaten to overload the development organization. It is critical for product management to select the requirements aligned with the overall business goals and discard others as early as possible. This paper presents a method that utilizes strategies for early requirements triage. The method presented is based on good practices from management literature customized for technical product strategy formulation. The creation of the method was also inspired by industry needs through exploratory interviews covering requirements triage and selection processes as well as strategy formulation. After creation, the method was subsequently validated in industry where the aspects of usability and usefulness were investigated, yielding promising initial results.

GREW'07 brings researchers and industry practitioners together to discuss the area of global product development from a requirements engineering and product management perspective. The workshop aims at analyzing selected challenges, which are put forward by accepted papers, in detail. The session discussions then lift the view in an attempt to identify the future needs with regards to research and study. Industry presence at the workshop is intended to ground the discussions of future research, helping to assure relevance and usefulness from both an industrial and an academic perspective.

Abstract Software process improvement is a challenge in general and in particular for small‐ and medium‐sized companies. Assessment is one important step in improvement. However, given that a list of improvement issues has been derived, it is often very important to be able to prioritize the improvement proposals and also look at the potential dependencies between them. This paper comes from an industrial need to enable prioritization of improvement proposals and to identify their dependencies. The need was identified in a small‐ and medium‐sized software development company. Based on the need, a method for prioritization and identification of dependencies of improvement proposals was developed. The prioritization part of the method is based on a multi‐decision criteria method and the dependencies are identified using a dependency graph. The developed method has been successfully applied in the company, where people with different roles applied the method. The paper presents both the method as such and the successful application of it. It is concluded that the method worked as a means for prioritization and identification of dependencies. Moreover, the method also allowed the employees to discuss and reason about the improvement actions to be taken in a structured and systematic way. Copyright © 2004 John Wiley & Sons, Ltd.