Context: The characteristics of software professionals have been widely investigated in the literature. However, limited attention has been given to undesirable attributes in Requirements Engineering, despite the strong dependence of this activity on stakeholder interaction and collaboration. Objective: This study investigates the undesirable attributes of requirements engineers’ hat may hinder collaboration and project success. Method: We surveyed software practitioners to identify these attributes and conducted interviews to gather supporting evidence. Results: Seventeen undesirable attributes were identified, grouped into four categories (communication issues, lack of domain knowledge, personality, and lack of technical knowledge), and organized into conceptual maps. Conclusion: The maps help requirements engineers reflect on and improve their professional practice by recognizing traits that may hinder collaboration and project outcomes.

Qualitative analysis plays a pivotal role in understanding the human and social aspects of software engineering. However, it remains a demanding process shaped by the subjective interpretation of individual researchers and sensitive to methodological choices such as prompt design. Recent advancements in Large Language Models (LLMs) offer promising opportunities to support this type of analysis, although their reliability in reproducing human qualitative reasoning under varying prompting conditions remains largely untested. This study presents a controlled empirical evaluation of three LLMs – Claude Haiku, DeepSeek-Chat, and Gemini 2.5 Flash – across two prompt engineering strategies (zero-shot and multi-shot closed coding), using Cohen's kappa as the primary agreement metric over ten independent runs per configuration. Results suggest that multi-shot prompting significantly improves agreement for Claude Haiku (Delta kappa = +0.034, Wilcoxon p = 0.004) but not for DeepSeek-Chat or Gemini 2.5 Flash. Intra-model stability varies substantially – DeepSeek-Chat and Claude Haiku exhibit the lowest variance (SD approx. 0.017), while Gemini 2.5 Flash is the least stable (SD = 0.038). A systematic over-prediction of "Sharing Negative Feedback" is identified across all models (bias ratios up to 5.25x), alongside consistent under-prediction of "Expressing Concerns." Collectively, these findings provide empirical evidence for prompt engineering guidelines in LLM-assisted qualitative coding for software engineering research.

Context: Psychological safety (PS) is an important factor influencing team well-being and performance, particularly in collaborative and dynamic domains such as software development. Despite its acknowledged significance, research on PS within the field of software engineering remains limited. The socio-technical complexities and fast-paced nature of software development present challenges to cultivating PS. To the best of our knowledge, no systematic secondary study has synthesized existing knowledge on PS in the context of software engineering. Objective: This study aims to systematically review and synthesize the existing body of knowledge on PS in software engineering. Specifically, it seeks to identify the potential antecedents and consequences associated with the presence or absence of PS among individuals involved in the software development process. Methods: A systematic literature review was conducted, encompassing studies retrieved from four digital libraries. The extracted data were subjected to both quantitative and qualitative analyses. Results: The findings indicate a growing academic interest in PS within software engineering, with the majority of studies grounded in Edmondson's framework. Factors antecedents of PS were identified at the individual, team, and organizational levels, including team autonomy, agile methodologies, and leadership behaviors. The presence of PS was found to positively impact team dynamics, software quality, technical excellence, and job satisfaction. Furthermore, PS was observed to mediate relationships between constructs such as ethical leadership and innovative behavior. Conclusion: PS fosters innovation, learning, and team performance within software development. However, significant gaps persist in understanding the contextual factors influencing PS, its underlying mechanisms, and effective strategies for its enhancement. Future research should address these gaps by investigating the practical applications of PS within diverse organizational settings in the software engineering domain.

Background: The use of grey literature (GL) has grown in software engineering research, especially in studies that consider questions and answers (Q A) websites, since software development professionals widely use them. Although snowballing (SB) techniques are standard in systematic literature reviews, little is known about how to apply them to GL reviews. Aims: This paper investigates how to apply SB approaches on Q A websites to identify new valid discussions for analysis during the exploration of such sites. Method: In previous studies, we compiled and analyzed a set of Stack Exchange Project Management (SEPM) discussions related to software engineering technical debt. Those studies used a data set consisting of 108 valid discussions extracted from SEPM. Based on this start data set, we perform forward and backward SB using two different approaches: link-based and similarity-based SB. We then compare the precision and recall of those two SB approaches against the search-based approach of the original study. Results: In just one SB iteration, the approaches yielded 291 new discussions for analysis, 130 of which were considered valid for our study. This represents an approximate 120

