Searcharxiv⌕ Search

arXiv subjects

Jil Klünder

Publications and source records attributed to Jil Klünder.

At least 19 recordsLinked to original sources

Exploring Indicators of Developers' Sentiment Perceptions in Student Software Projects

Communication is a crucial social factor in the success of software projects, as positively or negatively perceived statements can influence how recipients feel and affect team collaboration through emotional contagion. Whether a developer perceives a written message as positive, negative, or neutral is likely shaped by multiple factors. In this paper, we investigate how mood traits and states, life circumstances, project phases, and group dynamics relate to the perception of text-based messages in software development. We conducted a four-round survey study with 81 students in team-based software projects. Across rounds, participants reported these factors and labeled 30 decontextualized statements for sentiment, including meta-data on labeling rationale and uncertainty. Our results show: (1) Sentiment perception is only moderately stable within individuals, and label changes concentrate on ambiguity-prone statements; (2) Correlation-level signals are small and do not survive global multiple-testing correction; (3) In statement-level repeated-measures models (GEE), higher mood trait and reactivity are associated with more positive (and less neutral) labeling, while predictors of negative labeling are weaker and at most trend-level (e.g., task conflict); (4) We find no clear evidence of systematic project-phase effects. Overall, sentiment perception varies within persons and is strongly statement-dependent. Although our study was conducted in an academic setting, the observed variability and ambiguity effects suggest caution when interpreting sentiment analysis outputs and motivate future work with contextualized, in-project communication.

cs.SE↗

Understanding Usefulness in Developer Explanations on Stack Overflow

Explanations are essential in software engineering (SE) and requirements communication, helping stakeholders clarify ambiguities, justify design choices, and build shared understanding. Online Q&A forums such as Stack Overflow provide large-scale settings where such explanations are produced and evaluated, offering valuable insights into what makes them effective. While prior work has explored answer acceptance and voting behavior, little is known about which specific features make explanations genuinely useful. The relative influence of structural, contextual, and linguistic factors, such as content richness, timing, and sentiment, remains unclear. We analyzed 3,323 questions and 59,398 answers from Stack Overflow, combining text analysis and statistical modeling to examine how explanation attributes relate to perceived usefulness (normalized upvotes). Structural and contextual factors, especially explanation length, code inclusion, timing, and author reputation, show small to moderate positive effects. Sentiment polarity has negligible influence, suggesting that clarity and substance outweigh tone in technical communication. This study provides an empirical account of what drives perceived usefulness in developer explanations. It contributes methodological transparency through open data and replication materials, and conceptual insight by relating observed communication patterns to principles of requirements communication. The findings offer evidence-based implications for how developers and RE practitioners can craft clearer and more effective explanations, potentially supporting fairer communication in both open and organizational contexts. From an RE perspective, these determinants can be interpreted as practical signals for ambiguity reduction and rationale articulation in day-to-day requirements communication.

cs.SE↗

How to Elicit Explainability Requirements? A Comparison of Interviews, Focus Groups, and Surveys

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

cs.SE↗

From App Features to Explanation Needs: Analyzing Correlations and Predictive Potential

In today's digitized world, software systems must support users in understanding both how to interact with a system and why certain behaviors occur. This study investigates whether explanation needs, classified from user reviews, can be predicted based on app properties, enabling early consideration during development and large-scale requirements mining. We analyzed a gold standard dataset of 4,495 app reviews enriched with metadata (e.g., app version, ratings, age restriction, in-app purchases). Correlation analyses identified mostly weak associations between app properties and explanation needs, with moderate correlations only for specific features such as app version, number of reviews, and star ratings. Linear regression models showed limited predictive power, with no reliable forecasts across configurations. Validation on a manually labeled dataset of 495 reviews confirmed these findings. Categories such as Security & Privacy and System Behavior showed slightly higher predictive potential, while Interaction and User Interface remained most difficult to predict. Overall, our results highlight that explanation needs are highly context-dependent and cannot be precisely inferred from app metadata alone. Developers and requirements engineers should therefore supplement metadata analysis with direct user feedback to effectively design explainable and user-centered software systems.

cs.SE↗

