Code-based analyzers often find too many potentially security-related issues to address them all. Therefore, issues likely to lead to vulnerabilities should be fixed first. Such prioritization requires project-specific knowledge, such as quality requirements, security-related decisions, and design, which is not accessible to code analyzers. We present TraceSEC, an automated technique for prioritizing issues according to their security-related importance to the project. Its core concept is to incorporate available design artifacts and trace links between them, thus considering the project context that the code lacks. We reduce the problem of issue prioritization to a maximum flow problem and quantify the importance of each issue by the flow from user-defined quality aspects to the issue, i.e., quantifying its impact on project-specific security preferences. Our evaluation shows that TraceSEC effectively provides automated prioritization and can be tailored to project-specific quality goals. Its prioritization correlates stronger with manual expert prioritization than SonarQube rule severities, which are commonly used in practice. In particular, TraceSEC has a higher similarity for identifying high-priority issues. TraceSEC scales reasonably well for codebases up to four million lines of code, and the initial setup overhead is likely to be recouped after the first automated prioritization.

In today’s digitalized world, where software systems are becoming increasingly ubiquitous and complex, the quality aspect of explainability is gaining relevance. A major challenge in achieving adequate explanations is the elicitation of individual explanation needs, as it may be subject to severe hypothetical or confirmation biases. To address these challenges, we aim to establish user-based indicators concerning user behavior or system events that can be captured at runtime to determine when a need for explanations arises. In this work, we conducted exploratory research by means of an online study to collect self-reported indicators that could indicate a need for explanation. We compiled a catalog containing 17 relevant indicators concerning user behavior, 8 indicators concerning system events and 14 indicators concerning emotional states or physical reactions. We also analyze the relationships between these indicators and different types of need for explanation. The established indicators can be used in the elicitation process through prototypes, as well as after publication to gather requirements from already deployed applications using telemetry and usage data. Moreover, these indicators can be used to trigger explanations at appropriate moments during the runtime.

As software systems grow increasingly complex, explainability has become a crucial non-functional requirement for transparency, user trust, and regulatory compliance. Eliciting explainability requirements is challenging, as different methods capture varying levels of detail and structure. This study examines the efficiency and effectiveness of three commonly used elicitation methods—focus groups, interviews, and online surveys—while also assessing the role of taxonomy usage in structuring and improving the elicitation process. We conducted a case study at a large German IT consulting company, utilizing a web-based personnel management software. A total of two focus groups, 18 interviews, and an online survey with 188 participants were analyzed. The results show that interviews were the most efficient, capturing the highest number of distinct needs per participant per time spent. Surveys collected the most explanation needs overall but had high redundancy. Delayed taxonomy introduction resulted in a greater number and diversity of needs, suggesting that a two-phase approach is beneficial. Based on our findings, we recommend a hybrid approach combining surveys and interviews to balance efficiency and coverage. Future research should explore how automation can support elicitation and how taxonomies can be better integrated into different methods.

As the complexity of modern software is steadily growing, these systems become increasingly difficult to understand for their stakeholders. At the same time, opaque and artificially intelligent systems permeate a growing number of safety-critical areas, such as medicine and finance. As a result, explainability is becoming more important as a software quality aspect and non-functional requirement. Contemporary research has mainly focused on making artificial intelligence and its decision-making processes more understandable. However, explainability has also gained traction in recent requirements engineering research. This work aims to contribute to that body of research by providing a quality model for explainability as a software quality aspect. Quality models provide means and measures to specify and evaluate quality requirements. In order to design a user-centered quality model for explainability, we conducted a literature review. We identified ten fundamental aspects of explainability. Furthermore, we aggregated criteria and metrics to measure them as well as alternative means of evaluation in the form of heuristics and questionnaires. Our quality model and the related means of evaluation enable software engineers to develop and validate explainable systems in accordance with their explainability goals and intentions. This is achieved by offering a view from different angles at fundamental aspects of explainability and the related development goals. Thus, we provide a foundation that improves the management and verification of explainability requirements. • Literature review on criteria and measures for explainability. • Quality model for explainability including ten aspects of explainability. • User-centered metrics, heuristics and questionnaires to evaluate explainability.

Ensuring traceability of safety- and security-related artifacts is vital in software development to comply with standards and mitigate risks. Despite its importance, the practical implementation of defining and tracing safety- and security-relevant artifacts remains ambiguous. Based on eight semi-structured interviews with industry experts, this work explores the definitions, methods, processes, and challenges of tracing safety- and security-related artifacts. The interviews revealed that definitions of safety- and security-relevant artifacts are highly context-dependent, shaped by regulatory standards, internal processes, technical characteristics, and practitioner judgment. Rather than signaling a deficiency, this variability reflects the inherently multifaceted nature of safety and security work, where artifact classification emerges from practical reasoning rather than strict or universal criteria. Tools play a key role in supporting traceability, and cross-team alignment remains a concern in practice. Our findings provide actionable insights for organizations seeking to strengthen traceability. The recommendations encourage the development of internal classification criteria, support effective collaboration with external partners, support guidance, onboarding, and training, and help align practices with across teams, fostering more reliable and transparent management of safety- and security-relevant artifacts.

Requirements Elicitation (RE) is a crucial activity especially in the early stages of software development. GUI prototyping has widely been adopted as one of the most effective RE techniques for user-facing software systems. However, GUI prototyping requires (i) the availability of experienced requirements analysts, (ii) typically necessitates conducting multiple joint sessions with customers and (iii) creates considerable manual effort. In this work, we propose SERGUI, a novel approach enabling the Self-Elicitation of Requirements (SER) based on an automated GUI prototyping assistant. SERGUI exploits the vast prototyping knowledge embodied in a large-scale GUI repository through Natural Language Requirements (NLR) based GUI retrieval and facilitates fast feedback through GUI prototypes. The GUI retrieval approach is closely integrated with a Large Language Model (LLM) driving the prompting-based recommendation of GUI features for the current GUI prototyping context and thus stimulating the elicitation of additional requirements. We envision SERGUI to be employed in the initial RE phase, creating an initial GUI prototype specification to be used by the analyst as a means for communicating the requirements. To measure the effectiveness of our approach, we conducted a preliminary evaluation. Video presentation of SERGUI at: https://youtu.be/pzAAB9Uht80

Modern software systems are becoming increasingly complex and opaque. The integration of explanations within software has shown the potential to address this opacity and can make the system more understandable to end-users. As a result, explainability has gained much traction as a non-functional requirement of complex systems. Understanding what type of system requires what types of ex-planations is necessary to facilitate the inclusion of explainability in early software design processes. In order to specify explain-ability requirements, an explainability taxonomy that applies to a variety of different software types is needed. In this paper, we present the results of an online survey with 84 participants. We asked the participants to state their questions and confusions concerning their three most recently used software systems and elicited both explicit and implicit explainability needs from their statements. These needs were coded by three researchers. In total, we identified and classified 315 explainability needs from the survey answers. Drawing from a large pool of explainability needs and our coding procedure, we present two major contributions of this work: 1) a taxonomy for explainability needs in everyday software systems and 2) an overview of how the need for explanations differs between different types of software systems.

With the rise of artificial intelligence in industry, many companies rely on machine learning methods such as time series forecasting. By processing data from the past, such systems can provide predictions for data in the future. In practice, however, there is often skepticism about the quality of the forecasts. Explainability has been identified as a means to address this skepticism and foster trust. While there are already different methods to explain time series forecasts, it is unclear which of these explanations are actually useful for stakeholders. To investigate the need for explanations for time series forecasts, we conducted a study at a mid-sized German company in the energy domain. Throughout the study, 23 participants were shown five examples of different explanation types. For each type of explanation, we tested if it actually helped our participants to better understand the forecasts. We found that visual explanations including decision trees and feature importance charts were able to improve domain experts' understanding of time series forecasts. Textual explanations tended to lead to confusion rather than empowerment. While the exact findings and preferable types of explanations may vary between companies, our concrete results can provide a starting point for in-depth analyses in other environments.