Social aspects of software practitioners strongly influence software engineering outcomes. For instance, software companies seek to measure how factors like work engagement and job satisfaction impact employee productivity and software quality. Work engagement represents a positive, fulfilling, work-related mental state, while job satisfaction reflects how content professionals are with their roles. Our study aims to highlight the social aspects of software practitioners considering a large organization. We investigate the work engagement and job satisfaction of software practitioners working remotely at a large software organization in the public sector. We surveyed 891 software practitioners and analyzed their responses qualitatively and quantitatively. The survey participants indicated strong work engagement. They perceived their teams as effective, but there is room for improving social aspects, such as communication within the teams, promoting discussions about career development, and consistent feedback. Most professionals are satisfied with their teams, though a small minority expressed concerns that may influence their willingness to recommend their teams. Our findings provide relevant information about the engagement and satisfaction of employees within this particular type of organization and expand the knowledge base on the subject, supporting new research efforts in the area.

[Context]. Requirements Process Debt (RPD) refers to shortcomings or inefficiencies in the requirements engineering process. Through an industry-wide survey, the InsighTD project identified the causes of RPD, its effects, and practices for its prevention and mitigation. Another approach to exploring RPD is by examining grey literature (GL), i.e., sources that have not been formally published. One such source is the discourse of solution providers, a specific type of web content. Although this discourse can enhance the knowledge gained through empirical studies, no research has yet explored it. [Aims]. To investigate how public discourse has discussed the causes of RPD. [Research Method]. We elicited public discourse on RPD causes using predefined search strings on Google and Bing. We collected web addresses where discussions on RPD causes were found and applied content analysis procedures to examine the data. [Results]. Based on public discourse, we produced 128 codes for causes, 60 for effects of RPD, along with 93 preventive and 70 mitigation practices. These elements were categorized to reveal their relationships within the software development process. [Conclusion]. Our study expands the body of knowledge on RPD causes, demonstrating that GL can serve as a valuable complementary source.

Context and motivation: Several studies have investigated attributes of great software practitioners. However, the investigation of such attributes is still missing in Requirements Engineering (RE). The current knowledge on attributes of great software practitioners might not be easily translated to the context of RE because its activities are, usually, less technical and more human-centered than other software engineering activities. Question/problem: This work aims to investigate which are the attributes of great requirements engineers, the relationship between them, and strategies that can be employed to obtain these attributes. We follow a method composed of a survey with 18 practitioners and follow up interviews with 11 of them. Principal ideas/results: Investigative ability in talking to stakeholders, judicious, and understand the business are the most commonly mentioned attributes amongst the set of 22 attributes identified, which were grouped into four categories. We also found 38 strategies to improve RE skills. Examples are training, talking to all stakeholders, and acquiring domain knowledge. Contribution: The attributes, their categories, and relationships are organized into a map. The relations between attributes and strategies are represented in a Sankey diagram. Software practitioners can use our findings to improve their understanding about the role and responsibilities of requirements engineers.

Code churn, the intensity of software changes, can threaten software quality and has been empirically associated with many quality attributes. However, few studies have explored its relationship with code smells, which are widely recognized as indicators of poor object-oriented design quality. This study presents a preliminary investigation into the relationship between code churn and code smells. We use the number of commits and edited lines as proxies for code churn and the presence of code smells as a measure of software quality. We mined a large software repository comprising 31 open-source projects, 749 developers, and 153,994 commits to examine how development activity intensity relates to the incidence of code smells. Our findings suggest that code churn is related to the presence of code smells. Notably, developers with lower activity levels tend to have a proportionally higher impact on the introduction or persistence of code smells. This preliminary study highlights a correlation between code churn and code smells, providing a foundation for further research. Future work may explore variations such as different types of smells or commit categories to deepen our understanding of this relationship.

Context. Empathy, a key social skill, is essential for communication and collaboration in SE but remains an under-researched topic. Aims. This study investigates empathy in SE from practitioners' perspectives, aiming to characterize its meaning, identify barriers, discuss practices to overcome them, and explore its effects. Method. A qualitative content analysis was conducted on 55 web articles from DEV and Medium, two communities widely used by practitioners. To strengthen our findings, we conducted a follow-up survey with empathy experts. Results. The study proposes a definition of empathy in SE, identifies barriers such as toxic culture and excessive technical focus, practices to foster empathy in teams, and outcomes, including improved collaboration, communication, and reduced anxiety, frustration, and stress. These findings are synthesized into a conceptual framework. Conclusion. Survey results indicate the framework is clear, valuable, and raises empathy awareness, with suggestions for improvements and integration into training. This study paves the way for improving team dynamics by addressing barriers and offering strategies to cultivate empathy. Future work will explore empathy's broader implications in SE practice.