Automatic Generation of Explainability Requirements and Software Explanations From User Reviews

Explainability has become a crucial non-functional requirement to enhance transparency, build user trust, and ensure regulatory compliance. However, translating explanation needs expressed in user feedback into structured requirements and corresponding explanations remains challenging. While existing methods can identify explanation-related concerns in user reviews, there is no established approach for systematically deriving requirements and generating aligned explanations. To contribute toward addressing this gap, we introduce a tool-supported approach that automates this process. To evaluate its effectiveness, we collaborated with an industrial automation manufacturer to create a dataset of 58 user reviews, each annotated with manually crafted explainability requirements and explanations. Our evaluation shows that while AI-generated requirements often lack relevance and correctness compared to human-created ones, the AI-generated explanations are frequently preferred for their clarity and style. Nonetheless, correctness remains an issue, highlighting the importance of human validation. This work contributes to the advancement of explainability requirements in software systems by (1) introducing an automated approach to derive requirements from user reviews and generate corresponding explanations, (2) providing empirical insights into the strengths and limitations of automatically generated artifacts, and (3) releasing a curated dataset to support future research on the automatic generation of explainability requirements.

cs.SE↗

Towards Trustworthy Sentiment Analysis in Software Engineering: Dataset Characteristics and Tool Selection

Software development relies heavily on text-based communication, making sentiment analysis a valuable tool for understanding team dynamics and supporting trustworthy AI-driven analytics in requirements engineering. However, existing sentiment analysis tools often perform inconsistently across datasets from different platforms, due to variations in communication style and content. In this study, we analyze linguistic and statistical features of 10 developer communication datasets from five platforms and evaluate the performance of 14 sentiment analysis tools. Based on these results, we propose a mapping approach and questionnaire that recommends suitable sentiment analysis tools for new datasets, using their characteristic features as input. Our results show that dataset characteristics can be leveraged to improve tool selection, as platforms differ substantially in both linguistic and statistical properties. While transformer-based models such as SetFit and RoBERTa consistently achieve strong results, tool effectiveness remains context-dependent. Our approach supports researchers and practitioners in selecting trustworthy tools for sentiment analysis in software engineering, while highlighting the need for ongoing evaluation as communication contexts evolve.

cs.SE↗

A German Gold-Standard Dataset for Sentiment Analysis in Software Engineering

Sentiment analysis is an essential technique for investigating the emotional climate within developer teams, contributing to both team productivity and project success. Existing sentiment analysis tools in software engineering primarily rely on English or non-German gold-standard datasets. To address this gap, our work introduces a German dataset of 5,949 unique developer statements, extracted from the German developer forum Android-Hilfe.de. Each statement was annotated with one of six basic emotions, based on the emotion model by Shaver et al., by four German-speaking computer science students. Evaluation of the annotation process showed high interrater agreement and reliability. These results indicate that the dataset is sufficiently valid and robust to support sentiment analysis in the German-speaking software engineering community. Evaluation with existing German sentiment analysis tools confirms the lack of domain-specific solutions for software engineering. We also discuss approaches to optimize annotation and present further use cases for the dataset.

cs.SE↗

Modeling Communication Perception in Development Teams Using Monte Carlo Methods

Software development is a collaborative task involving diverse development teams, where toxic communication can negatively impact team mood and project success. Mood surveys enable the early detection of underlying tensions or dissatisfaction within development teams, allowing communication issues to be addressed before they escalate, fostering a positive and productive work environment. The mood can be surveyed indirectly by analyzing the text-based communication of the team. However, emotional subjectivity leads to varying sentiment interpretations across team members; a statement perceived neutrally by one developer might be seen as problematic by another developer with a different conversational culture. Early identification of perception volatility can help prevent misunderstandings and enhance team morale while safeguarding the project. This paper analyzes the diversity of perceptions within arbitrary development teams and determines how many team members should report their sentiment to accurately reflect the team's mood. Through a Monte Carlo experiment involving 45 developers, we present a preliminary mathematical model to calculate the minimum agreement among a subset of developers based on the whole team's agreement. This model can guide leadership in mood assessment, demonstrating that omitting even a single member in an average-sized 7-member team can misrepresent the overall mood. Therefore, including all developers in mood surveying is recommended to ensure a reliable evaluation of the team's mood.