Misalignments between stakeholders' project visions can lead to the elicitation of conflicting requirements. When these conflicts remain undetected, they can necessitate costly changes in late stages of the development process. One approach to avoid such conflicts are so-called vision videos. Vision videos present the project vision held by the stakeholders that create the vision videos. By watching a video created by their peers, stakeholders can detect and resolve misalignments between their project vision and the one presented in the video. Thus far, research has focused on how to create vision videos. Research on how to watch and use a vision video for requirements validation has been limited. If vision videos are created with care, but used without consideration, their full potential may be lost. In this paper, we aim to lay the groundwork for future research on the usage of vision videos by conducting an exploratory study with 128 students working in 21 project teams. Each team used vision videos to align their project vision with those of their customers. Based on this study, we identify 5 possible research avenues and present corresponding research questions. In doing so, we pave the way towards an effective usage of vision videos.

Abstract The benefits of traceability have widely been discussed in research. However, studies have also shown that traceability practices are still not prevalent in industrial settings due to the high manual effort and lack of tool support. In this paper, we explore the feasibility of using eye tracking to automatically detect trace links to reduce manual effort and thereby increase practical applicability. We conducted a two-stage interview study in industry. In Stage 1 we interviewed 20 practitioners to provide an overview of how traceability is established in practice and how an eye tracking approach would need to be applied in order to be useful. In Stage 2 we conducted interviews with 16 practitioners from one project context to elicit role-specific workflows and analyzed which activities are suitable to obtain useful traceability links based on gaze data. As there is no one-fits-all solution to traceability, and technical limitations of eye tracking still exist, we collected information on used artifact types, tools and requirements management practices to adjust an approach to actual traceability stakeholders’ needs. We report on perspectives from different roles in software projects and give an overview of traced artifacts, current traceability experiences, as well as benefits and doubts concerned with using eye tracking to obtain links automatically. We discuss the implications for the evaluation and implementation of an automatic tracing approach in practice and how eye tracking can support requirements engineering activities.

Abstract The success of software projects depends on developing a system that satisfies the stakeholders’ wishes and needs according to their mental models of the intended system. However, stakeholders may have misaligned mental models of the same system, resulting in conflicting requirements. For this reason, a shared understanding of the project vision is essential for the success of software projects. While it is already challenging to achieve shared understanding in synchronous contexts, such as meetings, it is even more challenging when only asynchronous contexts, like messaging services, are possible. When multiple stakeholders are involved from different locations and time zones, primarily asynchronous communication occurs. The use of asynchronous communication tools for the development of a shared understanding has hardly been analyzed. In this paper, we look to turn the potential detriment of having to discuss a project vision asynchronously into an opportunity for stakeholders to achieve a shared understanding. For this purpose, we give an overview of common challenges of asynchronous communication. We also propose five concepts designed to minimize the impact of these challenges. We examine categories of asynchronous communication tools and assess their adaptability to our concepts. In a workshop, we chose three most suited representatives to include in our main experiment. In this experiment, we evaluate the adapted representatives and a prototype of our own with 30 participants. Our results show the suitability of our concepts. Participants using our concepts were able to achieve a higher level of shared understanding.

Abstract Demonstrating software early and responding to feedback is crucial in agile development. However, it is difficult for stakeholders who are not on‐site customers but end users, marketing people, or designers, and so forth to give feedback in an agile development environment. Successful graphical user interface (GUI) test executions can be documented and then demonstrated for feedback. In our new concept, GUI tests from behavior‐driven development (BDD) are recorded, augmented, and demonstrated as videos. A GUI test is divided into several GUI unit tests, which are specified in Gherkin, a semi‐structured natural language. For each GUI unit test, a video is generated during test execution. Test steps specified in Gherkin are traced and highlighted in the video. Stakeholders review these generated videos and provide feedback, for example, on misunderstandings of requirements or on inconsistencies. To evaluate the impact of videos in identifying inconsistencies, we asked 22 participants to identify inconsistencies between (1) given requirements in regular sentences and (2) demonstrated behaviors from videos with Gherkin specifications or from Gherkin specifications alone. Our results show that participants tend to identify more inconsistencies from demonstrated behaviors, which are not in accordance with given requirements. They tend to recognize inconsistencies more easily through videos than through Gherkin specifications alone. The types of inconsistency are threefold: The mentioned feature can be incorrectly implemented, not implemented, or an unspecified new feature. We use a fictitious example showing how this feedback helps a product owner and her team manage requirements. We conclude that GUI test videos can help stakeholders give feedback more effectively. By obtaining early feedback, inconsistencies can be resolved, thus contributing to higher stakeholder satisfaction.

Explainability is an emerging quality aspect of software systems. Explanations offer a solution approach for achieving a variety of quality goals, such as transparency and user satisfaction. Therefore, explainability should be considered a means to an end. The evaluation of quality aspects is essential for successful software development. Evaluating explainability allows an assessment of the quality of explanations and enables the comparison of different explanation variants. As the evaluation depends on what quality goals the explanations are supposed to achieve, evaluating explainability is non-trivial. To address this problem, we combine the already well-established method of expert evaluation with goal-oriented heuristics. Goal-oriented heuristics are heuristics that are grouped with respect to the goals that the explanations are meant to achieve. By establishing appropriate goal-oriented heuristics, software engineers are enabled to evaluate explanations and identify problems with affordable resources. To show that this way of evaluating explainability is suitable, we conducted an interactive user study, using a high-fidelity software prototype. The results suggest that the alignment of heuristics with specific goals can enable an effective assessment of explainability.

In software projects, stakeholders can give valuable feedback on software demonstrations. Demonstrating software early and responding to feedback is crucial in agile development. However, it is difficult for stakeholders who are not on-site customers but end users, marketing people, or designers, etc. to give feedback in an agile development environment. Successful Graphical User Interface (GUI) tests, which show the working GUI with expected software behaviors, can be documented and then demonstrated for feedback. In our new concept, GUI tests are recorded, extended, and demonstrated as videos. A GUI test is divided into several GUI unit tests, which are specified in Gherkin, a semi-structured natural language. For each GUI unit test, a video is generated during test execution. Test steps specified in Gherkin are traced and highlighted in the video. Stakeholders review these generated videos and provide feedback, e.g., on misunderstandings of requirements or on inconsistencies. To evaluate the impact of videos in identifying inconsistencies, we asked 22 participants to identify inconsistencies between (1) given requirements in regular sentences and (2) demonstrated behaviors from videos with Gherkin specifications or from Gherkin specifications alone. Our results show that participants tend to identify more inconsistencies from demonstrated behaviors which are not in accordance with given requirements. They tend to recognize inconsistencies more easily through videos than through Gherkin specifications alone. We conclude that GUI test videos can help stakeholders give feedback more effectively. By obtaining early feedback, inconsistencies can be resolved, thus contributing to higher stakeholder satisfaction.

