Software is now deeply embedded in every aspect of society, shaping how we live, work, and connect. As a result, understanding users and their interactions with technology has never been more critical. While user-centered approaches, and particularly participatory approaches, have long been a cornerstone of requirements engineering, today’s increasingly digital world—driven by online interactions, automation, and AI—raises new challenges. How effectively can we engage with users and stakeholders to understand the complexity of their lived experiences, and how the software we design might impact them? Are we truly equipped to grasp their values, preferences, and needs—–especially when these are deeply rooted in diverse backgrounds, cultures, and life experiences?

User feedback has grown in importance for organizations to improve software products. Prior studies focused primarily on feedback collection and reported a high-level overview of the processes, often overlooking how practitioners reason about, and act upon this feedback through a structured set of activities. In this work, we conducted an exploratory interview study with 40 practitioners from 32 organizations of various sizes and in several domains such as e-commerce, analytics, and gaming. Our findings indicate that organizations leverage many different user feedback sources. Social media emerged as a key category of feedback that is increasingly critical for many organizations. We found that organizations actively engage in a number of non-trivial activities to curate and act on user feedback, depending on its source. We synthesize these activities into a life cycle of managing user feedback. We also report on the best practices for managing user feedback that we distilled from responses of practitioners who felt that their organization effectively understood and addressed their users' feedback. We present actionable empirical results that organizations can leverage to increase their understanding of user perception and behavior for better products thus reducing user attrition.

With the onset of the COVID-19 pandemic and the ensuing shift away from co-located work arrangements towards working from home, practitioners encountered many collabora-tive and coordination challenges. While companies are slowly moving back towards in-person arrangements, many employers have permanently adopted fully remote and hybrid work modes. However, the work modes are more blurred, as hybrid work makes coordinating the requirements engineering practices that rely on rich interactions more challenging. Therefore, gaining more understanding of RE challenges and practices from prac-titioners transitioning to the new modes of work is imperative to identify insights that can be useful for organizations shifting to hybrid and remote work. In this paper, we use a mixed-methods approach to gain insights into remote and hybrid requirements engineering practices and challenges in the industry. Through interviews with 12 industry practitioners and a survey with 49 practitioners, we report on 7 adopted practices and 7 challenges encountered in these work arrangements. We found challenges such as organizing co-located tasks, lack of interpersonal con-nections, keeping everyone in the loop, and engagement barriers, which fall under coordination, communication and collaboration. To offset such challenges, we provide 20 recommendations based on our findings, such as proactive planning and using newer tools that support comprehensive tracking of important knowl-edge for requirements documentation. Our findings suggest that practitioners are facing challenges in remote and hybrid work arrangements, which they are mitigating with various strategies. Nonetheless, there remains a need for further research, as not all challenges are equally addressed across different work contexts.

Abstract In many application domains of recommender systems, e.g., on media streaming sites, one main goal of the provider of the recommendation service is to increase the engagement of users by helping themdiscovernew types of content they like. Standard collaborative filtering algorithms by design often lead to a certain level of discovery. Nonetheless, in certain domains, it may be helpful to more actively promote content to users beyond their past preference profile (“off-profile”) and thereby help users explore new content. However, when showing such off-profile content to users in combination with more familiar content, the new content items may be overlooked. In this research, we explore to what extentdigital nudging, i.e., subtly directing user choices in a specific direction, can help to raise the attention and interest of users for off-profile content. We conducted a user study ( $$N=1064$$ N=1064 ) on a real-world social book recommendation app. We find that users who are nudged towards recommended books of their non-preferred genres significantly more often put these off-profile books on their reading lists, thus confirming the effectiveness of digital nudging in this application. However, we also found that digital nudges may negatively impact the users’ beliefs and attitudes towards the system and a more limited intention to use the system in the future. As a result, we find that digital nudging in recommendations, while effective in the short run, must be done with due care, keeping an eye on the overall quality perceptions by users and potentially harmful long-term effects.

The increasing importance of videos as a medium for engagement, communication, and content creation makes them critical for organizations to consider for user feedback. However, sifting through vast amounts of video content on social media platforms to extract requirements-relevant feedback is challenging. This study delves into the use of TikTok and YouTube, two widely used social media platforms that focus on video content, in identifying relevant user feedback that may be further refined into requirements using subsequent requirement generation steps. We demonstrate an approach of using videos as a source of user feedback by analyzing audio and visual text, and metadata (i.e., description/title) from 6276 videos of 20 popular products across various industries. We employed state-of-the-art deep learning transformer-based models, and classified 3097 videos consisting of requirements relevant information. We then clustered relevant videos and found multiple requirements relevant feedback themes for each of the 20 products. This feedback can later be refined into requirements artifacts. We found that product ratings (feature, design, performance), bug reports, and usage tutorial are persistent themes from the videos. Video-based social media such as TikTok and YouTube can provide valuable user insights, making them a powerful and novel resource for companies to improve customer-centric development.

Privacy requirements are increasingly growing in importance as new privacy regulations are enacted. To adequately manage privacy requirements, organizations not only need to comply with privacy regulations, but also consider user privacy concerns. In this exploratory study, we used Reddit as a source to understand users’ privacy concerns regarding software applications. We collected 4.5 million posts from Reddit and classified 129075 privacy related posts, which is a non-negligible number of privacy discussions. Next, we clustered these posts and identified 9 main areas of privacy concerns. We use the concept of narratives from economics (i.e., posts that can go viral) to explain the phenomenon of what and when users change in their discussion of privacy. We further found that privacy discussions change over time and privacy regulatory events have a short term impact on such discussions. However, narratives have a notable impact on what and when users discussed about privacy. Considering narratives could guide software organizations in eliciting the relevant privacy concerns before developing them as privacy requirements.