cs.SE↗

Sentiment Analysis Tools in Software Engineering: A Systematic Mapping Study

Software development is a collaborative task. Previous research has shown social aspects within development teams to be highly relevant for the success of software projects. A team's mood has been proven to be particularly important. It is paramount for project managers to be aware of negative moods within their teams, as such awareness enables them to intervene. Sentiment analysis tools offer a way to determine the mood of a team based on textual communication. We aim to help developers or stakeholders in their choice of sentiment analysis tools for their specific purpose. Therefore, we conducted a systematic mapping study (SMS). We present the results of our SMS of sentiment analysis tools developed for or applied in the context of software engineering (SE). Our results summarize insights from 106 papers with respect to (1) the application domain, (2) the purpose, (3) the used data sets, (4) the approaches for developing sentiment analysis tools, (5) the usage of already existing tools, and (6) the difficulties researchers face. We analyzed in more detail which tools and approaches perform how in terms of their performance. According to our results, sentiment analysis is frequently applied to open-source software projects, and most approaches are neural networks or support-vector machines. The best performing approach in our analysis is neural networks and the best tool is BERT. Despite the frequent use of sentiment analysis in SE, there are open issues, e.g. regarding the identification of irony or sarcasm, pointing to future research directions. We conducted an SMS to gain an overview of the current state of sentiment analysis in order to help developers or stakeholders in this matter. Our results include interesting findings e.g. on the used tools and their difficulties. We present several suggestions on how to solve these identified problems.

cs.SE↗

On the Limitations of Combining Sentiment Analysis Tools in a Cross-Platform Setting

A positive working climate is essential in modern software development. It enhances productivity since a satisfied developer tends to deliver better results. Sentiment analysis tools are a means to analyze and classify textual communication between developers according to the polarity of the statements. Most of these tools deliver promising results when used with test data from the domain they are developed for (e.g., GitHub). But the tools' outcomes lack reliability when used in a different domain (e.g., Stack Overflow). One possible way to mitigate this problem is to combine different tools trained in different domains. In this paper, we analyze a combination of three sentiment analysis tools in a voting classifier according to their reliability and performance. The tools are trained and evaluated using five already existing polarity data sets (e.g. from GitHub). The results indicate that this kind of combination of tools is a good choice in the within-platform setting. However, a majority vote does not necessarily lead to better results when applying in cross-platform domains. In most cases, the best individual tool in the ensemble is preferable. This is mainly due to the often large difference in performance of the individual tools, even on the same data set. However, this may also be due to the different annotated data sets.

cs.SE↗

Do Users' Explainability Needs in Software Change with Mood?

Context and Motivation: The increasing complexity of modern software systems often challenges users' abilities to interact with them. Taking established quality attributes such as usability and transparency into account can mitigate this problem, but often do not suffice to completely solve it. Recently, explainability has emerged as essential non-functional requirement to help overcome the aforementioned difficulties. Question/problem: User preferences regarding the integration of explanations in software differ. Neither too few nor too many explanations are helpful. In this paper, we investigate the influence of a user's subjective mood and objective demographic aspects on explanation needs by means of frequency and type of explanation. Principal ideas/results: Our results reveal a limited relationship between these factors and explanation needs. Two significant correlations were identified: Emotional reactivity was positively correlated with the need for UI explanations, while a negative correlation was found between age and user interface needs. Contribution: As we only find very few significant aspects that influence the need for explanations, we conclude that the need for explanations is very subjective and does only partially depend on objective factors. These findings emphasize the necessity for software companies to actively gather user-specific explainability requirements to address diverse and context-dependent user demands. Nevertheless, future research should explore additional personal traits and cross-cultural factors to inform the development of adaptive, user-centered explanation systems.

cs.SE↗

How Does Users' App Knowledge Influence the Preferred Level of Detail and Format of Software Explanations?

