Abstract Context and Motivation: In 2016, the European Union introduced ‘innovation partnerships’ to facilitate innovative development of the EU through public procurement. Requirements engineering is one of the main challenges in the public procurement of innovative products. Nevertheless, there is little empirical research on public procurement, particularly managing requirements in the pre-tender dialogue phase between potential suppliers and problem owners. Question/Problem: This paper investigates the market dialogue phase of an innovation partnership project in Norway. We aim to understand critical factors of the dialogue phase that clarify and focus needs and requirements. This leads to the research question: How can we clarify and focus needs and requirements for a new solution in the market dialogue phase? Principal Ideas/Results: We have conducted a case study at a major Norwegian hospital. The objective of this innovation partnership is to make the emergency room in a Norwegian hospital more efficient. The case study illustrates how requirements have been developed by the joint effort of the procurement team, the active engagement of potential suppliers, and the learning and mutual trust between them. By discussing the vision and getting feedback on opportunities and limitations in existing and projected technologies, the procurement team has refined their ambition and focused on the core of the innovation. Contribution: This paper contributes to the literature on requirement engineering in public procurement by describing how requirements are focused during the dialogue phase of an innovation partnership facilitated by a cross-functional procurement team with sufficient competencies, resources, and trust.

Abstract To satisfy the need for analytical data in the development of digital services, many organizations use data warehouse, and, more recently, data lake architectures. These architectures have traditionally been accompanied by centralized organizational models, where a single team or department has been responsible for gathering, transforming, and giving access to analytical data. However, such centralized models presuppose stability and are incompatible with agile software development where applications and databases are continuously updated. To achieve more agile forms of data management, some organizations have therefore begun to experiment with distributed data management models such as “data meshes”. Research on this topic is however limited. In this paper, we report findings from a case study of a public sector organization in Norway that has begun the transition from centralized to distributed data management, outlining both the benefits and challenges of a distributed approach.

Eliciting scalability requirements during agile software development is complicated and poorly described in previous research. This article presents a lightweight artifact for eliciting scalability requirements during agile software development: the ScrumScale model. The ScrumScale model is a simple spreadsheet. The scalability concepts underlying the ScrumScale model are clarified in this design science research, which also utilizes coordination theory. This paper describes the open banking case study, in which a legacy banking system becomes open. This challenges the scalability of this legacy system. The first step in understanding this challenge is to elicit the new scalability requirements. In the open banking case study, key stakeholders from TietoEVRY spent 55 h eliciting the scalability requirements of TietoEVRY’s open banking project. According to TietoEVRY, the ScrumScale model provided a systematic way of producing scalability requirements. For TietoEVRY, the scalability concepts behind the ScrumScale model also offered significant advantages in dialogs with other stakeholders.

Architectural technical debt can be generated by changes in the business and the environment of an organization. In this paper, we emphasize the change in scalability requirements due to new regulations. Scalability is the ability of a system to handle an increased workload. For complex systems that are abruptly exposed via open interfaces and hence a greater workload, the scalability requirements may quickly increase, leading to technical debt. We term this scalability debt. This paper describes scalability triage, a light-weight, novel technique for identifying scalability threats as a form of technical debt. We illustrate this technique with an open banking case from a large software organization. Open banking is partly caused by the new European PSD2 regulative that enforce banks to open interfaces to unknown third-party actors. Banking systems are well-established, mature systems. However, with the advent of open banking and PSD2, the workload may quickly rocket. This leads to tougher scalability requirements and accumulated architectural debt, despite previously sound architectural decisions. Using scalability triage, such risks may be identified fast. It will then be possible to prevent this form of technical debt with timely reengineering.

Abstract Scalability engineering is currently not well integrated into agile development techniques. This paper extends agile development techniques so that scalability can be handled in an incremental and iterative development process. By scalability we mean the ability of a system to handle increasing workload. We propose the ScrumScale Method which includes scalability engineering in Scrum. This extension should also be applicable to other agile techniques. For scalability testing, we indicate how quality thresholds should be scaled up or down according to the degree of completeness of the product, test hardware, test software, test data and test workload. Using action research, we have conducted three pilots in three Norwegian software organizations. These three pilots have different architectures and operate in different markets yet have in common scalability challenges.

Patient-centered care encourages active involvement of patients in their own treatment and a collaborative perspective on the relationship between patient and practitioner. However, to achieve constructive patient–practitioner collaboration in medical consultations the partakers need to successfully interact across conceptual boundaries that can impede intersubjectivity, i.e., the construction of shared meanings and understandings in communicative activities. We present a synthesis of a user-centered approach to designing interactive technology supporting collaboration in face-to-face consultations related to audiological (hearing) rehabilitation. Specifically, we focus on the case of hearing aid tuning, and on the design and utility assessment of a prototype sound environment simulator intended to support the process by helping the patient and the practitioner build a joint understanding of the individual patient’s hearing problem and perceived effects of treatment actions. We describe an empirical and qualitative investigation that calls specific attention to the multi-dimensional boundaries involved in collocated patient–practitioner interactions, and to the explorative and situated nature of the consultation as a collaborative problem-solving process. Here, various micro-practices play a key role in gradually forming a better understanding of the problem at hand and in identifying appropriate treatment steps. Our findings suggest that patient–practitioner collaboration can benefit from interactive technology, which is sufficiently flexible or open-ended in terms of use to accommodate, or be appropriated, to the immediate needs of the situation. We argue that designing technology with the aim of enhancing existing practices of intersubjectivity, rather than doing away with them, improves the chances of enriching collocated patient–practitioner interaction and reduces risk of obstructing it. The main research contribution is an increased understanding of the medical consultation as an instance of collocated collaborative work and learning, and the challenges and opportunities that lie in co-designing interactive solutions that can help the patient take an active and contributing part in the situation.