Building a shared understanding of non-functional requirements (NFRs) is a known but understudied challenge in requirements engineering, especially in organizations that adopt continuous software engineering (CSE) practices. During the peak of the COVID-19 pandemic, many CSE organizations complied with working remotely due to the imposed health restrictions; some continued to work remotely while implementing business processes to facilitate team communication and productivity. In remote CSE organizations, managing NFRs becomes more challenging due to the limitations to team communication. While previous research has identified the factors that lead to a lack of shared understanding of NFRs in CSE, we still have a significant gap in understanding how CSE organizations, particularly in remote work, build a shared understanding of NFRs. We conduct a three-month ethnography-informed case study of a remote CSE organization. Through thematic analysis of our qualitative data from interviews and observations, we identify a number of practices for building a shared understanding of NFRs, such as validating NFRs through feedback. The collaborative workspace the organization uses for remote interaction is Gather, which simulates physical workspaces, and which our findings suggest allows for informal communications instrumental for building shared understanding. In addition, we describe the limitations to building a shared understanding of NFRs in the organization, such as gaps in communication and the limited understanding of customer context. As actionable insights, we discuss our findings in light of proactive practices that represent opportunities for software organizations to invest in building a shared understanding of NFRs in their development.

Non-functional requirements (NFR), which include performance, availability, and maintainability, are vitally important to overall software quality. However, research has shown NFRs are, in practice, poorly defined and difficult to verify. Continuous software engineering practices, which extend agile practices, emphasize fast paced, automated, and rapid release of software that poses additional challenges to handling NFRs. In this multi-case study we empirically investigated how three organizations, for which NFRs are paramount to their business survival, manage NFRs in their continuous practices. We describe four practices these companies use to manage NFRs, such as offloading NFRs to cloud providers or the use of metrics and continuous monitoring, both of which enable almost real-time feedback on managing the NFRs. However, managing NFRs comes at a cost—as we also identified a number of challenges these organizations face while managing NFRs in their continuous software engineering practices. For example, the organizations in our study were able to realize an NFR by strategically and heavily investing in configuration management and infrastructure as code, in order to offload the responsibility of NFRs; however, this offloading implied potential loss of control. Our discussion and key research implications show the opportunities, trade-offs, and importance of the unique give-and-take relationship between continuous software engineering and NFRs. Research artifacts may be found athttps://doi.org/10.5281/zenodo.3376342.

Building shared understanding of requirements is key to ensuring downstream software activities are efficient and effective. However, in continuous software engineering (CSE) some lack of shared understanding is an expected, and essential, part of a rapid feedback learning cycle. At the same time, there is a key trade-off with avoidable costs, such as rework, that come from accidental gaps in shared understanding. This tradeoff is even more challenging for non-functional requirements (NFRs), which have significant implications for product success. Comprehending and managing NFRs is especially difficult in small, agile organizations. How such organizations manage shared understanding of NFRs in CSE is understudied. We conducted a case study of three small organizations scaling up CSE to further understand and identify factors that contribute to lack of shared understanding of NFRs, and its relationship to rework. Our in-depth analysis identified 41 NFR-related software tasks as rework due to a lack of shared understanding of NFRs. Of these 41 tasks 78% were due to avoidable (accidental) lack of shared understanding of NFRs. Using a mixed-methods approach we identify factors that contribute to lack of shared understanding of NFRs, such as the lack of domain knowledge, rapid pace of change, and cross-organizational communication problems. We also identify recommended strategies to mitigate lack of shared understanding through more effective management of requirements knowledge in such organizations. We conclude by discussing the complex relationship between shared understanding of requirements, rework and, CSE.

For a firm in an open source software (OSS) ecosystem, the requirements engineering (RE) process is rather multifaceted. Apart from its typical RE process, there is a competing process, external to the firm and inherent to the firm’s ecosystem. When trying to impose an agenda in competition with other firms, and aiming to align internal product planning with the ecosystem’s RE process, firms need to consider who and how influential the other stakeholders are, and what their agendas are. The aim of the presented research is to help firms identify and analyze stakeholders in OSS ecosystems, in terms of their influence and interactions, to create awareness of their agendas, their collaborators, and how they invest their resources. To arrive at a solution artifact, we applied a design science research approach where we base artifact design on the literature and earlier work. A stakeholder influence analysis (SIA) method is proposed and demonstrated in terms of applicability and utility through a case study on the Apache Hadoop OSS ecosystem. SIA uses social network constructs to measure the stakeholders’ influence and interactions and considers the special characteristics of OSS RE to help firms structure their stakeholder analysis processes in relation to an OSS ecosystem. SIA adds a strategic aspect to the stakeholder analysis process by addressing the concepts of influence and interactions, which are important to consider while acting in collaborative and meritocratic RE cultures of OSS ecosystems.

Presents the introductory welcome message from the conference proceedings. May include the conference officers' congratulations to all involved with the conference event and publication of the proceedings record.

We use Grounded Theory to study the evolution of requirements practices of 16 software startups as they grow and introduce new products and services. These startups operate in a dynamic environment, with significant time and market pressure, and rarely have time for systematic requirements analysis. Our theory describes the evolution of practice along six dimensions that emerged as relevant to their requirements activities: requirements artefacts, knowledge management, requirements-related roles, planning, technical debt and product quality. Beyond the relationships among the dimensions, our theory also explains the turning points that drove the evolution along these dimensions. These changes are reactive, rather than planned, suggesting an overall pragmatic lightness, i.e., flexibility, in the startups' evolution towards engineering practices for requirements. Our theory organises knowledge about evolving requirements practice in maturing startups, and provides practical insights for startups' assessing their own evolution as they face challenges to their growth. Our research also suggests that a startup's evolution along the six dimensions is not fundamental to its success, but has significant effects on their product, their employees and the company.

When a developer is writing code they are usually focused and in a state-of-mind which some refer to as flow. Breaking out of this flow can cause the developer to lose their train of thought and have to start their thought process from the beginning. This loss of thought can be caused by interruptions and sometimes slow IDE interactions. Predictive functionality has been harnessed in user applications to speed up load times, such as in Google Chrome's browser which has a feature called "Predicting Network Actions". This will pre-load web-pages that the user is most likely to click through. This mitigates the interruption that load times can introduce. In this paper we seek to make the first step towards predicting user commands in the IDE. Using the MSR 2018 Challenge Data of over 3000 developer session and over 10 million recorded events, we analyze and cleanse the data to be parsed into event series, which can then be used to train a variety of machine learning models, including a neural network, to predict user induced commands. Our highest performing model is able to obtain a 5 cross-fold validation prediction accuracy of 64%.