Context and Motivation: Due to their increasing complexity, everyday software systems are becoming increasingly opaque for users. A frequently adopted method to address this difficulty is explainability, which aims to make systems more understandable and usable. Question/problem: However, explanations can also lead to unnecessary cognitive load. Therefore, adapting explanations to the actual needs of a user is a frequently faced challenge. Principal ideas/results: This study investigates factors influencing users' preferred the level of detail and the form of an explanation (e.g., short text or video tutorial) in software. We conducted an online survey with 58 participants to explore relationships between demographics, software usage, app-specific knowledge, as well as their preferred explanation form and level of detail. The results indicate that users prefer moderately detailed explanations in short text formats. Correlation analyses revealed no relationship between app-specific knowledge and the preferred level of detail of an explanation, but an influence of demographic aspects (like gender) on app-specific knowledge and its impact on application confidence were observed, pointing to a possible mediated relationship between knowledge and preferences for explanations. Contribution: Our results show that explanation preferences are weakly influenced by app-specific knowledge but shaped by demographic and psychological factors, supporting the development of adaptive explanation systems tailored to user expertise. These findings support requirements analysis processes by highlighting important factors that should be considered in user-centered methods such as personas.

cs.SE↗

Diversity is Key: Fantasy football dream teams under budget constraints

Given a fixed budget for player salaries, what is the distribution of salaries of the top scoring teams? We investigated this question using the wealth of data available from fantasy premier league football (soccer). Using the players' data from past seasons, for several seasons and several different budget constraints, we identified the highest scoring fantasy team for each season subject to each budget constraint. We then investigated quantifiable characteristics of these teams. Interestingly, across nearly every variable that is significant to the game of football and the budget, these top teams display diversity across these variables. Furthermore, randomly assembled teams would statistically \em not \em display such diversity across these variables. Our results indicate that diversity across these variables, including salaries, is a general feature of top performing teams. Moreover, in the process of obtaining these results we developed a data cleaning (or data reduction) algorithm that drastically reduced the amount of data to be analyzed.

physics.soc-ph↗

Human Factors in Model-Driven Engineering: Future Research Goals and Initiatives for MDE

Purpose: Software modelling and Model-Driven Engineering (MDE) is traditionally studied from a technical perspective. However, one of the core motivations behind the use of software models is inherently human-centred. Models aim to enable practitioners to communicate about software designs, make software understandable, or make software easier to write through domain-specific modelling languages. Several recent studies challenge the idea that these aims can always be reached and indicate that human factors play a role in the success of MDE. However, there is an under-representation of research focusing on human factors in modelling. Methods: During a GI-Dagstuhl seminar, topics related to human factors in modelling were discussed by 26 expert participants from research and industry. Results: In breakout groups, five topics were covered in depth, namely modelling human aspects, factors of modeller experience, diversity and inclusion in MDE, collaboration and MDE, and teaching human-aware MDE. Conclusion: We summarise our insights gained during the discussions on the five topics. We formulate research goals, questions, and propositions that support directing future initiatives towards an MDE community that is aware of and supportive of human factors and values.

cs.SE↗

Divide and Conquer the EmpiRE: A Community-Maintainable Knowledge Graph of Empirical Research in Requirements Engineering

[Background.] Empirical research in requirements engineering (RE) is a constantly evolving topic, with a growing number of publications. Several papers address this topic using literature reviews to provide a snapshot of its "current" state and evolution. However, these papers have never built on or updated earlier ones, resulting in overlap and redundancy. The underlying problem is the unavailability of data from earlier works. Researchers need technical infrastructures to conduct sustainable literature reviews. [Aims.] We examine the use of the Open Research Knowledge Graph (ORKG) as such an infrastructure to build and publish an initial Knowledge Graph of Empirical research in RE (KG-EmpiRE) whose data is openly available. Our long-term goal is to continuously maintain KG-EmpiRE with the research community to synthesize a comprehensive, up-to-date, and long-term available overview of the state and evolution of empirical research in RE. [Method.] We conduct a literature review using the ORKG to build and publish KG-EmpiRE which we evaluate against competency questions derived from a published vision of empirical research in software (requirements) engineering for 2020 - 2025. [Results.] From 570 papers of the IEEE International Requirements Engineering Conference (2000 - 2022), we extract and analyze data on the reported empirical research and answer 16 out of 77 competency questions. These answers show a positive development towards the vision, but also the need for future improvements. [Conclusions.] The ORKG is a ready-to-use and advanced infrastructure to organize data from literature reviews as knowledge graphs. The resulting knowledge graphs make the data openly available and maintainable by research communities, enabling sustainable literature reviews.