This is the Replicated Computational Results (RCR) Report for our TOSEM paper “Exploring Empathy in Software Engineering: Insights from a Grey Literature Analysis of Practitioners’ Perspectives” where we present qualitative content analysis conducted on 55 web articles from DEV and Medium, two communities widely used by practitioners, and a follow-up survey with empathy experts. In this paper, we introduced a conceptual framework of empathy in software engineering. As part of this RCR, we provide an empirical package with detailed guidelines to set up and replicate our study, as well as to interpret the results. We hope it can motivate and support future research on empathy and human aspects in software engineering by offering a reusable and transparent example of qualitative analysis involving grey literature and expert feedback. All related data and materials are openly available in the experimental package.

A crisis is an inherently unpredictable event. However, it often exhibits patterns that can help authorities anticipate challenges and respond more effectively to crisis situations. Current information systems for public communication during crises tend to focus on disseminating standardized messages across various communication channels. This approach contradicts effective communication practices, as different audiences have different information needs. Inappropriate public communication messages can generate noise, amplify perception of risk, and increase feelings of insecurity. This paper proposes a novel model to guide the development of information systems for crisis communication. To ensure flexibility and adaptability across diverse crisis scenarios, our approach maps and models variability in the crisis communication process. This variability model enables the rapid creation of tailored yet consistent crisis communication, delivered through appropriate channels to meet the needs of different audiences - such as crisis responders, authorities, press and the general public - who are the intended recipients of the system.

The evaluation of software quality has traditionally focused on internal design characteristics, such as cohesion and complexity. However, recent studies have shown that contextual factors may also be associated with quality-related attributes. In this study, we investigate whether the incidence of the god class code smell varies according to different development contexts. We define context based on the combination of four software attributes: system size, number of commits, number of contributors, and development time. Using data from 419 Java systems extracted from GHTorrent, we classified the projects into distinct contexts and analyzed the distribution of the god class smell within each. The results reveal statistically significant variations in smell incidence across contexts, suggesting that contextual attributes should not be overlooked in the assessment of design quality. This work contributes by presenting an empirical analysis of god class incidence across distinct development contexts, introducing a methodological strategy for context formation based on measurable software attributes, providing empirical evidence that supports a contextualized understanding of design quality, and making the experimental package publicly available to foster further research on the topic.

Context: In the digital age, the software industry is central to innovation but still faces persistent gender inequality. Despite women’s historical contributions, their presence in the software industry remains disproportionately low due to systemic barriers. Aims: To identify and analyze challenges faced by women in software engineering based on descriptions in grey literature. Objectives include analyzing gender challenges, revealing their effects, identifying solutions, and organizing knowledge on barriers, effects, and solutions. Method: Using the thematic synthesis applied to grey literature, we analyzed posts from the DEV online community. Results: From the DEV articles, we identified barriers like toxic men dominance, sexism, pay gaps, and stereotypes, causing emotional exhaustion and career aspiration changes. Proposed solutions include mentorship, skill development, ignoring threats, and salary negotiation to foster workplace inclusion for women in software engineering. Conclusion: The study highlights the need to create a more equitable workspace where women can thrive and contribute to the advancement of technology.

Context. Technical debt (TD) monitoring allows software professionals to track the evolution of debt incurred in their projects. The technical literature has listed several practices used in the software industry to monitor indebtedness. However, there is limited evidence on the use and on the reasons to avoid using these practices. Aims. This work aims to investigate, from the point of view of software practitioners, the practices used for monitoring TD items, and the practice avoidance reasons (PARs) curbing the monitoring of TD items. Method. We analyze quantitatively and qualitatively a set of 653 answers collected with a family of industrial surveys distributed in six countries. Results. Practitioners are prone to monitor TD items, revealing 46 practices for monitoring the debt and 35 PARs for explaining TD non-monitoring. Both practices and PARs are strongly associated with planning and management issues. The study also shows the relationship found among practices, PARs and types of debt and presents a conceptual map that relates practices and PARs with their categories. Conclusion. The results of this study add to a practitioners’ capability to monitor TD items by revealing the monitoring practices, PARs and their relationship with different TD types.