Software engineering practice has shifted from the development of products in closed environments toward more open and collaborative efforts. Software development has become significantly interdependent with other systems (e.g. services, apps) and typically takes place within large ecosystems of networked communities of stakeholder organizations. Such software ecosystems promise increased innovation power and support for consumer-oriented software services at scale and are characterized by a certain openness of their information flows. While such openness supports project and reputation management, it also brings requirements engineering-related challenges within the ecosystem, such as managing dynamic, emergent contributions from the ecosystem stakeholders, as well as collecting their input while protecting their IP. In this paper, we report from a study of requirements communication and management practices within IBM ® ’s Collaborative Lifecycle Management ® product development ecosystem. Our research used multiple methods for data collection, including interviews within several ecosystem actors, on-site participatory observation, and analysis of online project repositories. We chart and describe the flow of product requirements information through the ecosystem, how the open communication paradigm in software ecosystems provides opportunities for “just-in-time” RE—and which relies on emergent contributions from the ecosystem stakeholders—, as well as some of the challenges faced when traditional requirements engineering approaches are applied within such an ecosystem. More importantly, we discuss two tradeoffs brought about by the openness in software ecosystems: (1) allowing open, transparent communication while keeping intellectual property confidential within the ecosystem and (2) having the ability to act globally on a long-term strategy while empowering product teams to act locally to answer end users’ context-specific needs in a timely manner. A sufficient level of openness facilitates contributions of emergent stakeholders. The ability to include important emergent contributors early in requirements elicitation appears to be a crucial asset in software ecosystems.

There has been a significant interest in the estimation of time and effort in fixing defects among both software practitioners and researchers over the past two decades. However, most of the focus has been on prediction of time and effort in resolving bugs, without much regard to predicting time needed to complete high-level requirements, a critical step in release planning. In this paper, we describe a mixed-method empirical study on three large IBM projects in which we developed and evaluated a process of training a predictive model constituting a set of 29 features in nine categories in order to predict if a requirement will be completed within its planned iteration. We conducted feature engineering through iterative interviews with IBM practitioners as well as analysis of large development repositories of these three projects. Using machine learning techniques, we were able to make predictions on completion time of requirements at four different stages of their lifetime. Using our industrial partner's interest in high precision over recall, we then adopted a cost sensitive learning method and maximized precision of predictions (ranging from 0.8 to 0.97) while maintaining an acceptable recall. We also ranked the features based on their relative importance to the optimized predictive model. We show that although satisfying predictions can be made at early stages, performance of predictions improves over time by taking advantage of requirements' progress data. Furthermore, feature importance ranking results show that although importance of features are highly dependent on project and prediction stage, there are certain features (e.g. requirement creator, time remained to the end of iteration, time since last requirement summary change and number of times requirement has been replanned for a new iteration) that emerge as important across most projects and stages, implying future worthwhile research directions for both researchers and practitioners.

Understanding and keeping the customer happy is a central tenet of requirements engineering. Strategies to gather, analyze, and negotiate requirements are complemented by efforts to manage customer input after products have been deployed. For the latter, support tickets are key in allowing customers to submit their issues, bug reports, and feature requests. Whenever insufficient attention is given to support issues, however, their escalation to management is time-consuming and expensive, especially for large organizations managing hundreds of customers and thousands of support tickets. Our work provides a step towards simplifying the job of support analysts and managers, particularly in predicting the risk of escalating support tickets. In a field study at our large industrial partner, IBM, we used a design science methodology to characterize the support process and data available to IBM analysts in managing escalations. Through iterative cycles of design and evaluation, we translated our understanding of support analysts' expert knowledge of their customers into features of a support ticket model to be implemented into a Machine Learning model to predict support ticket escalations. We trained and evaluated our Machine Learning model on over 2.5 million support tickets and 10,000 escalations, obtaining a recall of 79.9% and an 80.8% reduction in the workload for support analysts looking to identify support tickets at risk of escalation. Further on-site evaluations, through a prototype tool we developed to implement our Machine Learning techniques in practice, showed more efficient weekly support-ticket-management meetings. The features we developed in the Support Ticket Model are designed to serve as a starting place for organizations interested in implementing our model to predict support ticket escalations, and for future researchers to build on to advance research in escalation prediction.

Managing support tickets in large, multi-product organizations is difficult. Failure to meet the expectations of customers can lead to the escalation of support tickets, which is costly for IBM in terms of customer relationships and resources spent addressing the escalation. Keeping the customer happy is an important task in requirements engineering, which often comes in the form of handling their problems brought forth in support tickets. Proper attention to customers, their issues, and the bottom-up requirements that surface through bug reports can be difficult when the support process involves spending a lot of time managing customers to prevent escalations. For any given support analyst, understanding the customer is achievable through time spent looking through past and present support tickets within their organization; however, this solution does not scale up to account for all support tickets across all product teams. ECrits is a tool developed to help mitigate information overload by selectively mining customer information from support ticket repositories, displaying that data to support analysts, and doing predictive modelling on that data to suggest which support tickets are likely to escalate.

In a large organization, informal communication and simple backlogs are not sufficient for the management of requirements and development work. Many large organizations are struggling to successfully adopt agile methods, but there is still little scientific knowledge on requirements management in large-scale agile development organizations. We present an in-depth study of an Ericsson telecommunications node development organization which employs a large scale agile method to develop telecommunications system software. We describe how the requirements flow from strategy to release, and related benefits and problems. Data was collected by 43 interviews, which were analyzed qualitatively. The requirements management was done in three different processes, each of which had a different process model, purpose and planning horizon. The release project management process was plan-driven, feature development process was continuous and implementation management process was agile. The perceived benefits included reduced development lead time, increased flexibility, increased planning efficiency, increased developer motivation and improved communication effectiveness. The recognized problems included difficulties in balancing planning effort, overcommitment, insufficient understanding of the development team autonomy, defining the product owner role, balancing team specialization, organizing system-level work and growing technical debt. The study indicates that agile development methods can be successfully employed in organizations where the higher level planning processes are not agile. Combining agile methods with a flexible feature development process can bring many benefits, but large-scale software development seems to require specialist roles and significant coordination effort.