cs.SE↗

On the Subjectivity of Emotions in Software Projects: How Reliable are Pre-Labeled Data Sets for Sentiment Analysis?

Social aspects of software projects become increasingly important for research and practice. Different approaches analyze the sentiment of a development team, ranging from simply asking the team to so-called sentiment analysis on text-based communication. These sentiment analysis tools are trained using pre-labeled data sets from different sources, including GitHub and Stack Overflow. In this paper, we investigate if the labels of the statements in the data sets coincide with the perception of potential members of a software project team. Based on an international survey, we compare the median perception of 94 participants with the pre-labeled data sets as well as every single participant's agreement with the predefined labels. Our results point to three remarkable findings: (1) Although the median values coincide with the predefined labels of the data sets in 62.5% of the cases, we observe a huge difference between the single participant's ratings and the labels; (2) there is not a single participant who totally agrees with the predefined labels; and (3) the data set whose labels are based on guidelines performs better than the ad hoc labeled data set.

cs.SE↗

Meetings and Mood -- Related or Not? Insights from Student Software Projects

Background: Teamwork, coordination, and communication are a prerequisite for the timely completion of a software project. Meetings as a facilitator for coordination and communication are an established medium for information exchange. Analyses of meetings in software projects have shown that certain interactions in these meetings, such as proactive statements followed by supportive ones, influence the mood and motivation of a team, which in turn affects its productivity. So far, however, research has focused only on certain interactions at a detailed level, requiring a complex and fine-grained analysis of a meeting itself. Aim: In this paper, we investigate meetings from a more abstract perspective, focusing on the polarity of the statements, i.e., whether they appear to be positive, negative, or neutral. Method: We analyze the relationship between the polarity of statements in meetings and different social aspects, including conflicts as well as the mood before and after a meeting. Results: Our results emerge from 21 student software project meetings and show some interesting insights: (1) Positive mood before a meeting is both related to the amount of positive statements in the beginning, as well as throughout the whole meeting, (2) negative mood before the meeting only influences the amount of negative statements in the first quarter of the meeting, but not the whole meeting, and (3) the amount of positive and negative statements during the meeting has no influence on the mood afterwards. Conclusions: We conclude that the behaviour in meetings might rather influence short-term emotional states (feelings) than long-term emotional states (mood), which are more important for the project.

cs.SE↗

SEnti-Analyzer: Joint Sentiment Analysis For Text-Based and Verbal Communication in Software Projects

Social aspects in software development teams are of particular importance for a successful project closure. To analyze sentiments in software projects, there are several tools and approaches available. These tools analyze text-based communication based on the used words to predict whether they appear to be positive, negative, or neutral for the receiver of the message. In the research project ComContA, we investigate so-called sentiment analysis striving to analyze the content of text-based communication in development teams with regard to the statement's polarity. That is, we analyze whether the communication appears to be adequate (i.e., positive or neutral) or negative. In a workshop paper, we presented a tool called SEnti-Analyzer that allows to apply sentiment analysis to verbal communication in meetings of software projects. In this technical report, we present the extended functionalities of the SEnti-Analyzer by also allowing the analysis of text-based communication, we improve the prediction of the tool by including established sentiment analysis tools, and we evaluate the tool with respect to its accuracy. We evaluate the tool by comparing the prediction of the SEnti-Analyzer to pre-labeled established data sets used for sentiment analysis in software engineering and to perceptions of computer scientists. Our results indicate that in almost all cases at least two of the three votes coincide, but in only about half of the cases all three votes coincide. Our results raise the question of the "ultimate truth" of sentiment analysis outcomes: What do we want to predict with sentiment analysis tools? The pre-defined labels of established data sets? The perception of computer scientists? Or the perception of single computer scientists which appears to be the most meaningful objective?

cs.SE↗