Demo Data from EDBT 2026 / reviewers in the wild / expert
Eya Ben Charrada
dblp:23/8943
· DBLP profile ↗
7ranked-venue papers
4as first author
1since 2021 · last 2024
0000-0003-4251-9428ORCID · corroborated
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 6 · 3 first-author · 1 since 2021Databases, data management, data science and information retrieval · 1 · 1 first-author
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Software engineering, system software, and programming languages
1 paper |
Requirements engineering and software design · 50% Software maintenance and evolution · 50% |
Topics — the 1 heaviest of 2, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Requirements engineering and software design › requirements management
requirements evolution |
0.1 | 1 | 2010 | Updating requirements from tests during maintenance and evolution · SIGSOFT FSE 2010 |
Methods — techniques the papers use, named apart from their topics
test-based requirement inference · 0.1
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2024 | Debugging with Open-Source Large Language Models: An EvaluationabstractLarge language models have shown good potential in supporting software development tasks. This is why more and more developers turn to LLMs (e.g. ChatGPT) to support them in fixing their buggy code. While this can save time and effort, many companies prohibit it due to strict code sharing policies. To address this, companies can run open-source LLMs locally. But until now there is not much research evaluating the performance of open-source large language models in debugging. This work is a preliminary evaluation of the capabilities of open-source LLMs in fixing buggy code. The evaluation covers five open-source large language models and uses the benchmark DebugBench which includes more than 4000 buggy code instances written in Python, Java and C++. Open-source LLMs achieved scores ranging from 43.9% to 66.6% with DeepSeek-Coder achieving the best score for all three programming languages. Yacine Majdoub, Eya Ben Charrada |
ESEM | 2 |
| 2018 | Keeping Evolving Requirements and Acceptance Tests Aligned with Automatically Generated Guidance
Sofija Hotomski, Eya Ben Charrada, Martin Glinz |
REFSQ | 2 |
| 2016 | An Exploratory Study on Managing and Searching for Documents in Software Engineering EnvironmentsabstractA large number of documents are usually produced in the software industry. In this work, we conduct a qualitative study to explore the main practices and challenges related to managing these documents. The results of this study are based on interviews with 13 practitioners from nine companies. The main findings of the study are: (1) much data is stored in e-mails and in meeting protocols, (2) practitioners like wikis, (3) when searching for documents, practitioners would rather browse the structure than use the search function and (4) searching for documents is still a challenge due to the low effectiveness of search functions and the scattering of documents over several locations and tools. Eya Ben Charrada, Stefan Mussato |
DocEng | 1 |
| 2016 | An Exploratory Study on Handling Requirements and Acceptance Test Documentation in IndustryabstractWith the emergence and spread of agile processes, the practices of writing and maintaining documentation have drastically changed in the last decade. In this work, we performed a qualitative study to explore the current practices for managing two related types of software documentation: requirements and acceptance tests. We interviewed twenty practitioners from seventeen business units in fifteen companies to investigate the companies' practices for writing, maintaining and linking requirements and acceptance test documentation. The study yields interesting and partially unexpected results. For example, we had expected that tests would be more extensively documented than requirements, while we found a strong linear correlation between the number of requirements and tests in our sample. We also found that technical people are usually not involved in the requirements engineering activities, which often results in misunderstood or underestimated requirements. Acceptance tests are written, in many cases, based on requirements that are not necessarily detailed enough. Also, acceptance tests are not regularly maintained, which occasionally results in confusing features and bugs. Sofija Hotomski, Eya Ben Charrada, Martin Glinz |
RE | 2 |
| 2015 | Supporting requirements update during software evolutionabstractSummary Updating the requirements specification when software systems evolve is a manual task that is expensive and time consuming. Therefore, maintainers usually apply the changes to the code directly and leave the requirements unchanged. This results in the requirements rapidly becoming obsolete and useless. In this paper, we propose an approach that supports the maintainer in keeping the requirements specification consistent with the implementation, by identifying the requirements that are impacted whenever the code is changed. Our approach works as follows. First, we analyze the changes that have been applied to the source code and detect if they are likely to impact the requirements or not. Second, we trace the requirements‐impacting changes back to the requirements specification to identify the parts that might need to be modified. The output of the tracing is a list of requirements that are sorted according to their likelihood of being impacted. Automatically identifying the parts of the requirements specification that are likely to need maintenance reduces the effort needed for keeping the requirements up‐to‐date and thus makes the task of the maintainer easier. When applying our approach in three cases studies, 70% to 100% of the impacted requirements were identified within a list that includes less than 20% of the total number of requirements in the specification. Copyright © 2015 John Wiley & Sons, Ltd. Eya Ben Charrada, Anne Koziolek, Martin Glinz |
J. Softw. Evol. Process. | 1 |
| 2012 | Identifying outdated requirements based on source code changesabstractKeeping requirements specifications up-to-date when systems evolve is a manual and expensive task. Software engineers have to go through the whole requirements document and look for the requirements that are affected by a change. Consequently, engineers usually apply changes to the implementation directly and leave requirements unchanged. In this paper, we propose an approach for automatically detecting outdated requirements based on changes in the code. Our approach first identifies the changes in the code that are likely to affect requirements. Then it extracts a set of keywords describing the changes. These keywords are traced to the requirements specification, using an existing automated traceability tool, to identify affected requirements. Automatically identifying outdated requirements reduces the effort and time needed for the maintenance of requirements specifications significantly and thus helps preserve the knowledge contained in them. We evaluated our approach in a case study where we analyzed two consecutive source code versions and were able to detect 12 requirements-related changes out of 14 with a precision of 79%. Then we traced a set of keywords we extracted from these changes to the requirements specification. In comparison to simply tracing changed classes to requirements, we got better results in most cases. Eya Ben Charrada, Anne Koziolek, Martin Glinz |
RE | 1 |
| 2010 | Updating requirements from tests during maintenance and evolutionabstractKeeping requirements specification up-to-date during the evolution of a software system is an expensive task. Consequently, specifications are usually not updated and rapidly become obsolete and unreliable. The goal of our research is to preserve the alignment between requirements and the implementation by supporting the maintenance of the specification. In this proposal, we explore the idea of using tests to automatically generate hints about the evolution of requirements. We discuss the main research questions that need to be addressed, and propose ideas to approach them. Eya Ben Charrada |
SIGSOFT FSE | 1 |