Background: The use of gray literature (GL) has grown in software engineering research, especially in studies that consider Questions and Answers (Q A) sites, since software development professionals widely use them. Though snowballing (SB) techniques are standard in systematic literature reviews, little is known about how to apply them to gray literature reviews. Aims: This paper investigates how to use SB approaches on Q A sites during gray literature reviews to identify new valid discussions for analysis. Method: In previous studies, we compiled and analyzed a set of Stack Exchange Project Management (SEPM) discussions related to software engineering technical debt (TD). Those studies used a data set consisting of 108 valid discussions extracted from SEPM. Based on this start data set, we perform forward and backward SB using two different approaches: link-based and similarity-based SB. We then compare the precision and recall of those two SB approaches against the search-based approach of the original study. Results: In just one snowballing iteration, the approaches yielded 291 new discussions for analysis, 130 of which were considered valid for our study. That is an increase of about 120 original data set (recall). The SB process also yielded a similar rate of valid discussion retrieval when compared to the search-based approach (precision). Conclusion: This paper provides guidelines on how to apply two SB approaches to find new valid discussions for review. To our knowledge, this is the first study that analyzes the use of SB on Q A websites. By applying SB, it was possible to identify new discussions, significantly increasing the relevant data set for a gray literature review.

Context. Requirements engineers play a decisive role in the software development process, as they need to understand the application domain and provide good communication with the different project stakeholders. Although the competencies, skills and activities of requirements engineers have already been reported in the literature, it is necessary to investigate what Brazilian software development companies require from software engineers. Aims. To investigate the required technical knowledge, interpersonal skills, and responsibilities expected in the Brazilian job market for software requirements engineers. Method. We performed thematic analysis to examine 41 job ads collected from the LinkedIn Jobs plataform. Results. We found the main terms used for requirements engineers positions. We also recognized 81 technical knowledge and 37 responsibilities expected for requirements engineers. Lastly, we identified 22 interpersonal skills required by the Brazilian software industry. Conclusion. This work organizes the body of knowledge into a conceptual map to support requirements engineers in identifying what the Brazilian software industry expects from them.

Context: Agile methodologies use continuous delivery and adaptability to develop software that meets the needs of its users. However, such methods are prone to accumulate technical debt (TD). Agile teams must balance the benefits and risks of incurring debt by managing TD items. Knowing how TD management is conducted in agile software teams can help agile practitioners increase their ability to handle TD items. Aims: To investigate, based on the state of the art, how agile software teams have managed existing TD items in their projects. Method: We carried out a systematic mapping study covering 39 articles from 2010 to 2023. Results: Among the agile methodologies, Scrum was the most used for TD management. Regarding practices, agile teams employ mostly user stories and sprint backlogs to identify TD items. Sprints and sprint backlogs are used to monitor debt, while refactoring is applied to prevent and repay TD items. Conclusion: This study maps current knowledge on TD management in agile methodologies, serving as a starting point for new investigations in the area.

Context: Modularity is a key concept in software development. Well-modularized systems are easier to maintain and evolve, but achieving good modularity is difficult. Concerns that are important, but not central to a systems' main business rules, frequently end up scattered and entangled throughout several software modules. Those so called cross-cutting concerns are a major source of loss of modularity and code decay in software systems. Motivation: Studies on cross-cutting concerns often resort to manual identification of concerns, but manual identification is effort demanding, does not scale, and tends to be imprecise. Automatic approaches are therefore very attractive when the codebase is extensive. In modern systems, developers implement modules to address central business rules, but they tend to add third-party components in the codebase to materialize concerns related to other secondary aspects. Logging, database access, and tests automation are examples of concerns that are usually implemented with the help of imported components and are prone to scatter and tangle throughout the codebase. Aims: This paper proposes a method to track this type of cross-cutting concern. Our work takes advantage of the addition of metadata about components to track them. The method scales by automating the identification and analysis of concerns scattered throughout the software codebase. We define a new metric, Dedication to Concern (DtC), to measure how much source code modules focus on implementing the identified concerns. Working Method: We describe our method to mine cross-cutting concerns from the metadata related to the use of components. The method is instantiated as a tool, architectural knowledge suite (AKS). The tool is used to analyze concerns in a set of large Java projects. The results are used to feed an action research study, during which software development specialists analyze the AKS outputs to evaluate and evolve the method. Conclusion: The semi-automated approach is feasible and scalable, and can be used to analyze secondary concerns that are currently being imported into modern software systems via third-party components.