Welcome to the proceedings of the 31st edition of the IEEE International Requirements Conference (RE'23), the flagship conference of the international RE community. RE is where researchers, practitioners and students meet to share the latest advances, challenges and ideas related to software and systems requirements engineering.

In the context of the ongoing digitalization of society, human values such as privacy, ethics and trust are becoming increasingly important.Digital systems are entering private and professional spaces, which in turn affects the privacy of their end users.Hence, there is a need for conveying privacy information in a transparent and understandable manner, with the user in the focus.Lawmakers introduced privacy policies as a means of communicating privacy information.However, those documents have proven to be practically useless for end users.Privacy policies are long, vague, ambiguous and use complex language, such as legal terms, which often require profound background knowledge.Explainability has shown potential as a means to increase transparency and foster trust in software systems.Based upon the foundation of explainability, we developed a layered concept for usercentered privacy explanations, which is implemented within a high-fidelity software prototype.Finally, we tested and evaluated our concept by conducting an interactive user study with 61 participants.The results of our study suggest that our layered design concept enabled participants to understand the privacy aspects they regarded as important.We conclude that our approach seems to be an appropriate way to communicate complex privacy information to end users.

Abstract The creation of a shared understanding of the project vision of all relevant stakeholders is vital to the requirements engineering process. One way to create such a shared understanding is through the use of vision videos that visualize the project vision at an early project stage. However, not all functional aspects can be presented. For example, the fact that an access code is valid for only a single use can be hard to visualize. One low-effort solution could be the insertion of short texts or short audio clips. In this work, our question is twofold: What effects do short pieces of additional information have in vision videos? What are suitable ways to add this information to vision videos? To answer these research questions, we investigated three different methods of inserting additional information to vision videos in an eye tracking study. We inserted short texts either below the scene or as overlays and also investigated the addition of short audio clips. These methods were evaluated in terms of participants’ video comprehension, visual effort, cognitive load and subjective preference. The results of our study show that the pieces of additional information improve vision comprehension, thereby supporting the creation of a shared understanding. All investigated methods lead to only marginal increases of the viewers’ cognitive load. Based on our results, we derive recommendations on how to insert additional information in vision videos.

Explainability has been acknowledged as a fundamental requirement for modern information systems. However, there are currently only few guidelines available to assist software professionals in dealing with this requirement and integrating it into systems. More precisely, there is a lack of frameworks and guidelines that help to define and operationalize explainability requirements. To address this need, we present a quality framework that aggregates external dependencies, characteristics of explanations, and evaluation methods to facilitate the analysis, operationalization, and evaluation of explainability requirements. We conducted a literature study to construct the framework and demonstrated its applicability by using it as a guideline for incorporating explanations into an existing navigation system. Finally, we evaluated the quality and effect of the explanations through an experiment within our case study. Our results show that the quality framework is applicable and beneficial in an industrial context and leads to the construction of explanations that increase usage frequency, system acceptance and user satisfaction.

One main goal of requirements engineering is ensuring that all stakeholders share the same vision of the future system. Vision Videos can be used for this purpose. They visualize the product vision at an early stage of the project. However, some functional aspects, such as an access code being valid only once, are difficult to visualize. Short texts could be a low-effort solution to complement videos with additional information. Thus, represented visions and requirements could be taken to the next level of clarification. Our question is two-fold: What effects do texts have in vision videos? What are suitable ways to add textual information to vision videos? We conducted an eye tracking study to investigate the effects of adding short texts to vision videos, either below the scene or as text overlays. We evaluated these two methods regarding video comprehension, reading time, cognitive load and subjective preference. Our study shows that texts in vision videos improve vision comprehension and thus support the achievement of one requirements engineering goal. Both methods increase the cognitive load of viewers only by a reasonable margin. No clear-cut preference for a single variant was found. We derive recommendations on how to add texts to vision videos.

Abstract Code review is an important process in software engineering – yet, a very expensive one. Therefore, understanding code review and how to improve reviewers’ performance is paramount. In the study presented in this work, we test whether providing developers with explicit reviewing strategies improves their review effectiveness and efficiency. Moreover, we verify if review guidance lowers developers’ cognitive load. We employ an experimental design where professional developers have to perform three code review tasks. Participants are assigned to one of three treatments: ad hoc reviewing, checklist, and guided checklist. The guided checklist was developed to provide an explicit reviewing strategy to developers. While the checklist is a simple form of signaling (a method to reduce cognitive load), the guided checklist incorporates further methods to lower cognitive demands of the task such as segmenting and weeding. The majority of the participants are novice reviewers with low or no code review experience. Our results indicate that the guided checklist is a more effective aid for a simple review,while the checklist supports reviewers’ efficiency and effectiveness in a complex task. However, we did not identify a strong relationship between the guidance provided and code review performance. The checklist has the potential to lower developers’ cognitive load, but higher cognitive load led to better performance possibly due to the generally low effectiveness and efficiency of the study participants. Data and materials: 10.5281/zenodo.5653341 . Registered report: 10.17605/OSF.IO/5FPTJ .

Together with many success stories, promises such as the increase in production speed and the improvement in stakeholders’ collaboration have contributed to making agile a transformation in the software industry in which many companies want to take part. However, driven either by a natural and expected evolution or by contextual factors that challenge the adoption of agile methods as prescribed by their creator(s), software processes in practice mutate into hybrids over time. Are these still agile? In this article, we investigate the question: what makes a software development method agile? We present an empirical study grounded in a large-scale international survey that aims to identify software development methods and practices that improve or tame agility. Based on 556 data points, we analyze the perceived degree of agility in the implementation of standard project disciplines and its relation to used development methods and practices. Our findings suggest that only a small number of participants operate their projects in a purely traditional or agile manner (under 15 percent). That said, most project disciplines and most practices show a clear trend towards increasing degrees of agility. Compared to the methods used to develop software, the selection of practices has a stronger effect on the degree of agility of a given discipline. Finally, there are no methods or practices that explicitly guarantee or prevent agility. We conclude that agility cannot be defined solely at the process level. Additional factors need to be taken into account when trying to implement or improve agility in a software company. Finally, we discuss the field of software process-related research in the light of our findings and present a roadmap for future research.

Abstract The number of companies that use agile methods increases steadily. However, these companies often do not implement a pure agile approach but combine agile and plan‐based methods to so‐called hybrid development approaches. However, the development of these approaches is rather difficult for the companies, since agile and plan‐based approaches often follow opposite concepts. To benefit from agile and plan‐based approaches at the same time, the companies have to identify and address the conflicts between agile and plan‐based methods. The conflicts depend on the goals that are pursued with the implementation of agile and plan‐based methods. However, there is no overview of the exact goals that are pursued in hybrid approaches and which challenges and conflicts arise with them. Therefore, we conducted a systematic mapping study to gather and analyze the goals and challenges in hybrid development approaches. The mapping study is focused on literature that presents the actual needs and goals of companies and projects. Based on our results, we present the influence factors that cause conflicts in hybrid approaches and discuss how these conflicts can be addressed.

Abstract Product Owners have an important role in the agile and hybrid software development process. While this role is supposed to maximize the value of a product, there seem to be several scattered results on how they achieve this, as well as what actually constitutes this role in practice. To consolidate current research results and to further analyze the key attribute of Product Owners, we conducted a multi‐method research approach spanning a systematic mapping study and a consecutive case study in a hybrid development environment. The results of the mapping study states that Product Owners are communicators. We further investigated on this and used the shadowing technique to observe three Product Owners' communication activities. The results support that statement, as the gained data reveal that Product Owners spend 65% of their time in meetings. But rather than just providing the team with the necessary requirements for the product under development, Product Owners need this time to synchronize and align their work, streamline the agile process of large‐scale Scrum, discuss team‐based topics, and to solve upcoming issues addressed by the team. These results contribute to draw a more comprehensive picture of the important but yet complex role of Product Owners in practice.

Fast feedback promotes agile teams to improve their work during the software process, making it crucial for team success. Information systems accelerate the availability of information that result in compact knowledge sources. In practice, feedback in Sprints is often limited to sole progress and performance measures, e.g., burndown charts or velocity diagrams. Sprint insights related to team dynamics are rarely considered, even though they frequently cause project failures, e.g., lack of social interaction. In this paper, we describe a survey study conducted with international members of the software engineering community to reveal which information helps agile teams the most and provides practical support in Sprints. We describe results in an experience report highlighting the frequent information problems and needs of agile teams, considering the perspective of 90 researchers and practitioners. The responses were quantitatively interpreted. The report promotes understanding about how or what kind of information would be useful for agile development teams. Moreover, it reveals what information problems were perceived as crucial for project success and avoidable, considering proper team feedback. The study endorses practical needs for system-aided feedback that supplies knowledge on the human factors in Sprints. The findings are relevant for practitioners and researchers that struggle on improving team feedback based on information needs.

Agile software development methods promise shorter time-to-market and higher product quality, but lack the ability of long-term planning or coping with large projects. However, software companies often also want the ability of long-term planning, promised by traditional or plan-based methods. To benefit from the strengths of both approaches, software companies often use a combination of agile and plan-based methods, known as hybrid development approaches. These approaches strongly depend on the individual context and are customized. Therefore, companies have to organize their hybrid development approach individually. However, practitioners often have difficulties with the organization of hybrid approaches. The organization considers how the phases, activities, roles, and artifacts are arranged and connected. Research lacks the necessary detailed insight into how hybrid development approaches are organized to support practitioners. To gain better understanding of the organization of hybrid approaches, we conducted a systematic literature review to gather descriptions of hybrid approaches. We analyzed the found papers thoroughly and could identify three general patterns of how hybrid approaches are organized. We found that all these patterns are still based on Royce's waterfall model and use the standard software engineering activities. Our findings shall help to lead further research and help practitioners to better organize their individual development approach.

Context: Code review is a fundamental, yet expensive part of software engineering. Therefore, research on understanding code review and its efficiency and performance is paramount.

Abstract Software systems are becoming increasingly complex. Their ubiquitous presence makes users more dependent on their correctness in many aspects of daily life. As a result, there is a growing need to make software systems and their decisions more comprehensible, with more transparency in software-based decision making. Transparency is therefore becoming increasingly important as a non-functional requirement. However, the abstract quality aspect of transparency needs to be better understood and related to mechanisms that can foster it. The integration of explanations into software has often been discussed as a solution to mitigate system opacity. Yet, an important first step is to understand user requirements in terms of explainable software behavior: Are users really interested in software transparency and are explanations considered an appropriate way to achieve it? We conducted a survey with 107 end users to assess their opinion on the current level of transparency in software systems and what they consider to be the main advantages and disadvantages of embedded explanations. We assess the relationship between explanations and transparency and analyze its potential impact on software quality. As explainability has become an important issue, researchers and professionals have been discussing how to deal with it in practice. While there are differences of opinion on the need for built-in explanations, understanding this concept and its impact on software is a key step for requirements engineering. Based on our research results and on the study of existing literature, we offer recommendations for the elicitation and analysis of explainability and discuss strategies for the practice.

Product Owners (PO) in the Scrum framework have an important role in the development process. While the POs primal description is straightforward - the actual implementation of this role in industries is not. Many companies face the difficulty of assigning the right level of tasks and responsibilities to this role. To provide solutions to this problem, the Product Owner role became a subject of research. However, most of the studies focus on the actual state of the role to propose solutions on how to tailor it. What is missing is the Scrum Teams perspective. Therefore, we were interested in the Teams expectations on the Product Owner role. Which tasks do they expect to be performed by this role and how would they characterize a perfect Product Owner? In an attempt to answer this question, we conducted an online survey in the oil and gas industry and gathered feedback from all members of the Scrum Team. Our findings indicate that the Scrum Team expects the Product Owner to write user stories and prioritize the backlog solely. Other tasks are expected to be done either in direct collaboration with the management or the scrum master or are not expected to be done by the Product Owner role at all. Also, the respondents would characterize a perfect Product Owner primarily as trustworthy.

Agile software development teams strive for fast and continuous feedback. Both the quality of the resulting software and the performance of the team require feedback. The performance of the team developments is often addressed in retrospectives which are not only part of the SCRUM framework, but also in general. Reflecting on incidents during the last sprint helps the team to increase performances, expressed by, e.g., efficiency and productivity. However, it is not only essential to identify volatile sprint performances, but also to characterize the primary cause to solve them. Main reasons for low performance are often not visible, primarily when they are related to social-driven team behavior, such as communication structures, mood, or satisfaction. In this paper, we analyze whether automated team feedback about retrospective sprint-behavior can help the team to increase performances due to additional awareness about the dynamic effects over time. In a comparative case study with 15 software projects and a total of 130 undergraduate students, we investigated the sustainable impact of feedback on human aspects. Our results indicate that automated feedback positively affects team performances - and customer satisfaction.

Product Owners in the Scrum framework - respectively the On-site Customer when applying eXtreme Programming - have an important role in the development process. The Scrum Guide states that this role is responsible for the requirements and maximizing the value of the product. However, the implementation of this role depends on the individual, the organization and the team and is perceived as difficult in industry. Various research approaches provide insights in the applied PO role in industry - yet, a conclusive bigger picture of the studies and reports on this issue is missing. To fill this gap, we conducted a systematic mapping study. Our findings structure the research area of Product Owners in industry in terms of research topics and applied research methods. In total, we identified 30 contributions addressing seven research topics and generated consolidated answers for each of them. While some of those topics provide congruent results, others point to gaps in current research: So is the PO role in large-scale projects clearly defined as a group effort, but questions regarding the leadership and management responsibilities of POs remain unanswered. Also, the impact of external circumstances on the PO role is a question that is worth to answer in future work.

Software systems are getting more and more complex. Their ubiquitous presence makes users more dependent on them and their correctness in many aspects of daily life. Thus, there is a rising need to make software systems and their decisions more comprehensible. This seems to call for more transparency in software-supported decisions. Therefore, transparency is gaining importance as a non-functional requirement. However, the abstract quality aspect of transparency needs to be better understood and related to mechanisms that can foster it. Integrating explanations in software to leverage systems' opacity has been discussed often. Yet, an important first step is to understand user requirements with respect to explainable software behavior: Are users really interested in transparency, and are explanations considered an adequate mechanism to achieve it? We conducted a survey with 107 end-users to assess their opinion on the current status of transparency in software systems, and what they consider main advantages and disadvantages of explanations embedded in software. The overall attitude towards embedded explanations was positive. However, we also identified potential disadvantages. We assess the relation between explanations and transparency and analyze its possible impact on software quality.

In agile software development, the sprint performances and dynamics of teams often imply tendencies for the success of a project.Post mortem strategies, e.g., retrospectives help the team to report and share individually gained experiences (positives and negatives) from previous sprints, and enable them to use these experiences for future sprint planning.The interpretation of effects on sprint performance is often subjective, especially with concern to social-driven factors in teams.Involving strategies from predictive analytics in sprint retrospectives could reduce potential interpretation gaps of dynamics, and enhance the pre-knowledge, also awareness situation when preparing for the next sprint.In a case study involving 15 software projects with a total of 130 involved undergraduate students, we investigated the post-effects on team performances and behavioral-driven factors when providing predictive analytics in retrospectives.Besides measures for productivity, we consider human factors, e.g., team structures, communication, meetings and mood affects in teams as well as project success metrics.We developed a unique JIRA plugin called ProDynamics that collects performance information from projects and derives trend-insights for next sprints.The ProDynamics plugin enables the use of a times series and neural network model within a JIRA system to interpret factorial dependencies and behavioral pattern, thus to show the next sprint course of a team.

Faced with the severe financial and reputation implications associated with data breaches, enterprises now recognize security as a top concern for software analysis tools.While software engineers are typically not equipped with the required expertise to identify vulnerabilities in code, community knowledge in the form of publicly available vulnerability databases could come to their rescue.For example, the Common Vulnerabilities and Exposures Database (CVE) contains data about already reported weaknesses.However, the support with available examples in these databases is scarce.CVE entries usually do not contain example code for a vulnerability, its exploit or patch.They just link to reports or repositories that provide this information.Manually searching these sources for relevant information is time-consuming and error-prone.In this paper, we propose a vulnerability detection approach based on community knowledge and clone detection.The key idea is to harness available example source code of software weaknesses, from a large-scale vulnerability database, which are matched to code fragments using clone detection.We leverage a clone detection technique from the literature, which we adapted to make it applicable to vulnerability databases.In an evaluation based on 20 reports and affected projects, our approach showed good precision and recall.

Abstract Almost all companies struggle with software systems that are getting increasingly complex. Therefore, in particular large companies often use software product lines, which provide an efficient way to manage software reuse as well as the high complexity. However, software product lines seem to be too slow to react to changes. Agile development approaches promise to meet this demand. At the same time, integrating an agile approach is not always easy. Consequently, there is a need for a transformation model that supports the agile transformation without harming the benefits of software product lines. In this paper, we present the results of a literature review regarding agile transformation in large software companies. Our results summarize the insights from 85 papers and present a list of 20 tasks and tasks that are recommended by several researchers to be considered during the transformation. On the basis of these results, we create an agile transformation model—the so‐called “agile hamburger”—that contains these tasks and preserves software product lines. Since the model is rather coarse grained and generic, we also support the adaption to different teams by presenting an assessment model tailored to the demands of the automotive domain.

Multitasking has always been an inherent part of software development and is known as the primary source of interruptions due to task switching in software development teams. Developing software involves a mix of analytical and creative work, and requires a significant load on brain functions, such as working memory and decision making. Thus, task switching in the context of software development imposes a cognitive load that causes software developers to lose focus and concentration while working thereby taking a toll on productivity. To investigate the disruptiveness of task switching and interruptions in software development projects, and to understand the reasons for and perceptions of the disruptiveness of task switching we used a mixed-methods approach including a longitudinal data analysis on 4,910 recorded tasks of 17 professional software developers, and a survey of 132 software developers. We found that, compared to task-specific factors (e.g. priority, level, and temporal stage), contextual factors such as interruption type (e.g. self/external), time of day, and task type and context are a more potent determinant of task switching disruptiveness in software development tasks. Furthermore, while most survey respondents believe external interruptions are more disruptive than self-interruptions, the results of our retrospective analysis reveals otherwise. We found that self-interruptions (i.e. voluntary task switchings) are more disruptive than external interruptions and have a negative effect on the performance of the interrupted tasks. Finally, we use the results of both studies to provide a set of comparative vulnerability and interaction patterns which can be used as a mean to guide decision-making and forecasting the consequences of task switching in software development teams.

[Context:] The descriptions of interactions and system functions are two of the most important artifact types in requirements specifications. Their common notations are use cases and requirements which are related to each other. There are different variants to link a use case with its associated requirements due to a wide variety of use case templates. The main purpose of all linking variants is to highlight the interrelationships between use cases and requirements. Besides considering both artifacts for themselves, a reader needs to interrelate them to achieve a high understanding of the overall content. [Objective / Method:] Due to the effort to create and maintain links, we investigated the impact of different linking variants on the reading behavior in an eye tracking study with 15 subjects. [Results:] Our findings indicate that all investigated variants cause comparable visual effort and share the most frequent sequential reading pattern. In all cases, the use case was read first and then the requirements. Nevertheless, the different variants result in divergent reading behaviors. Especially, links embedded in the table of a use case description significantly increase the number of attention switches from the use case to the requirements. [Conclusion:] These attention switches represent the reading behavior of interrelating the use case and the associated requirements which only occurred in case of the most detailed linking variant.

Software process improvement has always been an essential part of software projects. Current market trends and the rapid pace of changing requirements demand fast development and adaptability. Agile software development is a popular possibility to react on these trends. Implementing agile practices promises for example a shorter time-to-market, satisfied customers and increased software quality. Consequently many companies strive for an integration of agile methods or for an agile transformation.

Information sharing in teams is one of the most important aspects of successful software development. For instance, requirements, design decisions and guidelines need to be communicated with the whole team or with specific team members. For information exchange, communication is mandatory. Meetings are an effective way to communicate with many team members. Hence, much information can be shared during team meetings. But meeting and communication behavior may vary. During the project, the team members get to know the others more and more. This has an influence on the chosen ways of information sharing and hence changes communication behavior.We are interested in analyzing the influence of meetings on team-internal communication and collaboration. To analyze collaboration, we consider a measure of indirections representing used communication channels and the perceived communication intensity between each of the team members. In a study with 65 students across eight development teams, we examine how intensively team members used various communication channels and if there is a change in communication and meeting behavior over time.In our study, the communication behavior becomes increasingly effective during the development process and the number of team meetings decreases in the course of the project. Moreover, the teams decentralize their communication behavior during project progress. According to our results, there is no cause for concern if there are less or shorter meetings at the end than at the beginning of a project.

Change-based code review, e.g., in the form of pull requests, is the dominant style of code review in practice. An important option to improve review's efficiency is cognitive support for the reviewer. Nevertheless, review tools present the change parts under review sorted in alphabetical order of file path, thus leaving the effort of understanding the construction, connections, and logic of the changes on the reviewer. This leads to the question: How should a code review tool order the parts of a code change to best support the reviewer? We answer this question with a middle-range theory, which we generated inductively in a mixed methods study, based on interviews, an online survey, and existing findings from related areas. Our results indicate that an optimal order is mainly an optimal grouping of the change parts by relatedness. We present our findings as a collection of principles and formalize them as a partial order relation among review orders.

The digital transformation of the automotive industry has a significant impact on how development processes need to be organized in future. Dynamic market and technological environments require capabilities to react on changes and to learn fast. Agile methods are a promising approach to address these needs but they are not tailored to the specific characteristics of the automotive domain like product line development. Although, there have been efforts to apply agile methods in the automotive domain for many years, significant and widespread adoptions have not yet taken place. The goal of this literature review is to gain an overview and a better understanding of agile methods for embedded software development in the automotive domain, especially with respect to product line development. A mapping study was conducted to analyze the relation between agile software development, embedded software development in the automotive domain and software product line development. Three research questions were defined and 68 papers were evaluated. The study shows that agile and product line development approaches tailored for the automotive domain are not yet fully explored in the literature. Especially, literature on the combination of agile and product line development is rare. Most of the examined combinations are customizations of generic approaches or approaches stemming from other domains. Although, only few approaches for combining agile and software product line development in the automotive domain were found, these findings were valuable for identifying research gaps and provide insights into how existing approaches can be combined, extended and tailored to suit the characteristics of the automotive domain.

Classifying requirements into functional requirements (FR) and non-functional ones (NFR) is an important task in requirements engineering. However, automated classification of requirements written in natural language is not straightforward, due to the variability of natural language and the absence of a controlled vocabulary. This paper investigates how automated classification of requirements into FR and NFR can be improved and how well several machine learning approaches work in this context. We contribute an approach for preprocessing requirements that standardizes and normalizes requirements before applying classification algorithms. Further, we report on how well several existing machine learning methods perform for automated classification of NFRs into sub-categories such as usability, availability, or performance. Our study is performed on 625 requirements provided by the OpenScience tera-PROMISE repository. We found that our preprocessing improved the performance of an existing classification method. We further found significant differences in the performance of approaches such as Latent Dirichlet Allocation, Biterm Topic Modeling, or Naïve Bayes for the sub-classification of NFRs.

Estimating dynamic components in projects involves understanding human factors which are substantial in software development.Communication and collaboration in teams consist of social-driven characteristics with influences on the continuous delivery of software.Efficiently estimated meetings become increasingly important due to budget calculations and shortened release cycles.Experiences of project managers combined with retrospectives on historical data records support a better understanding of team dynamics.But interpreting complex effects is not always trivial, in particular without further analyzes.In several studies, information relationships are investigated through linear correlation measures.Additional analyses for higher correlations are often neglected due to the advanced functional characterization.This leads to statistical gaps with significances for explored data relationships and their functional interpretation.In this paper, we present a systematic identification and visualization of team communication effects and diversities for field study records of 34 student software projects.We combine methodologies from system dynamics with exploratory data analysis to extract and emphasize significant effects.These insights help to sensitize for advanced investigations about the statistical measures of correlation and to interpret sophisticated structures.Furthermore, it reinforces potentials for a team's communication performances and enables an enhanced understanding about how student teams meet and communicate.

Abstract Code review in practice is often performed change‐based, ie, using the code changes belonging to a task to determine which code to review. Previous studies found that 2 variations of this process are used in industry: pre‐commit review and post‐commit review. The choice between these has implications not only for practitioners deciding on a code review process to use but also for the development of review tools and for experimentation with review processes. In some situations, a specific variant is clearly preferable due to the nature of the development process or team. In other situations, there are conflicting opinions. So we asked: Are there practically relevant performance differences between pre and post‐commit reviews? How are these differences influenced by contextual factors? To assess these questions, we designed a parametric discrete event simulation model of certain agile development processes. We validated this model with practitioner's feedback and in part also with empirical data from industry. Our analysis indicates that the best choice does depend on the context but also that there are many situations with no practically relevant difference between both choices. We identified the main influencing factors and underlying effects and condensed our findings into heuristic rules.

Code review in practice is often performed change-based, i.e. using the code changes belonging to a task to determine which code to review. In previous studies, it was found that two variations of this process are used in industry: Pre commit review (review-then-commit) and post commit review (commit-then-review). The choice for one of these variants has implications not only for practitioners deciding on a code review process to use, but also for the development of review tools and for experimentation with review processes. In some situations, a specific variant is clearly preferable due to the nature of the development process or team. In other situations, there are conflicting opinions, and both variants have proponents arguing for their method of choice. So we asked: Are there practically relevant performance differences between pre commit and post commit reviews, and how are these differences influenced by contextual factors? To assess this question, we designed a parametric discrete event simulation model of certain agile development processes. We validated this model with practitioner's feedback and in part also with empirical data from industry. Our analysis of the simulation results indicates that the best choice does depend on the context, but also that there are many situations with no practically relevant difference between both choices. We identified the main influencing factors and underlying effects and condensed our findings into heuristic rules.

Code review in the industry today is different to code review twenty years ago. The process has become more lightweight, reviews are performed frequently and change-based and the use of specialized tools is increasing. An accurate view of the current state of the industrial practice is an indispensable foundation for improving it. Most recent descriptions of review practices come from a limited population of large hightech companies. Therefore, we used interviews with software engineering professionals from a broad sample of 19 companies to gain insight into their code review practices. We augmented our findings with data for 11 companies found through a semisystematic literature review. There are many commonalities in the code review processes of these companies, but also a lot of variation in the details. A simple process taxonomy cannot describe these variations adequately. Therefore, we present a faceted classification scheme that is grounded in our observations.

Workshops are an established technique for requirements elicitation. A lot of information is revealed during a workshop, which is generally captured via textual minutes. The scribe suffers from a cognitive overload due to the difficulty of gathering all information, listening and writing at the same time. Video recording is used as additional option to capture more information, including non-verbal gestures. Since a workshop can take several hours, the recorded video will be long and may be disconnected from the scribe's notes. Therefore, the weak and unclear structure of the video complicates the access to the recorded information, for example in subsequent requirements engineering activities. We propose the combination of textual minutes and video with a software tool. Our objective is connecting textual notes with the corresponding part of the video. By highlighting relevant sections of a video and attaching notes that summarize those sections, a more useful structure can be achieved. This structure allows an easy and fast access to the relevant information and their corresponding video context. Thus, a scribe's overload can be mitigated and further use of a video can be simplified. Tool-supported analysis of such an enriched video can facilitate the access to all communicated information of a workshop. This allows an easier elicitation of high-quality requirements. We performed a preliminary evaluation of our approach in an experimental set-up with 12 participants. They were able to elicit higher-quality requirements with our software tool.

Code review is known to be an efficient quality assurance technique. Many software companies today use it, usually with a process similar to the patch review process in open source software development. However, there is still a large fraction of companies performing almost no code reviews at all. And the companies that do code reviews have a lot of variation in the details of their processes. For researchers trying to improve the use of code reviews in industry, it is important to know the reasons for these process variations. We have performed a grounded theory study to clarify process variations and their rationales. The study is based on interviews with software development professionals from 19 companies. These interviews provided insights into the reasons and influencing factors behind the adoption or non-adoption of code reviews as a whole as well as for different process variations. We have condensed these findings into seven hypotheses and a classification of the influencing factors. Our results show the importance of cultural and social issues for review adoption. They trace many process variations to differences in development context and in desired review effects.

Security is an important quality aspect for modern information systems. Security properties may however be violated if the information system operates in an evolving environment. Environmental changes then trigger reactions which lead to co-evolution of the security design and the corresponding system model. However, updating the security design manually is time-consuming and error-prone. We present an approach to support semi-automatic system co-evolution which responds to environmental knowledge evolution, using the UML security extension UMLsec and graph transformation. The aim is to enable software engineers to react more reliably and effectively to environmental changes and to ensure lifelong compliance of information systems. To evaluate our approach, we conducted a case study on the open-source project iTrust.

Good service design is key to acceptance and success for a service-oriented architecture (SOA) in an enterprise. Enterprises try to achieve good service design by using guidelines which combine experts' experience, company policies and best practices. Applying, evolving and maintaining guidelines overburdens service designers and reviewers due to the amount and volume. This results in inefficient, costly and frustrating processes. Without an automated support, guidelines provide only limited value to the design process. We describe how our design environment prototype addresses these problems and introduce automatic guideline checks using heuristics on service models. Our evaluation confirms applicability and advantages of our tool. We present a selection of heuristics which are used in our tool. As the second contribution we describe our plan of how to support evolution and maintenance of guidelines and heuristics.

Software-intensive systems are subject to continuous change due to modification of the systems themselves and their environment.Methods for supporting evolution are a competitive edge in software engineering as software is operated over decades.Empirical research is useful to validate the effectiveness of these methods.However, empirical studies on software evolution are rarely comprehensive and hardly replicable.Collaboration in empirical studies may prevent these shortcomings.We analyzed the support for such collaboration and examined existing studies in a literature review.Based on our findings, we designed CoCoMEP-a platform for supporting collaboration in empirical research on software evolution by shared knowledge.We report lessons learned from the application of the platform in a large research programme.

New graduates joining the software engineering workforce sometimes have trouble writing test code. Coming from university, they lack a hands-on approach to testing and have little experience with writing tests in a real-world setting. Software companies resort to costly training camps or mentoring initiatives. Not overcoming this lack of testing skills early on can hinder the newcomer’s professional progress in becoming a high-quality engineer. Studying open source developers, we found that they rely on a project’s pre-existing test code to learn how to write tests and adapt test code for their own use. We propose to strategically present useful and contextual test code examples from a project’s test suite to newcomers in order to facilitate learning and test writing. With an automatic suggestion mechanism for valuable test code, the newcomer is enabled to learn how senior developers write tests and copy it. Having access to suitable tests lowers the barrier for writing new tests.

Methods for supporting evolution of software-intensive systems are a competitive edge in software engineering as software is often operated over decades. Empirical research is useful to validate the effectiveness of these methods. However, empirical studies on software evolution are rarely comprehensive and hardly replicable. Collaboration may prevent these shortcomings. We designed CoCoMEP — a platform for supporting collaboration in empirical research on software evolution by shared knowledge. We report lessons learned from the application of the platform in a large research programme.

This article investigates relationships between media, mood, and communication in teams, and studies how they are related to project success. Team projects are an essential part of the software engineering curriculum. Student teams carry out full software projects, including requirements elicitation, project management, implementation, and testing. This requires various technical skills, but non-technical and psychological aspects are of utmost importance as well, just as in professional software teams. Modern software is often developed by distributed teams. In many cases, team members feel isolated and distant from each other. Indirect communication and inappropriate media create a similar feeling of distance as geographical location. This perceived distance could have an impact on their individual and group moods, and eventually on project success. Therefore, these factors should be considered in educational software engineering team projects. In a longitudinal study at Leibniz Universität Hannover, 20 student teams were observed over a period of 4 months. They were free to schedule team meetings when and where they wanted; and they could use any communication media they chose. Statistical correlations and non-parametric test are used for quantitative empirical analysis. Furthermore, we used analyses of variance for repeated measures to investigate conflicts over time. Results led to a number of recommendations for course organizers. They are interesting for software engineering in general.

Security is an increasingly important quality facet in modern information systems and needs to be retained. Due to a constantly changing environment, long-living software systems “age” not by wearing out, but by failing to keep up-to-date with their environment. The problem is that requirements engineers usually do not have a complete overview of the security-related knowledge necessary to retain security of long-living software systems. This includes security standards, principles and guidelines as well as reported security incidents. In this paper, we focus on the identification of known vulnerabilities (and their variations) in natural-language requirements by leveraging security knowledge. For this purpose, we present an integrative security knowledge model and a heuristic method to detect vulnerabilities in requirements based on reported security incidents. To support knowledge evolution, we further propose a method based on natural language analysis to refine and to adapt security knowledge. Our evaluation indicates that the proposed assessment approach detects vulnerable requirements more reliable than other methods (Bayes, SVM, k-NN). Thus, requirements engineers can react faster and more effectively to a changing environment that has an impact on the desired security level of the information system.

There are many different approaches to testing software, with different benefits for software quality and the development process. Yet, it is not well understood what developers struggle with when getting started with testing - and why some do not test at all or not as much as would be good for their project. This missing understanding keeps us from improving processes and tools to help novices adopt proper testing practices. We conducted a qualitative study with 97 computer science students. Through interviews, we explored their experiences and attitudes regarding testing in a collaborative software project. We found enabling and inhibiting factors for testing activities, the different testing strategies they used, and novices’ perceptions and attitudes of testing. Students push test automation to the end of the project, thus robbing themselves from the advantages of having a test suite during implementation. Students were not convinced of the return of investment in automated tests and opted for laborious manual tests - which they often regretted in the end. Understanding such challenges and opportunities novices face when confronted with adopting testing can help us improve testing processes, company policies, and tools. Our findings provide recommendations that can enable organizations to facilitate the adoption of testing practices by their members.

Abstract Communication is a key success factor of distributed software projects. Poor communication has been identified as a main obstacle to successful collaboration. Global projects are especially endangered by information gaps between collaborating sites. Different communication styles, technical equipment, and missing awareness of each other can cause severe problems. Knowledge about actual and desired channels, paths, and modes of communication is required for improving communication in a globally distributed project. However, many project participants know little about communication and information flow in their projects. In this contribution, we focus on knowledge about communication and information flow. It is acquired by modelling on‐going and desired flows of information, including documented and non‐documented channels of information flow. We analyzed a distributed software project from the information flow perspective. Based on the findings, we developed specific techniques to improve information flow in distributed software development according to the FLOW Method. In a second distributed project, we evaluated one of the techniques. We found the FLOW mapping technique to be suitable for effectively spreading knowledge about communication and information flow in global software projects.

The multitude of social media channels that programmers can use to participate in software development has given rise to online developer profiles that aggregate activity across many services. Studying members of such developer profile aggregators, we found an ecosystem that revolves around the social programmer. Developers are assessing each other to evaluate whether other developers are interesting, worth following, or worth collaborating with. They are self-conscious about being assessed, and thus manage their public images. They value passion for software development, new technologies, and learning. Some recruiters participate in the ecosystem and use it to find candidates for hiring; other recruiters struggle with the interpretation of signals and issues of trust. This mutual assessment is changing how software engineers collaborate and how they advance their skills.

Students of software engineering need a mental model to guide their activities; this mental model should contain a concept of success. They should be able to contribute to that success criterion through their daily work. Although economic gain is a wide-spread measure of success, it cannot be fully controlled by developers or even project leaders. Inappropriate deadlines, political influences, and many other aspects are beyond the control of software engineers. A success criterion closer to the sphere of influence of software engineers could better guide decisions of students - and practicing software engineers as well. We introduce the concept of requirements compliance1, which measures the size of the intersection between stated and implemented requirements. Fulfilled requirements are considered a success. Both unfulfilled requirements and unsolicited features are considered indications of reduced success: The latter consume resources without meeting stated needs, while missing requirements ignore customer requests. In this paper, we motivate and introduce the core concept of requirements compliance. We show how it can be and has been used for different variants of software engineering education, including serious educational games. We go beyond this prior use by identifying ways of modeling, observing and controlling requirements compliance in a series of student projects. We discuss opportunities for using this concept in software engineering education - but also build on the mental model in research and in practice.

Many software development projects struggle with creating and communicating a testing culture that is appropriate for the project's needs. This may degrade software quality by leaving defects undiscovered. Previous research suggests that social coding sites such as GitHub provide a collaborative environment with a high degree of social transparency. This makes developers' actions and interactions more visible and traceable. We conducted interviews with 33 active users of GitHub to investigate how the increased transparency found on GitHub influences developers' testing behaviors. Subsequently, we validated our findings with an online questionnaire that was answered by 569 members of GitHub. We found several strategies that software developers and managers can use to positively influence the testing behavior in their projects. However, project owners on GitHub may not be aware of them. We report on the challenges and risks caused by this and suggest guidelines for promoting a sustainable testing culture in software development projects.

GitHub projects attract contributions from a community of users with varying coding and quality assurance skills. Developers on GitHub feel a need for automated tests and rely on test suites for regression testing and continuous integration. However, project owners report to often struggle with implementing an exhaustive test suite. Convincing contributors to provide automated test cases remains a challenge. The absence of an adequate test suite or using tests of low quality can degrade the quality of the software product. We present an approach for reducing the effort required by project owners for extending their test suites. We aim to utilize the phenomenon of drive-by commits: capable users quickly and easily solve problems in others' projects - even though they are not particularly involved in that project - and move on. By analyzing and directing the drive-by commit phenomenon, we hope to use crowdsourcing to improve projects' quality assurance efforts. Valuable test cases and maintenance tasks would be completed by capable users, giving core developers more resources to work on the more complicated issues.

During acceptance testing customers assess whether a system meets their expectations and often identify issues that should be improved. These findings have to be communicated to the developers -- a task we observed to be error prone, especially in distributed teams. Here, it is normally not possible to have developer representatives from every site attend the test. Developers who were not present might misunderstand insufficiently documented findings. This hinders fixing the issues and endangers customer satisfaction. Integrated feedback systems promise to mitigate this problem. They allow to easily capture findings and their context. Correctly applied, this technique could improve feedback, while reducing customer effort. This paper collects our experiences from comparing acceptance testing with and without feedback systems in a distributed project. Our results indicate that this technique can improve acceptance testing -- if certain requirements are met. We identify key requirements feedback systems should meet to support acceptance testing.

Software engineering research and practice provide a wealth of methods that improve the quality of software and lower the costs of producing it. Even though processes mandate their use, methods are not employed consequently. Software developers and development organizations thus cannot fully benefit from these methods. We propose a method that, for a given software engineering method, provides instructions on how to improve its adoption using social software. This employs the intrinsic motivation of software developers rather than prescribing behavior. As a result, we believe that software engineering methods will be applied better and more frequently.

Today's large-scale softwareintensive systems exhibit an increasing complexity due to a broad spectrum of technical and socio-technical components. Due to the very dynamic character of such systems as well as fast evolving technologies, most requirements cannot be planned a priori. To overcome this problem, we suggest a method to gather enduser needs for requirements engineers at any time by applying a geographical deployed feedback system. End-user needs are gathered in-situ by utilizing mobile devices. In this paper, we present the implementation of our feedback system enabling end-users to submit feedback with smartphones at very low effort and cost.

In practice, more and more software development projects are distributed, ranging from partly distributed teams to global projects with each stakeholder located differently. Teaching actual practice in software engineering at university needs a proper mixture of theory and practice. But setting up practical exercises for global software engineering is hard, because students have to cooperate across different locations and situations reflecting the teaching intentions have to be provoked explicitly. This paper presents the concepts behind our common teaching environment for global software engineering - the GloSELab. It describes the experiences on setting up a distributed course and reports our teaching intentions based on each universities main focus: project management, requirements engineering & quality assurance, architecture, and implementation. Furthermore, we discuss our setup - a stage-gate process, where each location takes care of a different phase - and report occurred problems and how they supported or interfered with our teaching intentions.

Distributed software development is more difficult than co-located software development. One of the main reasons is that communication is more difficult in distributed settings. Defined processes and artifacts help, but cannot cover all information needs. Not communicating important project information, decisions and rationales can result in duplicate or extra work, delays or even project failure. Planning and managing a distributed project from an information flow perspective helps to facilitate available communication channels right from the start - beyond the documents and artifacts which are defined for a given development process. In this paper we propose FLOW Mapping, a systematic approach for planning and managing information flows in distributed projects. We demonstrate the feasibility of our approach with a case study in a distributed agile class room project. FLOW Mapping is sufficient to plan communication and to measure conformance to the communication strategy. We also discuss cost and impact of our approach.

Modern software systems are rarely built from scratch. They rather evolve over a long period of time while components and subsystems are developed independently. During that evolution, new and changing requirements emerge when end-users interact with the system. Users encounter situations that provoke spontaneous complaints or suggestions, which may be the seed of new requirements. However, there are two challenges: How to capture spontaneous reactions and how to focus and let them mature into valid requirements? We propose concepts that enable citizens to report a problem or make a suggestion by Smartphone. A key for preserving the spontaneous impetus is to lower the threshold for composing and sending feedback. Software providers who are interested in feedback can define filtering and focusing aids; they guide end-users in giving focused feedback. Focused feedback is also better prepared to be transformed to requirements. Our ConTexter tool demonstrates technical feasibility of these concepts. We explore and characterize a potential application domain empirically. Based on the findings, we discuss potentials and limitations of our approach.

Adapting new software processes and practices in organizational and academic environments requires training the developers and validating the applicability of the newly introduced activities. Investigating process conformance during training and understanding if programmers are able and willing to follow the specific steps are crucial to evaluating whether the process improves various software product quality factors. In this paper we present a process model independent approach to detect process non-conformance. Our approach is based on non-intrusively collected data captured by a version control system and provides the project manager with timely updates. Further, we provide evidence of the applicability of our approach by investigating process conformance in a five day training class on eXtreme Programming (XP) practices at the Leibniz Universität Hannover. Our results show that the approach enabled researchers to formulate minimal intrusive methods to check for conformance and that for the majority of the investigated XP practices violations could be detected.

Global software engineering has become a fact in many companies due to real necessity in practice. In contrast to co-located projects global projects face a number of additional software engineering challenges. Among them quality management has become much more difficult and schedule and budget overruns can be observed more often. Compared to co-located projects global software engineering is even more challenging due to the need for integration of different cultures, different languages, and different time zones-across companies, and across countries. The diversity of development locations on several levels seriously endangers an effective and goal-oriented progress of projects. In this position paper we discuss reasons for global development, sketch settings for distribution and views of orchestration of dislocated companies in a global project that can be seen as a ldquovirtual project environmentrdquo. We also present a collection of questions, which we consider relevant for global software engineering. The questions motivate further discussion to derive a research agenda in global software engineering.

Writing good requirements is difficult. Authors of requirements specifications need to acquire specific habits and professional writing styles to avoid ambigu-ities. However, gaining and sharing related experience and abilities is challenging. Heuristic Critiques offer help in this situation. Experience on writing good re-quirements can be codified as heuristic critiques. When integrated in a requirements tool, a heuristic critique can automatically check requirements specifications and provide constructive feedback (critique), whenever a piece of experience is applicable. Observing this feedback helps requirements authors to transfer expe-rience in writing, and internalize it. In this paper we describe the concept of learning to write better re-quirements through heuristic critiques - both, on an individual level and on an organizational level. The proposed concept has been applied in several dedicat-ed requirements support tools; it can also be used to improve existing tools and methods.

A software engineering department in a Daimler-Chrysler business unit was highly professional at developing embedded software for busses and coaches. However, customer specific add-ons were a regular source of hassle. Simple as they are, those individual requirements have to be implemented in hours or days rather than weeks or months. Poor quality or late upload into the bus hardware would cause serious cost and overhead. Established software engineering methods were considered inadequate and needed to be cut short. Agile methods offer guidance when quality, flexibility and high speed need to be reconciled. However, we did not adopt any full agile method, but added single agile practices to our process improvement toolbox. We suggested a number of classical process improvement activities (such as more systematic documentation and measurement) and combined them with agile elements (e.g. Test First Process). This combination seemed to foster acceptance of agile ideas and may help us to break the ice for a cautious extension of agile process improvement.

Software development and acquisition require knowledge and experience in many areas of software engineering. Experience helps people to make decisions under uncertainty, and to find better compromises. Experience-based process improvement considers experience as a prerequisite for competent behavior in software development. There is usually a repository to store experiences and to make it available for reuse. At DaimlerChrysler, we have been building those repositories for more than five years. We learned to concentrate on certain properties that seem to be key success factors for experience repositories. During our experience-based work in business units, five key quality aspects have been identified that determine the chances for success of an experience repository. The quality criteria can be used to analyze a given repository; or they can be applied to guide the construction of more effective experience repositories.

The experience factory concept enables systematic learning and continuous improvement in software development. As with most learning initiatives, it is hard to establish. In our experience, there is a great deal of uncertainty and skepticism about the mission and contents of an experience factory. The starting phase is especially endangered through pitfalls or unexpected delays. As expectations vary and there is pressure to demonstrate success within only a few months, tension arises which may jeopardize the entire enterprise. In the course of a large-scale software improvement program, we have established three experience factories in different environments of the Daimler-Benz AG within two years. At each site, several application projects are involved. We describe how we approached the task, what actions we took, and the lessons we learned.

This paper introduces an approach to modeling software project dynamics using an attributed graph grammar formalism. A project situation is modeled and presented to a "player" who is supposed to act as project manager of a simulated project. Events and internal processes of the simulated project are modeled using a custom-designed formalism that integrates attributed graph grammar concepts with a quantitative simulation mechanism resembling System Dynamics. Both ingredients were pragmatically selected and blended based on (1) their comparative simplicity, (2) their expressive power, and (3) their intuitive appeal for bridging the cognitive gap between real-world software engineering experiences and an executable simulation model. This modeling formalism was applied in the SESAM educational software engineering game. The modeling formalism was supported by a family of graphical SESAM editors. Resulting models could be animated and served as simulated projects in the game runs. SESAM was applied in graduate courses on software project management at the University of Stuttgart. Experiences with the modeling approach are reported. The design history and design rationale that led to using graph grammars as the underlying formalism are described and discussed. The design of the SESAM modeling formalism is presented as an (involuntary) case study in adopting a graph grammar approach.

Teaching software engineering as well as researching in this area is very tedious due to the length and costliness of software projects. SESAM ('Software Engineering Simulation by Animated Models') therefore is designed as a simulator for software projects, allowing students to gain reality-like experiences in project management and researchers to evaluate hypotheses on the mechanisms influencing software projects. This paper focuses on the basic assumptions for SESAM, its building blocks and the way hypotheses are affecting the simulation. After a short description of the requirements for SESAM, the authors introduce objects, attributes, actions, relationships between objects, and hypotheses as its basic concepts. They present attributed graph grammars as a means for representing hypotheses. Finally they position their project with respect to related work, and they show its present a state and future development.>