Explore the vast range of titles available.

Research has repeatedly shown that high-quality requirements are essential for the success of development projects. While the term “quality” is pervasive in the field of requirements engineering and while the body of research on requirements quality is large, there is no meta-study of the field that overviews and compares the concrete quality attributes addressed by the community. To fill this knowledge gap, we conducted a systematic mapping study of the scientific literature. We retrieved 6905 articles from six academic databases, which we filtered down to 105 relevant primary studies. The primary studies use empirical research to explicitly define, improve, or evaluate requirements quality. We found that empirical research on requirements quality focuses on improvement techniques, with very few primary studies addressing evidence-based definitions and evaluations of quality attributes. Among the 12 quality attributes identified, the most prominent in the field are ambiguity, completeness, consistency, and correctness. We identified 111 sub-types of quality attributes such as “template conformance” for consistency or “passive voice” for ambiguity. Ambiguity has the largest share of these sub-types. The artefacts being studied are mostly referred to in the broadest sense as “requirements”, while little research targets quality attributes in specific types of requirements such as use cases or user stories. Our findings highlight the need to conduct more empirically grounded research defining requirements quality, using more varied research methods, and addressing a more diverse set of requirements types.

High-quality requirements minimize the risk of propagating defects to later stages of the software development life cycle. Achieving a sufficient level of quality is a major goal of requirements engineering. This requires a clear definition and understanding of requirements quality. Though recent publications make an effort at disentangling the complex concept of quality, the requirements quality research community lacks identity and clear structure which guides advances and puts new findings into an holistic perspective. In this research commentary, we contribute (1) a harmonized requirements quality theory organizing its core concepts, (2) an evaluation of the current state of requirements quality research, and (3) a research roadmap to guide advancements in the field. We show that requirements quality research focuses on normative rules and mostly fails to connect requirements quality to its impact on subsequent software development activities, impeding the relevance of the research. Adherence to the proposed requirements quality theory and following the outlined roadmap will be a step toward amending this gap.

It is commonly accepted that the quality of requirements specifications impacts subsequent software engineering activities. However, we still lack empirical evidence to support organizations in deciding whether their requirements are good enough or impede subsequent activities. We aim to contribute empirical evidence to the effect that requirements quality defects have on a software engineering activity that depends on this requirement. We conduct a controlled experiment in which 25 participants from industry and university generate domain models from four natural language requirements containing different quality defects. We evaluate the resulting models using both frequentist and Bayesian data analysis. Contrary to our expectations, our results show that the use of passive voice only has a minor impact on the resulting domain models. The use of ambiguous pronouns, however, shows a strong effect on various properties of the resulting domain models. Most notably, ambiguous pronouns lead to incorrect associations in domain models. Despite being equally advised against by literature and frequentist methods, the Bayesian data analysis shows that the two investigated quality defects have vastly different impacts on software engineering activities and, hence, deserve different levels of attention. Our employed method can be further utilized by researchers to improve reliable, detailed empirical evidence on requirements quality.

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. If insufficient attention is given to support issues, however, their escalation to management becomes time-consuming and expensive, especially for large organizations managing hundreds of customers and thousands of support tickets. Our work provides a step toward 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 research methodology to characterize the support process and data available to IBM analysts in managing escalations. In a design science methodology, we used feature engineering to translate our understanding of support analysts’ expert knowledge of their customers into features of a support ticket model. We then implemented these features 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 87.36% and an 88.23% 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. Finally, in addition to these research evaluation activities, we compared the performance of our support ticket model with that of a model developed with no feature engineering; the support ticket model features outperformed the non-engineered model. The artifacts created in this research are designed to serve as a starting place for organizations interested in predicting support ticket escalations, and for future researchers to build on to advance research in escalation prediction.

The original version of this article contains an error in the Acknowledgements section. The correct text should read as follows.