Avionic systems for communication, navigation, and flight control, and many other functions are complex and crucial components of any modern aircraft. Present day avionic systems are increasingly based on computers and a growing percentage of system complexity can be attributed to software. An error in the software of a safety-critical avionic system could lead to a catastrophic event, such as multiple deaths and loss of the aircraft. To demonstrate compliance with airworthiness requirements, certification agencies accept the use of RTCA document DO-178 for the software development. Avionics software development is typically complex and is traditionally reliant on a strict plan-driven development process, characterized by early fixture of detailed requirements and late production of working software. In this process, requirement changes and solving software errors can lead to much rework, and create a risk of budget and schedule overruns. This raises the question whether avionics software development could benefit from the application of agile approaches. Based on the results of three activities: (1) a literature study on industrial experience with the use of agile methods in a DO-178 context, (2) an expert assessment of the DO-178 objectives, and (3) a survey conducted among European avionics industry, an outline is presented of an agile development process, where Scrum is extended to achieve the DO-178 objectives. The application of agile methods is expected to support frequent delivery of working software and ability to respond to changes, resulting in reduced risk of budget and schedule overruns.

This paper explores how interactive technology can help overcome barriers to active patient participation in audiological consultations involving hearing aid tuning. We describe the design and evaluation of a prototype sound simulator intended to trigger reflection in patients regarding their hearing experiences, and help guide the tuning process. The prototype was tested in twelve consultations. Our findings suggest that it helped facilitate patient participation during the tuning process by: (1) encouraging an iterative, patient-driven approach; (2) stimulating context-specific feedback and follow-up questions; (3) helping patients make sense of medical information and treatment actions; (4) offering patient control over the process pace and what situations to optimize for; and (5) promoting reflections on daily hearing aid use. Post-consultation interviews revealed that the prototype was perceived useful in several ways. Our results highlight the benefit of flexible designs that can be appropriated to fit the spontaneous needs of patients and audiologists

Various agile methods have several quality assurance mechanisms embedded in the process itself, without any explicit QA role. In principle, the team takes care of quality assurance during sprints and as part of daily stand-ups, sprint reviews and retrospectives. We have defined SafeScrum, a variant of Scrum with some additional XP techniques that can be used to develop safety-critical software and have the software certified according to the IEC 61508 standard. This imposes a load of additional requirements on the process. In a recent industrial case, we have experienced that the quality assurance mechanisms in Scrum becomes insufficient. We have therefore analyzed the standard, consulted an independent assessor and worked with the Scrum team to identify necessary additional tasks for a team-internal QA role to be added to the SafeScrum process.

Most large software companies are involved in offshore development of some sort, and now the trend is that small and medium sized companies are also going global. While empirical research suggests that offshoring are not always successful, evidence explaining the reasons for terminated collaborations is scarce, especially for small and medium sized companies. In this paper we explore the stories of three Scandinavian medium-sized software companies that have terminated their offshore outsourcing relationships and changed to offshore insourcing arrangements. The main reason for termination was disappointing low quality of the software delivered, being caused by insufficient domain knowledge, high turnover and a lack of motivation among the remote and external developers. We apply the theory of single-loop and double-loop learning in order to explain why the companies failed to correct the experienced problems, and the theory of escalating commitment to explain why the companies did not correct the failing course of action earlier. Finally we describe the change in the choice of the principle sourcing strategy from outsourcing to insourcing.

Abstract This paper reports on a study of a software product line organization that has adopted agile software development to address process rigidity and slowing performance. Experience has showed that despite some impediments, this has become a valuable change to both the organization and its development process. The aim of this study is to identify and understand enabling factors of a combined process, and to understand their subsequent effects. Qualitative data are summarized and analyzed, giving insight into the actions taken, their effects that have emerged over time, and the enabling and contextual factors. The study concludes that a combined process is feasible, that the simplified approach makes the organization more flexible and thus capable of serving a volatile market with fast‐changing technologies. This has also enabled the organization to collaborate better with external actors. Copyright © 2011 John Wiley & Sons, Ltd.

Software entropy is a phenomenon where repeated changes gradually degrade the structure of the system, making it hard to understand and maintain. This phenomenon imposes challenges for organizations that have moved to agile methods from other processes, despite agile's focus on adaptability and responsiveness to change. We have investigated this issue through an industrial case study, and reviewed the literature on addressing software entropy, focussing on the detection of ldquocode smellsrdquo and their treatment by refactoring. We found that in order to remain agile despite of software entropy, developers need better support for understanding, planning and testing the impact of changes. However, it is exactly work on refactoring decision support and task complexity analysis that is lacking in literature. Based on our findings, we discuss strategies for dealing with entropy in this context and present avenues for future research.

Systematic reviews are one of the key building blocks of evidence-based software engineering. Current guidelines for such reviews are, for a large part, based on standard meta-analytic techniques. However, such quantitative techniques have only limited applicability to software engineering research. In this paper, therefore, we describe our experience with an approach to combine diverse study types in a systematic review of empirical research of agile software development.