Software development has always inherently required multitasking: developers switch between coding, reviewing, testing, designing, and meeting with colleagues. The advent of software ecosystems like GitHub has enabled something new: the ability to easily switch between projects. Developers also have social incentives to contribute to many projects; prolific contributors gain social recognition and (eventually) economic rewards. Multitasking, however, comes at a cognitive cost: frequent context-switches can lead to distraction, sub-standard work, and even greater stress. In this paper, we gather ecosystem-level data on a group of programmers working on a large collection of projects. We develop models and methods for measuring the rate and breadth of a developers' context-switching behavior, and we study how context-switching affects their productivity. We also survey developers to understand the reasons for and perceptions of multitasking. We find that the most common reason for multitasking is interrelationships and dependencies between projects. Notably, we find that the rate of switching and breadth (number of projects) of a developer's work matter. Developers who work on many projects have higher productivity if they focus on few projects per day. Developers that switch projects too much during the course of a day have lower productivity as they work on more projects overall. Despite these findings, developers perceptions of the benefits of multitasking are varied.

The goal of this one-day workshop is to bring together researchers interested in techniques and tools that leverage context information that accumulates around development activities. Developers continuously make use of context to make decisions, coordinate their work, understand the purpose behind their tasks, and understand how their tasks fit with the rest of the project. However, there is little research on defining what context is, how we can model it, and how we can use those models to better support software development at large. This workshop brings together scholars interested in identifying, gathering and modelling context information in software development, as well as discussing its applications.

Researchers are currently drawn to study projects hosted on GitHub due to its popularity, ease of obtaining data, and its distinctive built-in social features. GitHub has been found to create a transparent development environment, which together with a pull request-based workflow, provides a lightweight mechanism for committing, reviewing and managing code changes. These features impact how GitHub is used and the benefits it provides to teams' development and collaboration. While most of the evidence we have is from GitHub's use in open source software (OSS) projects, GitHub is also used in an increasing number of commercial projects. It is unknown how GitHub supports these projects given that GitHub's workflow model does not intuitively fit the commercial development way of working. In this paper, we report findings from an online survey and interviews with GitHub users on how GitHub is used for collaboration in commercial projects. We found that many commercial projects adopted practices that are more typical of OSS projects including reduced communication, more independent work, and self-organization. We discuss how GitHub's transparency and popular workflow can promote open collaboration, allowing organizations to increase code reuse and promote knowledge sharing across their teams.

Knowing the impact in real settings of a software development approach is beneficial to both the industry and the research community. In this paper, we report on a field study we conducted at General Motors with the intent of understanding whether the organization was achieving some of the intended benefits of introducing a model-driven approach to software engineering. This study involved both observations and interviews. We found that several factors are still limiting the productivity increase claimed by MDE.

We describe an experience in teaching global software engineering (GSE) using distributed Scrum augmented with industrial best practices. Our unique instructional technique had students work in both same-site and cross-site teams to contrast the two modes of working. The course was a collaboration between Aalto University, Finland and University of Victoria, Canada. Fifteen Canadian and eight Finnish students worked on a single large project, divided into four teams, working on interdependent user stories as negotiated with the industrial product owner located in Finland. Half way through the course, we changed the teams so each student worked in both a local and a distributed team. We studied student learning using a mixed-method approach including 14 post-course interviews, pre-course and Sprint questionnaires, observations, meeting recordings, and repository data from git and Flow dock, the primary communication tool. Our results show no significant differences between working in distributed vs. Non-distributed teams, suggesting that Scrum helps alleviate many GSE problems. Our post-course interviews and survey data allows us to explain this effect, we found that students over time learned to better self-select tasks with less inter-team dependencies, to communicate more, and to work better in teams.

Software projects are not developed in isolation. Recent research has shifted to studying software ecosystems, communities of projects that depend on each other and are developed together. However, identifying technical dependencies at the ecosystem level can be challenging. In this paper, we propose a new method, known as reference coupling, for detecting technical dependencies between projects. The method establishes dependencies through user-specified cross-references between projects. We use our method to identify ecosystems in GitHub-hosted projects, and we identify several characteristics of the identified ecosystems. We find that most ecosystems are centered around one project and are interconnected with other ecosystems. The predominant type of ecosystems are those that develop tools to support software development. We also found that the project owners' social behaviour aligns well with the technical dependencies within the ecosystem, but project contributors' social behaviour does not align with these dependencies. We conclude with a discussion on future research that is enabled by our reference coupling method.

Self-adaptive systems are capable of dealing with uncertainty at runtime handling complex issues as resource variability, changing user needs, and system intrusions or faults. If the requirements depend on context, runtime uncertainty will affect the execution of these contextual requirements. This work presents SACRE, a proof-of-concept implementation of an existing approach, ACon, developed by researchers of the Univ. of Victoria (Canada) in collaboration with the UPC (Spain). ACon uses a feedback loop to detect contextual requirements affected by uncertainty and data mining techniques to determine the best operationalization of contexts on top of sensed data. The implementation is placed in the domain of smart vehicles and the contextual requirements provide functionality for drowsy drivers.

When software developers fail to coordinate, build failures, duplication of work, schedule slips and software defects can result. However, developers are often unaware of when they need to coordinate, and existing methods and tools that help make developers aware of their coordination needs do not provide timely or efficient recommendations. We describe our techniques to identify timely and efficient coordination recommendations, which we developed and evaluated in a study of coordination needs in the Mylyn software project. We describe how data obtained from tools that capture developer actions within their Integrated Development Environment (IDE) as they occur can be used to timely identify coordination needs; we also describe how properties of tasks coupled with machine learning can focus coordination recommendations to those that are more critical to the developers to reduce information overload and provide more efficient recommendations. We motivate our techniques through developer interviews and report on our quantitative analysis of coordination needs in the Mylyn project. Our results suggest that by leveraging IDE logging facilities, properties of tasks and machine learning techniques awareness tools could make developers aware of critical coordination needs in a timely way. We conclude by discussing implications for software engineering research and tool design.