Issue Tracking Systems (ITSs), such as GitHub and Jira, are popular tools that support Software Engineering (SE) organisations through the management of ``issues'', which represent different SE artefacts such as requirements, development tasks, and maintenance items. ITSs also support internal linking between issues, and external linking to other tools and information sources. This provides SE organisations key forms of documentation, including forwards and backwards traceability (e.g., Feature Requests linked to sprint releases and code commits linked to Bug Reports). An Issue Tracking Ecosystem (ITE) is the aggregate of the central ITS and the related SE artefacts, stakeholders, and processes -- with an emphasis on how these contextual factors interact with the ITS. The quality of ITEs is central to the success of these organisations and their software products. There are challenges, however, within ITEs, including complex networks of interlinked artefacts and diverse workflows. While ITSs have been the subject of study in SE research for decades, ITEs as a whole need further exploration. In this thesis, I undertake the challenge of understanding ITEs at a broader level, addressing these questions regarding complexity and diversity. I interviewed practitioners and performed archival analysis on a diverse set of ITSs. These analyses revealed the context-dependent nature of ITE problems, highlighting the need for context-specific ITE research. While previous work has produced many solutions to specific ITS problems, these solutions are not consistently framed in a context-rich and comparable way, leading to a desire for more aligned solutions across research and practice. To address this emergent information and lack of alignment, I created the Best Practice Ontology for ITEs. <... truncated due to arXiv abstract character limit ...>

Color image demosaicing is an ill-posed inverse problem that arises in the formation of digital color images. By designing a demosaicing algorithm that operates on sequences of mosaiced video frames instead of isolated mosaiced images, one might hope to achieve a higher quality reconstruction. We propose two different deep convolutional networks for demosaicing that demonstrate the ability to effectively exploit temporal context frames in producing superior reconstructions as compared to single-frame networks. The first network explicitly registers frames using a computed optical flow; the second network adapts a recurrent back-projection architecture originally proposed for video super-resolution. Additionally, we show that single-frame demosaicing networks benefit from dense residual connections. Our contributions are supplemented with a review of the theory of proximal operators, image processing, neural networks, and demosaicing.

A well-rounded software engineer is often defined by technical prowess and the ability to deliver on complex projects. However, the narrative around the ideal Software Engineering (SE) candidate is evolving, suggesting that there is more to the story. This article explores the non-technical aspects emphasized in SE job postings, revealing the sociotechnical and organizational expectations of employers. Our Thematic Analysis of 100 job postings shows that employers seek candidates who align with their sense of purpose, fit within company culture, pursue personal and career growth, and excel in interpersonal interactions. This study contributes to ongoing discussions in the SE community about the evolving role and workplace context of software engineers beyond technical skills. By highlighting these expectations, we provide relevant insights for researchers, educators, practitioners, and recruiters. Additionally, our analysis offers a valuable snapshot of SE job postings in 2023, providing a scientific record of prevailing trends and expectations.

Issue Tracking Systems (ITSs) enable software developers and managers to collect and resolve issues collaboratively. While researchers have extensively analysed ITS data to automate or assist specific activities such as issue assignments, duplicate detection, or priority prediction, developer studies on ITSs remain rare. Particularly, little is known about the challenges Software Engineering (SE) teams encounter in ITSs and when certain practices and workarounds (such as leaving issue fields like \"priority\" empty) are considered problematic. To fill this gap, we conducted an in-depth interview study with 26 experienced SE practitioners from different organisations and industries. We asked them about general problems encountered, as well as the relevance of 31 ITS smells (aka potentially problematic practices) discussed in the literature. By applying Thematic Analysis to the interview notes, we identified 14 common problems including issue findability, zombie issues, workflow bloat, and lack of workflow enforcement. Participants also stated that many of the ITS smells do not occur or are not problematic. Our results suggest that ITS problems and smells are highly dependent on context factors such as ITS configuration, workflow stage, and team size. We also discuss potential tooling solutions to configure, monitor, and visualise ITS smells to cope with these challenges.