With over 10 million git repositories, GitHub is becoming one of the most important source of software artifacts on the Internet. Researchers are starting to mine the information stored in GitHub's event logs, trying to understand how its users employ the site to collaborate on software. However, so far there have been no studies describing the quality and properties of the data available from GitHub. We document the results of an empirical study aimed at understanding the characteristics of the repositories in GitHub and how users take advantage of GitHub's main features---namely commits, pull requests, and issues. Our results indicate that, while GitHub is a rich source of data on software development, mining GitHub for research purposes should take various potential perils into consideration. We show, for example, that the majority of the projects are personal and inactive; that GitHub is also being used for free storage and as a Web hosting service; and that almost 40% of all pull requests do not appear as merged, even though they were. We provide a set of recommendations for software engineering researchers on how to approach the data in GitHub.

Users on GitHub can watch repositories to receive notifications about project activity. This introduces a new type of passive project membership. In this paper, we investigate the behavior of watchers and their contribution to the projects they watch. We find that a subset of project watchers begin contributing to the project and those contributors account for a significant percentage of contributors on the project. As contributors, watchers are more confident and contribute over a longer period of time in a more varied way than other contributors. This is likely attributable to the knowledge gained through project notifications.

A growing number of software systems is characterized by continuous evolution as well as by significant interdependence with other systems (e.g. services, apps). Such software ecosystems promise increased innovation power and support for consumer oriented software services at scale, and are characterized by a certain openness of their information flows. While such openness supports project and reputation management, it also brings some challenges to Requirements Engineering (RE) within the ecosystem. We report from a mixed-method study of IBM®'s CLM®ecosystem that uses an open commercial development model. We analyzed data from from interviews within several ecosystem actors, participatory observation, and software repositories, to describe the flow of product requirements information through the ecosystem, how the open communication paradigm in software ecosystems provides opportunities for `just-in-time' RE, as well as some of the challenges faced when traditional requirements engineering approaches are applied within such an ecosystem. More importantly, we discuss two tradeoffs brought about the openness in software ecosystems: i) allowing open, transparent communication while keeping intellectual property confidential within the ecosystem, and ii) having the ability to act globally on a long-term strategy while empowering product teams to act locally to answer end-users' context specific needs in a timely manner.

Methodology implementation failure is attributed to developer mediocrity (by management) – not to organizational mediocrity (rigidity or control-driven, process-driven management), or to a lack of adaptation capability in the methodology. In supporting software construction as a creative process, however, we must promote excellence rather than conformity. We argue that we – through principled research -- must pay attention to the interplay between methodology and culture – the local adaptations needed to make things work, understand how the two co-evolve and how they may contribute together to software quality.

Software projects involve diverse roles and artifacts that have dependencies to requirements. Project team members in different roles need to coordinate but their coordination is affected by the availability of domain knowledge, which is distributed among different project members, and organizational structures that control cross-functional communication. Our study examines how information flowed between different roles in two software projects that had contrasting distributions of domain knowledge and different communication structures. Using observations, interviews, and surveys, we examined how diverse roles working on requirements and their related artifacts coordinated along task dependencies. We found that communication only partially matched task dependencies and that team members that are boundary spanners have extensive domain knowledge and hold key positions in the control structure. These findings have implications on how organizational structures interfere with task assignments and influence communication in the project, suggesting how practitioners can adjust team configuration and communication structures.

This demo introduces V:ISSUE:LIZER, a tool for exploring online communication and analyzing clarification of requirements over time. V:Issue:lizer supports managers and developers to identify requirements with insufficient shared understanding, to analyze communication problems, and to identify developers that are knowledgeable about domain or project related issues through visualizations. Our preliminary evaluation shows that V:Issue:lizer offers managers valuable information for their decision making. (Demo video: http://youtu.be/Oy3xvzjy3BQ).

In this paper we describe distributed Scrum augmented with best practices in global software engineering (GSE) as an important paradigm for teaching critical competencies in GSE. We report on a globally distributed project course between the University of Victoria, Canada and Aalto University, Finland. The project-driven course involved 16 students in Canada and 9 students in Finland, divided into three cross-site Scrum teams working on a single large project. To assess learning of GSE competencies we employed a mixed-method approach including 13 post-course interviews, pre-, post-course and iteration questionnaires, observations, recordings of Daily Scrums as well as collection of project asynchronous communication data. Our analysis indicates that the Scrum method, along with supporting collaboration practices and tools, supports the learning of important GSE competencies, such as distributed communication and teamwork, building and maintaining trust, using appropriate collaboration tools, and inter-cultural collaboration.

Several methods exist to detect the coordination needs within software teams. Evidence exists that developers’ awareness about coordination needs improves work performance. Distinguishing with certainty between critical and trivial coordination needs and identifying and prioritizing which specific tasks a pair of developers should coordinate about remains an open problem. We investigate what work dependencies should be considered when establishing coordination needs within a development team. We use our conceptualization of work dependencies named Proximity and leverage machine learning techniques to analyze what additional task properties are indicative of coordination needs. In a case study of the Mylyn project, we were able to identify from all potential coordination requirements a subset of 17% that are most critical. We define critical coordination requirements as those that can cause the most disruption to task duration when left unmanaged. These results imply that coordination awareness tools could be enhanced to make developers aware of only the coordination needs that can bring about the highest performance benefit.

Building tools to help software developers communicate effectively requires a deep understanding of their communication dynamics. To date we do not have good comprehension of why developers talk to each other as a result of some events in the life of their projects, and not of others. This lack of knowledge makes it difficult to design useful communication models and support systems.

In current project environments, requirements often evolve throughout the project and are worked on by stakeholders in large and distributed teams. Such teams often use online tools such as mailing lists, bug tracking systems or online discussion forums to communicate, clarify or coordinate work on requirements. In this kind of environment, the expected evolution from initial idea, through clarification, to a stable requirement, often stagnates. When project managers are not aware of underlying problems, development may proceed before requirements are fully understood and stabilized, leading to numerous implementation issues and often resulting in the need for early redesign and modification. In this paper, we present an approach to analyzing online requirements communication and a method for the detection and classification of clarification events in requirement discussions. We used our approach to analyze online requirements communication in the IBM®Rational Team Concert®(RTC) project and identified a set of six clarification patterns. Since a predominant amount of clarifications through the lifetime of a requirement is often indicative of problematic requirements, our approach lends support to project managers to assess, in real-time, the state of discussions around a requirement and promptly react to requirements problems.

Sharing knowledge in a timely fashion is important in distributed software development. However, because experts are difficult to locate, developers tend to broadcast information to find the right people, which leads to overload and to communication breakdowns. We study the context in which experts are included in an email discussion so that team members can identify experts sooner. In this paper, we conduct a case study examining why people emerge in discussions by examining email within a distributed team. We find that people emerge in the following four situations: when a crisis occurs, when they respond to explicit requests, when they are forwarded in announcements, and when discussants follow up on a previous event such as a meeting. We observe that emergent people respond not only to situations where developers are seeking expertise, but also to execute routine tasks. Our findings have implications for expertise seeking and knowledge management processes.

Software projects typically rely on system analysts to conduct requirements elicitation, an approach potentially costly for large projects with many stakeholders and requirements. This paper describes StakeSource2.0, a web-based tool that uses social networks and collaborative filtering, a "crowdsourcing" approach, to identify and prioritise stakeholders and their requirements.

Distributed Software Development (DSD) is an emerging research area in software engineering. Several conducted research studies identified similar communication problems among DSD teams and tried to solve them. In this paper we present patterns that we have identified while surveying state of the art research studies. The patterns can help to organize DSD teams better in order to enhance their communication. We also highlight some potential future research challenges.

The primary goal of requirements engineering research is to propose, develop, and validate effective solutions for important practical problems. However practice has shown that successful projects often take from 20-25 years to reach the stage of full industry adoption, while many other projects fizzle out and never advance beyond the initial research phase. In this interactive panel, teams of researchers representing several different requirements engineering research areas, bring ideas for technology transfer to a panel of industrial and government practitioners. The teams proceed through a series of interactive presentations and receive feedback from panelists. Underlying the game-show genre of the panel is the more serious goal to foster conversation between practitioners and researchers in order to improve the effectiveness of technology transfer in the requirements engineering community.

Requirements engineering involves collaboration among many project team members. Driven by coordination needs, this collaboration relies on communication and knowledge that members have of their colleagues and related activities. Ineffective coordination with those who work on requirements dependencies may result in project failure. In this paper, we report on a study of roles and communication structures in the collaboration driven by interdependent requirements in a software team. Through on-site observations, interviews with the developers and application of social network analysis, we found that there was significant communication between diverse roles in the project, and identified what were the reasons for communication between the different roles. We also found that these interactions typically involved a core of requirements analysts and testers in close communication, that most often they involved critical members whose absence, whether temporary or permanent, would disrupt the information flow if removed from the project, as well as that new hires were mostly isolated from the team collaboration. Most interestingly we found that the emergent communication structure between the different roles in the project did not conform to the planned communication structure prescribed by the organization. These findings further our knowledge about collaboration driven by requirements, and provide some useful implications for research and development of collaborative tools to support the effective coordination of cross-functional teams in software development.

Socio-technical congruence is an approach that measures coordination by examining the alignment between the technical dependencies and the social coordination in the project. We conduct a case study of coordination in the IBM Rational Team Concert project, which consists of 151 developers over seven geographically distributed sites, and expect that high congruence leads to a high probability of successful builds. We examine this relationship by applying two congruence measurements: an unweighted congruence measure from previous literature, and a weighted measure that overcomes limitations of the existing measure. We discover that there is a relationship between socio-technical congruence and build success probability, but only for certain build types, and observe that in some situations, higher congruence actually leads to lower build success rates. We also observe that a large proportion of zero-congruence builds are successful, and that socio-technical gaps in successful builds are larger than gaps in failed builds. Analysis of the social and technical aspects in IBM Rational Team Concert allows us to discuss the effects of congruence on build success. Our findings provide implications with respect to the limits of applicability of socio-technical congruence and suggest further improvements of socio-technical congruence to study coordination.

Successful distributed collaboration requires support for informal communication, opportunistic interactions, and smooth and frequent shifts between synchronous and asynchronous collaboration modes. Introducing new collaboration tools for distributed interaction is often regarded as a difficult organizational endeavor, compounded by a lack of concrete, empirical evidence of expected improvements in tool-supported distributed collaboration. In this paper, we describe the introduction of the Microsoft Office Communication Server collaboration tool to improve collaboration in a distributed project at Siemens IT Solutions and Services. Improvements included (1) faster response and resolution time on issues that involve cross-site communication; (2) enhanced productivity of global teams, enhanced sense of teamwork, and motivation in the global team; and (3) flatter communication structures across sites. We discuss lessons learned from the adoption of the collaboration tool and factors that made it possible.

A critical factor in work group coordination, communication has been studied extensively. Yet, we are missing objective evidence of the relationship between successful coordination outcome and communication structures. Using data from IBM's Jazztrade project, we study communication structures of development teams with high coordination needs. We conceptualize coordination outcome by the result of their code integration build processes (successful or failed) and study team communication structures with social network measures. Our results indicate that developer communication plays an important role in the quality of software integrations. Although we found that no individual measure could indicate whether a build will fail or succeed, we leveraged the combination of communication structure measures into a predictive model that indicates whether an integration will fail. When used for five project teams, our predictive model yielded recall values between 55% and 75%, and precision values between 50% to 76%.

Nowadays, distributed development is common in software development. Besides many advantages, research in the last decade has consistently found that distribution has a negative impact on collaboration in general, and communication and task completion time in particular. Adapted processes, practices and tools are demanded to overcome these challenges. We report on an empirical study of communication structures and delay, as well as task completion times in IBM's distributed development project Jazz. The Jazz project explicitly focuses on distributed collaboration and has adapted processes and tools to overcome known challenges. We explored the effect of distance on communication and task completion time and use social network analysis to obtain insights about the collaboration in the Jazz project. We discuss our findings in the light of existing literature on distributed collaboration and delays.

In this paper, we describe a preliminary capability model that captures patterns of evolution in the practice of distributed software development in internal offshoring projects. In our research we seek to understand how the practices of organizations involved in the internal offshoring of software development evolve over time, from a software engineering perspective, and from the point of view of the subsidiaries. Based on a combination of qualitative and quantitative methods, we propose a capability model that encompasses the evolution of software development activities within and among several subsidiaries owned by an organization.

Requirements interdependencies create technical dependencies among project members that generally belong to different functional groups in an organization, but who need to coordinate activities during processes of requirements change management. Effective knowledge management is needed to disseminate information on requirement changes across teams working on interdependent requirements to avoid mis-interpretations. Social networks are regarded as important in fostering knowledge management, where brokers or gatekeepers have the role of project members facilitating information flow. However, little is known about processes of information flow and brokerage in social networks built around interdependent requirements. In a field study of requirement interdependencies in a large IT manufacturing organization, we found that brokers holding pockets of knowledge have an impact on information flow in requirement-interdependent teams. We discuss a number of patterns of information flow and draw implications for processes of requirements change management.

Achieving agreement with respect to software requirements is a collaborative process that traditionally relies on same-time, same-place interactions. As the trend toward geographically distributed software development continues, colocated meetings are becoming increasingly problematic. Our research investigates the impact of computer-mediated communication on the performance of distributed client/developer teams involved in the collaborative development of a requirements specification. Drawing on media-selection theories, we posit that a combination of lean and rich media is needed for an effective process of requirements negotiations when stakeholders are geographically dispersed. In this paper, we present an empirical study that investigates the performance of six educational global project teams involved in a negotiation process using both asynchronous text-based and synchronous videoconferencing-based communication modes. The findings indicate that requirement negotiations were more effective when the groups conducted asynchronous structured discussions of requirement issues prior to the synchronous negotiation meeting. Asynchronous discussions were useful in resolving issues related to uncertainty in requirements, thus allowing synchronous negotiations to focus more on removing ambiguities in the requirements.

Among the software development activities, requirements engineering is one of the most communication-intensive and then, its effectiveness is greatly constrained by the geographical distance between stakeholders. For this reason, the need to identify the appropriate task/technology fits to support teams of geographically dispersed stakeholders plays a key role for coping with the lack of physical proximity when developing requirements. In this paper we report on an empirical study that assessed the use of synchronous text-based communication in distributed requirements workshops, as compared to face-to-face (F2F), and the effects of computer-mediated communication (CMC), with respects to the different tasks of distributed requirements elicitation and negotiation. First results show that, in terms of satisfaction with performance, CMC elicitation is a better task/technology fit than CMC negotiation. Furthermore, the general preference for F2F over CMC is due to the strong preference for the F2F negotiation fit over the CMC counterpart.

Global software teams face challenges when collaborating over long distances, such as communicating changes in the project. During a four-month case study at IBM Ottawa Software Lab we observed the collaboration patterns of a multi-site development project team. In this period, we inspected project documentation, interviewed team leaders, attended project meetings, and spoke with developers to identify problems originated by the lack of awareness of changes related to the implementation of work items. Our observations show (1) that organizational culture has an effect on how developers are made aware; (2) that communication-based social networks revolving around particular work items are dynamic throughout development, and therefore awareness needs to be maintained in infrastructures of work; and (3) that information overload and communication breakdowns contributed to the generation of a broken integration build. We discuss these breakdowns in communication and implications for the design of collaboration tools that could mitigate these problems.

Distributed Software Development involves a number of different business models, and companies intending to embark on the journey of distributed development have difficulty choosing the model(s) that suits their process and current software practice. More literature that presents similarities as well as differences among these models, in terms of processes, practices and challenges that characterize them, is thus becoming critical to software practitioners. This paper intends to bring more knowledge in this direction. We present empirical evidence from a case study of DSD practice in five companies that had projects following one or more of the different DSD business models described in the literature. We discuss the similarities and differences in the challenges faced by the projects in these models, as well as the relationship between the models, development process, and project size and complexity, as reported in the projects studied.

Because of intense collaborative needs, requirements engineering is a challenge in global software development. How do distributed teams manage the development of requirements in environments that require significant cross-site collaboration and coordination? In this paper, we report research that used social network analysis to explore collaboration and awareness among team members during requirements management in an industrial distributed software team. Using the lens of a requirements-centred social network to group team members who work on a particular requirement, we collected data to characterize requirements-centric collaborations in a project, and to examine aspects of awareness of requirements changes within these networks. Our findings indicate organic patterns of collaboration involving considerable cross-site interaction, in which communication of changes was the most predominant reason for interaction. Although we did not find evidence that distance affects developers' awareness of remote team members who work on the same requirements, distance affected how accessible the remote colleagues were. We discuss implications for knowledge sharing and coordination of work on a requirement in distributed teams, and propose directions for the design of collaboration tools that support awareness in distributed requirements management.

Project collaborators in a software development project need to stay aware not only of changes to requirements and other artifacts, but also of each other's current work. The set of team members working on a requirement is dynamic, and team members who were not assigned to the requirement in the plan may be involved. If this requirement changes, those team members who are dependent on that requirement must be notified quickly before they do outdated work. However, project plans often do not provide an easy method of listing all of the emergent team members who should be notified of changes to a requirement. We propose a requirements-dependency diagram that displays interdependent requirements and team members who are assigned to these interdependent requirements. The visualization highlights prominent collaborators, lists each collaborator and each requirement only once, marks emergent collaborators, and is simple and clutter-free. By viewing this diagram, collaborators will know who to contact to notify others of changes to requirements, and can contact experts working on interrelated requirements.

Due to its communication and collaborationintensive nature, processes of requirements engineering (RE) become one of the key challenges in distributed software development. The reality of distributed projects is that cross-functional stakeholder groups are tasked with specifying and managing requirements across cultural, time-zone and organizational boundaries. This creates an unique set of problems not only when an organization opens development centres across the world, but also when software development is a multi-organizational business affair.

In the context of increasing pressure to adopt global approaches to software development, the importance of teaching skills for geographically distributed software development (GSD) becomes essential. This paper reports the experience of teaching a course to prepare graduates for software engineering (SE) in global customer-developer teams, and which was taught in three-University collaboration (Canada, Australia and Italy). The course emphasized the learning of requirements management activities in frequent synchronous computer-mediated client-developer relationships and created a GSD environment with significant time zone and language differences. We describe our instructional approach and assessment strategies within a GSD instructional design framework which integrates (a) required GSD skills and strategies for aligning classroom projects with contemporary and authentic GSD conditions, (b) strategies for assessment of learning of GSD skills and (c) examples from our GSD course.

Important and yet very difficult process in software development, requirements engineering is plagued with additional challenges in the emergent dynamics of geographically distributed software teams. Our hypothesis is that a mix of lean and rich communication media are needed towards increasing the effectiveness of meetings in reaching mutual agreement when stakeholders are geographically dispersed.We studied tool-supported remote inspections in six educational global project teams in a multicultural software development environment. In this paper we present the preliminary results from comparing the effectiveness of the requirements negotiations when preceded by the asynchronous discussions to those negotiations with no prior asynchronous discussions.

Requirements engineering is an important component of effective software engineering, yet more research is needed to demonstrate the benefits to development organizations. While the existing literature suggests that effective requirements engineering can lead to improved productivity, quality, and risk management, there is little evidence to support this. We present empirical evidence showing how requirements engineering practice relates to these claims. This evidence was collected over the course of a 30-month case study of a large software development project undergoing requirements process improvement. Our findings add to the scarce evidence on RE payoffs and, more importantly, represent an in-depth explanation of the role of requirements engineering processes in contributing to these benefits. In particular, the results of our case study show that an effective requirements process at the beginning of the project had positive outcomes throughout the project lifecycle, improving the efficacy of other project processes, ultimately leading to improvements in project negotiation, project planning, and managing feature creep, testing, defects, rework, and product quality. Finally, we consider the role collaboration had in producing the effects we observed and the implications of this work to both research and practice

One thing that keeps many software-development organizations from doing serious requirements engineering before beginning development is the perception that doing requirements engineering wastes time and delays getting on to the real work, designing and programming. The first third of this paper presents anecdotal and case study evidence that upfront RE pays off big. The second third is a discussion on structural and cultural barriers to industrial adoption of RE practices. The final third is a free-wheeling discussion on these and related issues

There is limited evidence (Brooks (1987), Fosberg and Mooz (2000) and S. Robertson and J. Robertson (1999)) which supports claims in literature that requirements engineering (RE) can have positive effects on an organization's ability to manage project risk. Such evidence can serve to motivate industrial adoption of requirements engineering techniques, but it can also contribute to our understanding of the role of RE in supporting project management activities. This paper presents an analysis of the causal relationship between RE practice and benefits in risk management in one software organization that revised its RE process and enjoyed improvements in its project management activities. In particular, we present insights from our investigation of the interaction between the RE process and the processes of project planning and SQA. We found that elements of the RE process such as feature decomposition, structure documentation and traceability links improved feature sizing and enabled effective change management, contributing to improved risk management activities. These findings are useful to practitioners in similar software organizations whose product release objectives originate from a remote business unit and who currently suffer from significant feature creep.

The goal of this workshop is to provide an opportunity for researchers and industry practitioners to explore both the state-of-the art and the state-of-the-practice in global software development (GSD). Increased globalization of software development creates software engineering challenges due to the impact of temporal, geographical and cultural differences, and requires development of techniques and technologies to address these issues. The workshop will foster interaction between practitioners and researchers and help grow a community of interest in this area. Practitioners experiencing challenges in GSD will share their concerns and successful solutions and learn from research about current investigations. Researchers addressing GSD will gain a better understanding of the key issues facing practitioners and share their work in progress with others in the field.

The goal of this workshop is to bring together researchers and practitioners in trying to understand the emerging phenomenon of global software development. As we witness an increased globalization of software development, it is important that research addresses the challenges of distributed software engineering and informs the development of techniques and technologies to improve such practice.

The increasing globalization of software industry demands an investigation of requirements engineering (RE) in multisite software development organizations. Requirements engineering is a task difficult enough when done locally-but it is even more difficult when cross-functional stakeholder groups specify requirements across cultural, language and time zone boundaries. This paper reports on a field study that investigated RE challenges introduced by stakeholders' geographical distribution in a multi-site organization. The goal was to examine RE practice in global software development, to formulate recommendations for improvement as well as to provide directions for future research on methods and tools. Based on the empirical evidence, we have constructed a model of how remote communication and knowledge management, cultural diversity and time differences negatively impact on requirements gathering, negotiation and specification. Findings reveal that aspects such as a lack of a common understanding of requirements, together with reduced awareness of working local context, trust level and ability to share work artifacts significantly challenge the effective collaboration of remote stakeholders in negotiating a set of requirements that satisfies geographically distributed customers. The paper concludes with recommendations for improving RE practice in this setting.

In current literature few detailed process models for Requirements Engineering are presented: usually high-level activities are distinguished, without a more precise specification of each activity. In this paper the process of Requirements Engineering has been analyzed using knowledge-level modelling techniques, resulting in a well-specified compositional process model for the Requirements Engineering task. This process model is considered to be a generic process model: it can be refined (by instantiation or specialisation) into a process model for a specific kind of Requirements Engineering process.

The software development world is experiencing an irreversible trend towards the globalization of business. This creates the need for a thorough understanding of collaborative activities such as requirements engineering and design of software in distributed development environments. The requirements conflicts and tradeoffs are critical aspects that occur throughout software development and we, as software engineers, need to better understand the technological impacts on the performance of groups resolving requirements issues in distributed development structures. In this paper lessons learned from an exploratory study of requirements meetings in which stakeholders participate from remote sites are reported. Evidence not only shows that distributed requirements engineering is supported by current multimedia meeting systems but also reveals aspects that enabled the distributed communication of stakeholders to be more effective in achieving agreements integrative of each stakeholder's interests and needs. Practical implications of the results and recommendations for the software industry in enabling effective distributed requirements meetings are outlined.

Group facilitation is an important element of group approaches to requirements engineering (RE). The facilitation in traditional face-to-face groups is challenged by the increased globalization of the software industry. Thorough empirical investigation of human facilitation in computer-mediated requirements meetings is needed. This paper presents findings about the facilitation of distributed group settings in a controlled environment. Three professional facilitators mediate 15 three-person groups negotiating software requirements. Facilitation in face-to-face meetings is contrasted with four group settings in which the facilitator is physically separated from the group or co-located with key stakeholders. Rich qualitative and behavioral data enables an understanding of differences and similarities in the facilitation of the distributed groups and of aspects that were detrimental or beneficial to their facilitation. The empirical evidence indicates a reduced richness of social behaviors in computer-mediated group settings which: made the group facilitation problematic; but also enabled certain facilitation support in the medium itself.