When Stakeholder-centric Requirements Engineering is Not Enough: An Action Research Study on Legacy System Modernisation

When Stakeholder-centric Requirements Engineering is Not Enough: An Action Research Study on Legacy System Modernisation

arXiv:2609.07340v1 [cs.SE] 7 Sep 2026

Ruward S. Karper∗ , Damian A. Tamburri∗† , Alessio Ferrari‡§ , Willem-Jan van den Heuvel¶ ∗ Jheronimus Academy of Data Science, DA ’s-Hertogenbosch, the Netherlands † TU Eindhoven, Eindhoven, the Netherlands ‡ University College Dublin, Dublin, Ireland § CNR-ISTI, Pisa, Italy ¶ University of Tilburg, Tilburg, the Netherlands

on system re-implementation (e.g., changing programming languages while keeping architecture and functionality [12]), on cost assessment of modernisation decisions [13], and on model-based support for reverse engineering. Overall, most strategies proposed in the literature approach modernisation primarily as a technical endeavour, usually motivated by the need to lower operational costs while improving interoperability and supporting better performance at scale [14]. However, when considering the practitioner’s viewpoint [15], the challenges experienced by professionals include a large portion of human-related issues. These include prioritisation difficulties, resistance from members of the organisation, as well as soft factors such as perspective misalignment between stakeholders. Some studies have therefore started to frame modernisation explicitly as a socio-technical process, in which knowledge and goals play a central role [16]. This suggests that legacy system modernisation extends beyond architecture and refactoring to include a substantial requirements engineering (RE) dimension. Before introducing a technological transformation, organisations need to determine and agree on what the future system should do, what the current system already provides, and which existing functionality should be retained, adapted, or replaced [16]. Despite the recognised relevance of RE for legacy system modernisation, limited studies exist I. I NTRODUCTION that consider RE approaches to support this common industrial A legacy system is a business-critical system with high endevour. This paper aims to address this gap through an action economic value that becomes increasingly difficult to maintain, research study conducted in a multinational company, where RE owing to ageing technology, deteriorating documentation, and techniques have been applied to guide system modernisation. declining organisational expertise [1]. According to Seacord et Within RE, stakeholders are commonly approached as the al. [2], legacy system modernisation concerns the evolution of primary repositories of domain and system information [17], a legacy system when conventional maintenance and enhance- [18]. Accordingly, RE practice and research have long priment can no longer achieve the desired system properties, and oritized stakeholder-centric approaches, such as interviews, substantial renewal is required. Modernisation is a long standing focus groups, and workshops [19]. In software modernisation challenge in software engineering, with solution proposal start- projects, this emphasis naturally suggests an initial working ing already in the nineties. Early work addressed this problem assumption: if stakeholder knowledge and needs can be elicited through reverse engineering, restoration, and step-wise replace- and consolidated effectively, it should be possible to derive ment strategies [3]–[6], while more recent work has focused on high-quality requirements for the system-to-be and use them cloud migration and the decomposition of monolithic systems as a basis for comparing it with the system-as-is. This paper into microservices [7]–[11]. Industrial case studies focused examines that assumption in the context of a multinational

Abstract—Legacy system modernisation is a major challenge in digital transformation, especially when organisations depend on long-lived, business-critical systems that are only partly understood. In such context, organisations must define future needs while determining what current systems actually do and which functions to retain, adapt, or replace. Modernisation is therefore not only a technical challenge but also a requirements engineering (RE) problem, shaped by stakeholder perspectives. This study examines how far stakeholder-centric RE can support gap analysis between the system-as-is and the system-to-be in a legacy modernisation context. We conducted an action research study in a multinational energy company engaged in system modernisation. In the study, we applied stakeholder-centric RE practices, including stakeholder identification, semi-structured elicitation interviews, agreement-building through the Delphi method, and prioritisation with the MoSCoW method. The results show that this process was effective in producing requirements stakeholders generally viewed as understandable and correct, but less effective in achieving agreement on how elicited requirements mapped to legacy system functionality. The findings suggest that stakeholder-centric RE is necessary but not sufficient, pointing to the need for uncertainty-aware, iterative, and evidence-based modernisation practices that combine stakeholder perspectives with manual and tool-assisted analysis of legacy systems. Index Terms—System Modernisation, System Renewal, Legacy Problem, Requirements Engineering, Software Engineering, Legacy Applications

energy company that must renew a legacy application used to II. R ELATED W ORK analyze emissions data and produce statistics for sustainability Legacy system modernisation has long been recognised as analysis and external audits. The setting is characterised by mula central problem in software engineering [14]. The studies tiple related systems deployed across different nations, which in the area can be roughly partitioned into the following introduces heterogeneity and complicates the consolidation of categories: traditional studies focusing on reverse engineering system knowledge. In this context, we conducted an action and restoration [3], [5], [6]; works considering cloud migration, research study [20] to assess whether stakeholder-centric RE in particular through the decomposition of monolithic systems practices can produce high-quality requirements for the target into microservices [9]–[11]; industrial case studies [12], [13]; system and, in turn, whether these requirements provide a and surveys, including literaure reviews and interviews with defensible basis for gap analysis against the capabilities of practitioners [14], [15]. In the following, we summarise relevant the original system, with the final goal of identifying reuse contributions in the different areas. opportunities and missing functionality. a) Reverse engineering and restoration: Among early Methodologically, we select and apply a set of stakeholderwork on modernisation, Visaggio reported that comprehending centric RE techniques, including semi-structured requirements and restoring an ageing system can simplify structure and elicitation inteviews, the Delphi consensus-making technique improve maintainability, and later discussed symptoms and [21], and the MoScoW method for requirements prioritisaremedies for ageing in data-intensive systems [3], [4]. Battaglia tion [22]. The resulting requirements describing the system-toet al. introduced the “renaissance method”, separating an initial be were assessed as high quality by the stakeholders, in terms decision of what to do (renewal decisions) from how to do of understandability and correctness, i.e., relevance. However, it (evolving selected legacy features), and iterating between when these requirements were subsequently used to determine these concerns [5]. Later works focused on the transition which ones were actually implemented in the legacy system, substantial disagreement emerged among stakeholders, pointing problem, i.e., introducting strategies that enable coexistence and incremental replacement, as the legacy systems embed to fragmented understanding of the existing system. essential business logic and cannot be replaced abruptly. Among These findings suggest that, while stakeholder-centric RE, as them, Hasselbring et al. propose the Dublo Pattern, which applied in this study, can yield a high-quality specification of connects legacy business logic to a new tier to enable stepthe intended system, the same artifacts may be insufficient to wise replacement while sustaining operations [6]. While these establish a shared, verifiable account of the baseline in complex early contributions testify to the long-standing nature of system legacy modernisation contexts. The observed phenomenon modernisation, and provide foundational ideas and paradigms, points to the limits of relying on stakeholder viewpoints alone they introduce limited process guidance for contemporary largeand motivate the need to complement human- and processscale renewals. centered RE with more explicit technical grounding. This b) Cloud Migration and Microservices: Cloud migration, primarily includes software analytics capabilities that can also known as cloudification, is the most common approach for triangulate stakeholder accounts with evidence extracted from system modernisation [14], and it has been addressed through the system itself, since documentation is often scarce and much a variety of frameworks in the literature [23].These frameworks of the relevant knowledge remains embedded in the legacy mostly focus on the technical restructuring needed to move system. legacy systems to the cloud. For example, Grieger et al. [7] start Overall, while the legacy system literature focuses on from conceptual modelling of the existing system and analyse technical aspects alone, and RE research mainly targets the migration patterns and strategies for individual components, human dimension, an integrated perspective is missing. RE while Marquez et al. [8], with a focus on security, use researchers should work more closely with the mining software automated tools to derive higher-level models and requirements repositories and software architecture communities, to devise from code and technical documentation, before selecting a joint strategies to tackle the socio-technical nature of the legacy cloud architecture. Still in the area of cloudification, one of system modernisation problem. the main trend is the decomposition of monolithic systems Based on our findings and conclusions, the contributions of into microservices [14]. Fritzsch et al. [9] review refactoring approaches in the field, highlighting the context-dependent this paper are as follows: nature of the solutions, and providing a decision support scheme • Case-based evidence about the effectiveness of to select the most appropriate one based on the problem at stakeholder-centric RE techniques in producing high- hand. Wolfart et al. [10] propose a roadmap for modernising quality requirements in a legacy system modernisation legacy systems with microservices, outlining a generic process context; to guide cloudification, which starts from the analysis of the • Case-based evidence about the insufficiency of RE prac- limitations of the legacy system, and arrives to the deployment tices in producing requirements that can be effective to and monitoring phase. Mohottige et al. [11] provide a recent support strong conclusions on reuse potential; state-of-the-art review of methods, techniques and tools, for • A set of lessons learned and reflections triggered by the reengineering software systems into microservices, showing experience. a strong emphasis on artifact-driven, static analysis solutions.

Complementing these views, Carvalho et al. [24] report a survey and the subsequent realisation of the migration. In this way, with practitioners to identify the criteria used in practice to deal Khadka et al. make explicit that modernisation is not merely with modularity and feature variability when re-engineering an architectural transformation problem, but a socio-technical legacy systems as microservices. endeavour in which technical decisions are closely intertwined c) Industrial Case Studies: Given the relevance of the with stakeholder participation and the continuous elicitation of legacy system modernisation problem for practice, some of organisational knowledge. the works consider industrial case studies and experience e) Research Gap: Most of the previous work treat reports. Sneed and Verhoef [12] supports re-implementation as modernisation mainly as a system architecture or refactoring a practical strategy between direct conversion and complete problem, typically neglecting the RE dimension in general and redevelopment, preserving the functional architecture of the the relevance of stakeholders in particular. The only exception legacy system while replacing its technical implementation is the case study by Khadka et al. [16], where stakeholders (e.g., replacing COBOL with Java). The paper describes two have a prominent role. However, the paper mainly focuses on re-implementation case studies, observing that, while code lessons learned, failing to provide detailed reproducible steps, quality improved, complexity of the code also increased. In a and, although the approach is in line with the RE spirit (e.g., financial-services case study, Crotty and Horrocks [13] develops involve stakeholders, goals before solutions, plan before acting), a meta-assessment model to analyse the costs of maintaining it does not appear to follow structured RE practices. Overall, legacy systems and to support managerial decision making despite the relevance of the RE dimension in legacy system about modernisation. The authors apply the approach to FinCo, modernisation, studies that address this problem explicitly from a large UK financial services company, receiving confirmation an RE perspective remain scarce. of the utility of the method. García-Borgoñón et al. [25] present f) Contribution: Compared to previous work, our contrilessons learned from applying model-based reverse engineering bution investigates whether following stakeholder-centric RE to large industrial legacy systems, focusing on how legacy approaches from the literature can facilitate the process of knowledge can be reconstructed from existing artefacts before legacy system modernisation. In addition, this study shows further modernisation steps are planned. They conclude that that, while the RE practices as applied in this modernisation the applied method brings an average saving of 75% of the process produced high-quality requirements, they were not effort needed to understand how a legacy system is built and sufficient to support a reliable comparison between the legacy technological debt analysis, and 99% cost improvement in system and the target system. terms of producing documentation, compared to traditional III. R ESEARCH D ESIGN approaches. The overarching goal of this study is to understand the d) Surveys: Assunção et al. [14] provide a recent literature review on system modernisation, identifying drivers and extent to which, established stakeholder-centric RE practices, challenges. The paper highlights that most of the published can support legacy system modernisation in a large (5000+ works focus on reducing operational costs, and that tool employees) multinational company active in the energy and support is the main challenge recognised by the studies. power services sector. To address this goal, we followed the Interestingly, challenges associated with RE and stakeholders action research steps described by Staron [20]. Accordingly, are not prominent in the surveyed literature. On the other the study encompasses a constant presence of industrial hand, the socio-technical dimension appears to be slightly stakeholders embedded in the phases below: more present in the multi-vocal literature review by Hogan • Diagnosis: the goal of this phase is to understand the et al. [26], which remarks that one of the main challenges problem context and identify the underlying challenges. In resides in integrating the novel system with the existing process, our case, <anonymous company> contacted the authors which includes tasks and stakeholders. The broader sociowith the aim of modernizing their reporting system. To technical framing is instead strongly present in the survey with capture and scaffold the problem, informal meetings were practitioners by Khadka al. [15]. This highlights that the main held with company representatives in the first weeks of challenges of system modernisation include the fragmented collaboration. The problem unfolded as a stakeholderexpertise and lack of knowledge, the difficulty in understanding centered RE problem, where (i) stakeholder identification, the business logic and rationale of the legacy system, and requirements elicitation as well as specification were “soft” modernisation factors, including communication issues required to understand the requirements for the novel between the management and the technical teams, thus posing system, and (ii) gap analysis1 was needed to understand stakeholders at the center of the modernisation problem. A which features of the legacy system could be reused concrete example of this perspective is provided by the banking 1 In this study, gap analysis refers to the assessment of the extent to which case study of Khadka et al. [16], which places explicit emphasis the requirements identified for the target system were already supported by the on governance and stakeholder involvement throughout the legacy system. Specifically, we operationalised gap analysis as a comparison migration process. Their approach begins with the establishment between the requirements of the system-to-be and the features of the systemof a migration committee comprising both technical and as-is, aimed at identifying which requirements were already fully, partially, or not supported by the legacy system. More broadly, the term is also used managerial stakeholders, followed by the definition of a target throughout the text to denote any general comparison between the two system architecture grounded in business goals, a gap-analysis phase, versions.

to satisfy those requirements, and which features were missing. • Action planning: this phase consists in formalising the research questions (RQs) that should be addressed to solve the diagnosed problem, and defining the actual treatment to be applied to address the RQs. Furthemore, the phase also defines the data collection and analysis procedure to be carried out during the subsequent action taking and evaluation phases (cf. below). In our case, it consisted of: (i) selecting stakeholder-centric RE practices oriented to produce requirements specifications that could be reliably used to perform gap analysis; (ii) formulating RQs to evaluate the effectiveness of the selected RE practices for the problem at hand; (iii) defining a procedure to apply those practices; (iv) identify metrics to evaluate whether the application of the RE practices was successful, together with procedures to collect data for the metrics. • Action taking: in this phase, we applied the different RE practices selected during the action planning phase in a six-month time span involving relevant stakeholders of the company. The result of this activity was a requirement specification that was used in the evaluation phase. The different practices required a minimum of 2-3 days up to 2-3 weeks, followed typically by 2-3 days of synthesis in the form of a progress presentation/report by the first author to the other co-authors. • Evaluation: this phase consists of providing answers for the RQs. The specified requirements were evaluated by examining how well they supported modernisation decisions. To this end, we involved stakeholders in a questionnaire to (i) evaluate the quality of the resulting requirements, and (ii) perform a gap analysis using those requirements. • Specifying learning: after the experience, the authors and stakeholders discussed the lessons learned in a plenary workshop.

plant operators and governmental actors. These reports support both operational improvement and regulatory compliance. For this purpose, the AIM team produces technical reports on the consumption and generation performance of <anonymous company>’s heat assets. These reports depend on technical time-series data, for example emissions data recorded per hour or per day. The reliability and quality of this data are critical, since the reports must provide a faithful representation of the performance of <anonymous company>’s assets. In addition, external audits require the underlying reporting process to be transparent and accountable. To ensure the quality of the data used for reporting, different countries within the company relied on different legacy applications. These applications validated data by detecting and replacing missing values, checking plausibility, and performing calculations needed to derive reportable quantities from raw asset data. For example, CO2 emissions could be calculated by combining time-series data for natural gas with its emission factor and calorific value. In recent years, <anonymous company> has pursued a digital strategy that first focused on moving data to the cloud to improve accessibility, maintainability, and management, and then on renewing the legacy applications used for reporting. The first phase had already been completed when this study began: the relevant reporting data had been migrated to the infrastructure of a chosen cloud vendor. The company had therefore entered the second phase of its strategy, namely the renewal of the legacy reporting applications and, potentially, their migration to the cloud. Across the countries involved, the existing applications were regarded as end-of-life. They had been developed years earlier, and both users and management considered them increasingly inadequate for current business needs. Because the reporting process was business-critical, the company wished not only to renew these systems but also, where possible, to harmonise them across countries. IV. D IAGNOSIS : M ODERNISATION AS A RE P ROBLEM However, the organisation faced difficulties in initiating the The study was conducted at <anonymous company>, a renewal effort effectively. Although there was consensus that multinational energy company operating in Sweden, Denmark, the systems should be renewed, it remained unclear what the Germany, the Netherlands, and the United Kingdom. The work target situation should be and to what extent it differed from took place in <anonymous company>’s Heat department, the functionality already offered by the legacy systems. In which is responsible for heat generation and related assets, particular, the company lacked a systematic basis for deciding such as heat generation plants across Sweden, Germany, which legacy functionality should be retained, which should be and the Netherlands. Within this department, the researchers changed, and which new functionality should be introduced. collaborated closely with the Asset Information Management Problem Formulation. From an RE perspective, this was a (AIM) team, which manages the digital information associated legacy system modernisation problem in which the organisation with these assets. needed to determine which legacy functionality should be As an energy company, <anonymous company> must not retained, adapted, or replaced, but lacked a sufficiently explicit only generate sufficient power and heat for its customers, but and stakeholder-validated specification of the target system do so in a sustainable manner, with minimal emissions and against which the legacy applications could be assessed. We reduced dependence on fossil fuels. At the time of writing, therefore formulated the problem as an RE problem concerned <anonymous company>’s stated mission was to become fossil- with (i) eliciting and formalising stakeholders’ needs for fuel-free within one generation. This implies an obligation to the target system and (ii) using the resulting requirements report fuel and energy consumption, as well as heat and power specification to support gap analysis between the system-as-is production, to internal and external stakeholders, including and the system-to-be.

V. ACTION P LANNING Given the diagnosed problem, the intervention focused on designing an RE process capable of producing a requirements specification that could serve as a reliable basis for system modernisation. We adopted a stakeholder-centric approach because legacy renewal initiatives carry a substantial risk of reproducing existing system functionality without sufficiently examining whether it still reflects present stakeholder needs. By centring the process on stakeholder goals and knowledge rather than on the structure of the existing system, the intervention aimed to reduce the risk of uncritical legacy carryover, a problem defined by Alexandrova et al. as the legacy problem [27]. This was particularly important in the present case, where the organisation sought not only renewal but also harmonisation across multiple countries and organisational contexts. Based on this rationale, we defined the following overarching goal. Overarching goal. To investigate to what extent stakeholdercentric RE practices can produce a requirements specification that supports gap analysis between a legacy system (systemas-is) and a target system (system-to-be) in a multinational system modernisation context. To address this goal, we selected a sequence of stakeholdercentric RE practices aimed at progressively moving from stakeholder knowledge to a structured requirements specification. These techniques include: (i) stakeholder identification according to Hujainah et al. [28] and Pacheco and Garcia [29], (ii) semi-structured requirements elicitation interviews, based on general guidelines [30], [31] and RE-specific ones [32], [33], and thematic analysis of the interview transcripts based on Braun and Clarke [34] to identify preliminary requirements; (iii) a consensus workshop based on the Delphi method [21]; (iv) requirements specification through user stories, widely used in RE research and practice; and (v) requirements prioritisation based on the MoSCoW method [22]. The specific practices were opportunistically selected based on the experience of the research team. Given the time constraints of the action research study, identifying the most suitable practices, learning them, and applying them was not considered feasible. Although this has a substantial impact on the internal validity of the findings, these shortcomings are inherently part of any field experiment [35]2 . The sequence of practices was inspired by the work of Khadka et al. [16], which starts from the creation of a migration committee, elicits needs and architecture for the novel system, and then performs gap analysis. However, it not intended as a prescriptive RE lifecycle, but as a studyspecific operationalisation of established RE activities for the purposes of legacy system renewal. In line with standard RE references [36], which describe the RE process as progressing from elicitation and analysis toward specification and validation, we organised the intervention so as to move from stakeholder identification and need elicitation to agreement, specification, 2 The ABC for software engineering research by Stol et al. [35] classifies action research studies as field experiments.

and prioritisation. This ordering was considered appropriate in our context because it enabled a gradual transition from dispersed stakeholder knowledge to a structured requirements specification that could subsequently support a comparison between the envisioned system and the legacy system. The concrete application of the selected practices in the industrial setting is described in the action taking phase. To evaluate the extent to which this intervention achieved its goal, we formulated the following research questions, aiming to assess the quality of the produced requirements, and their usefulness to identify reuse opportunities and missing functionality. RQ1 (Requirements quality). To what extent do stakeholdercentric RE practices lead to a requirements specification that stakeholders assess as understandable and correct? RQ2 (Gap-analysis consistency). To what extent does the resulting requirements specification enable consistent stakeholder judgements about whether each requirement is already supported by the legacy system? The evaluation strategy was also defined during action planning. RQ1 was operationalised through stakeholder assessment of requirement understandability and correctness, while RQ2 was operationalised through stakeholder classification of whether each requirement was already supported by the legacy system. In the following, we report the details of the data collection and analysis procedures. a) RQ1—Data Collection: RQ1 focuses on understandability and correctness of the requirements. According to Davis et al. [37], a requirement specification is understandable “if all classes of SRS readers can easily comprehend the meaning of all requirements”, and it is correct if “every requirement represents something required of the system to be built, i.e., every requirement [...] contributes to the satisfaction of some need.”. Understandability and correctness form a subset of the quality criteria for a requirements specification from Davis et al. [37], which were selected as they were considered by the company as the most relevant quality dimensions for the renewal problem at hand. In particular, the company needed a requirements specification that stakeholders could understand consistently and recognise as reflecting actual needs. Other quality dimensions, e.g., modifiability [37], were considered less directly relevant to this specific objective. To collect the evaluation data, an online questionnaire was designed and shared with the involved stakeholders, including representatives of users from the different countries, management, and data analytics. For each requirement in the specification, stakeholders were asked whether they understood the requirement (“Do you understand what this requirement means?”), and whether they considered it to address a need (“Does this requirement satisfy a need from your perspective?”). Understandability and correctness were assessed through a binary judgement, and, in the case of correctness, respondents had the possibility to indicate that a requirement was not applicable to them. This was not allowed when assessing understandability, since it was considered important that all requirements are understandable also to stakeholders to whom the requirement

is not directly applicable. Since the requirements were going to among the main users and domain experts of the existing be expressed as user stories, a standard high-level format specif- systems; technical stakeholders were identified among the ically oriented to non-techincal stakeholders, this restriction actors responsible for data management, analytics, and technical was considered reasonable. It should be highlighted that simply solution design; and commercial stakeholders were identified asking whether a requirements was understandable, does not among the relevant management roles. This initial classification imply that the respondent actually understood it correctly, as was subsequently discussed with AIM management, which led phenomena of incorrect subconscious disambiguation could to the inclusion of additional technical actors outside AIM, have occurred [38]. However, given the limited time of the namely the solution designer, solution architect, legacy system stakeholders, asking to rephrase, or introducing other strategies manager, and a developer representative, as these roles were for checking actual understanding, was not considered an considered necessary to represent knowledge about the design, option, as it would limit the number of responses. Furthermore, operation, and historical development of the legacy systems. although binary assessment does not account for the shaded The final list of 14 identified stakeholders is shown in Table I. nature of the constructs considered, this was preferred to a TABLE I: Identified stakeholders Likert scale as it forces a clear-cut decision, which are preferred Stakeholder group Stakeholder in a time-constrained context. Functional-beneficiary Technical reporters NL b) RQ2—Data Collection: Once requirement quality had Specialist reporting NL been assessed, the same questionnaire was used to support Technical reporters GER AIM SWE the gap-analysis task. For each requirement, stakeholders were Technical Data management additionally asked whether the requirement was already covered Data analytics by the current legacy systems (“Is this requirement already Specialist data NL Solution designer covered by the functionality of the current systems?”). Possible Solution architect answers distinguished between full coverage, no coverage, Legacy system manager and partial coverage; when stakeholders indicated coverage or Developer representative Commercial Manager AIM partial coverage, they could also specify the relevant legacy Manager AIM-NL system or explain the reason for partial support. This enabled Manager AIM-GER the collection of a dataset that captured, for each requirement, stakeholders’ views on legacy system coverage. The functional-beneficiary group comprised the main users c) Data Analysis: In both steps, the consistency of stake- of the legacy systems and roles with reporting-related domain holder judgements was analysed through inter-rater agreement knowledge in the Netherlands, Germany, and Sweden. The techusing Krippendorff’s Alpha [39]. In addition to agreement, the nical group comprised roles responsible for data management evaluation also considered descriptive outcome measures: for and analytics within AIM, complemented by actors with design, RQ1, the proportion of requirements judged understandable development, and operational knowledge of the legacy systems. and correct, respectively; and for RQ2, the proportion of The commercial group consisted of the relevant management requirements judged fully or partially supported by the legacy roles, which represented organisational goals, priorities, and systems. The combination of requirement-quality results and external business expectations. functionality-mapping agreement further enabled us to interpret whether ambiguity in the results primarily stemmed from the B. Requirements Elicitation Interviews and Workshop Requirements elicitation was conducted through semirequirements specification itself, from differing understandings structured interviews with the stakeholders listed in Table I. of legacy-system functionality, or from both. Semi-structured interviews were selected because they provide VI. ACTION TAKING enough structure to ensure coverage of the main topics while The selected RE practices were enacted in sequence, starting leaving room for stakeholders to elaborate on their work from identification of stakeholders until requirements specifi- practices, needs, and concerns. The interviews were designed cation and prioritisation. In the following, we report details on following established guidance on qualitative interviewing [30], [31], also considering RE-specific guidance to avoid common the implementation of the planned process. pitfalls [32], [33]. The interviews were conducted in a converA. Identification of Stakeholders sational style, with the aim of creating a comfortable setting in Stakeholder identification was carried out by combining which participants could speak freely and the interviewer could the stakeholder categories proposed by Hujainah et al. [28] focus on listening and probing for clarification when needed. with the practices of Pacheco and Garcia [29] for stakeholder To reduce power imbalance and anchor the discussion in the identification. We first examined the organisational structure participants’ expertise, each interview started with questions of the AIM team and identified candidate stakeholders based about the interviewee’s role, daily work, and involvement with on their current responsibilities in relation to the validation the existing system, before discussing the legacy system’s and calculation system. These candidates were then assigned problems and the expectations from the modernised system. to three categories: functional-beneficiary, technical, and comInterview guides were tailored to the different stakeholder mercial. Functional-beneficiary stakeholders were identified groups and consisted of broad, open-ended questions. While all

interviews mainly addressed the overall goal of understanding the expectations for the renewal effort as well as the characteristics of the current system, the emphasis varied by role. Users were asked primarily about their current use of the system (e.g., “How do you use the system in your daily work?”), difficulties encountered (e.g., “What is the first thing you would change about the system?”), and desired functionality (e.g., ‘‘What do you miss in the system that you consider essential?”); management stakeholders were asked about business goals (“ What is from a management perspective the most important goal of roadmap 2.0?”), priorities (“What would be the most important factors when choosing between multiple possible new applications?”), and expected outcomes of the renewal (“What value will roadmap 2.0 have within the company as a whole?”); and technical stakeholders were asked about data flow (“What is your vision of what the data flow would ideally look like?”), and other data-related aspects, using a more technical language (“The users already indicate a number of important matters: transparency, speed, user friendliness, reliability, flexibility. If you hear these topics, how do you think we can best deal with them from a data perspective? Think about data accessibility, data transparency, single point of truth, etc.”). The objective of the interviews was to elicit an initial understanding of the stakeholder’s knowledge on the current system, as well as their needs, so that these could be translated into preliminary requirements. The interview data were analysed using thematic analysis following Braun and Clarke [34]. Interview answers were first coded by summarising or aggregating relevant statements into short descriptive codes. These codes were then clustered into themes representing recurring needs, concerns, and expectations regarding the future system, and that took the form of informal preliminary requirements (e.g., “track changes in system”, “statistics on data and system load”, “collection of manual inputs from plant technician”). As the analysis progressed, the themes were further organised into functionality groups that captured the main areas of the system under discussion, namely: data ingestion, validation, calculation, export, plant characteristics, data analytics, and general. These groups helped structure the problem space and clarify the system’s intended scope. The process produced a total of 40 themes within the seven functionality groups. The preliminary findings from the thematic analysis were then presented to the full stakeholder group, i.e., 14 participants, in a workshop session, carried out based on the Delphi method [21] for consensus making. Specifically, for each theme, each stakeholder was engaged in a SWOT analysis, in which they were asked to assess strenghts (in terms of potential relevance and impact), weaknesses (how much the theme was ill-defined), opportunities (in terms of added value for the business), and threats (in terms of business risks). Three rounds of discussion were performed until consensus was reached. While during the session the themes were not formalised as user stories, potentially hampering their interpretability, the interactive nature of the session facilitated shared understanding. This session served to validate the emerging interpretations,

harmonise understanding across stakeholders, and refine the next step of the planned process. C. Requirements Specification Based on this discussion, the themes were converted into an a list of 105 requirements and circulated for validation and prioritisation. The requirements were formalised through user stories, using the format As a <Role> I want to <do Action> because <Goal> by <How>. Example requirements are: “As a reporter I want to have normalized data available for comparison of data in equal units and granularity by converting data into the same dimensions”; and “As a reporter I want to be notified when there is no connection with PI to estimate the impact of connectivity issues on technical reporting by receiving an active notification when connectivity issues occur”. The final dataset contained 16 entries/topics—or epics in the Agile parlance [40]—covering 105 requirements. D. Requirements Prioritisation All stakeholders were invited to take part to the prioritisation process. Requirements were prioritised using the MoSCoW method, selected for its simplicity and its suitability for use in the early stages of a project. Each stakeholder was asked to rate every requirement as Must, Should, Could, or Won’t, based on their view of the system. This produced a dataset containing a distribution of prioritisation scores for each requirement, which could then be used to determine which aspects of the system should be elaborated first. The idea was to understand the requirements that were expected to be implemented in a minimum viable product (MVP) of the envisioned system, i.e., the first basic version of the target system that was expected to be completed enough to demonstrate the value it would bring to the company [41]. Although the list of requirements was distributed to all stakeholders, in practice it appeared most suitable for management, end-users, and the data department, which amounted in total to 9 people. The IT developers and architects indicated that they did not consider themselves the appropriate actors to rate the requirements, as their role was to design and build the solution rather than to express preferences about what the system should do. To enable a fair comparison across perspectives, stakeholder input was weighted at group level. For example, the German users were represented by a single participant, who had collected input from the other German users and reflected this in his own ratings, whereas the Dutch users were represented by four participants. To balance this difference in representation, the German user’s responses were counted four times. Although this gave that participant greater influence, this adjustment was not communicated in advance and therefore could not have influenced the ratings themselves; moreover, it was considered the most practical way to ensure equal representation of the two user groups. Similarly, management was given the same overall weight as the combined user group, as it was considered more appropriate to balance stakeholder groups

TABLE III: Requirement quality and functionality mapping than individual stakeholders in order to reflect the different perspectives involved. Measure Rating ratio Tight Lenient Understandability 30.5–1 80% 100% Not all invited stakeholders submitted their ratings. The Correctness 18.4–1 66% 100% Swedish user base did not complete the prioritisation, and Functionality mapping 1.34–1, 0.59–1 0% 50% only two of the three management representatives responded. These stakeholders had been informed that, if they did not respond by the deadline, it would be assumed that their views correctness. Under the lenient interpretation, all requirements were sufficiently represented by their colleagues’ input. On were judged understandable and correct by a majority of that basis, the collected ratings were considered an acceptable stakeholders; under the tight interpretation, the proportions representation of the stakeholder perspectives involved. An remained high at 80% and 66%, respectively. estimate response rate was achieved around 58%, which is well above typically acceptable levels. RQ1—Requirements Quality. The stakeholder-centric Agreement on the priority was rather low, as for less than RE practices were effective in producing a requirements 20% of the requirements at least 80% of the stakeholders specification that stakeholders largely agreed to be actually agreed on the precise rating. Given the large number understandable and correct. and variety of stakeholders this should have been, however, expected. For this reason it was decided to discard any requirements that had less than half of the votes include “must” B. RQ2: Gap-analysis consistency RQ2 asked to what extent the resulting requirements specifior “should”. The final list of retained requirements for the cation enabled consistent stakeholder judgements about whether MVP consisted of 56 items. each requirement was already supported by the legacy system. VII. E VALUATION This was evaluated through the additional questionnaire item This section reports the results of the evaluation and answers on legacy-system coverage, again analysed through inter-rater the two research questions defined in the action planning phase. agreement. As shown in Table II, agreement on functionality mapping A. RQ1: Requirements Quality was the lowest of all measured dimensions, with an alpha RQ1 asked to what extent the stakeholder-centric RE value of 0.45. This indicates only limited consistency in practices led to a requirements specification that stakeholders stakeholder judgements about whether requirements were assessed as understandable and correct. To answer this question, already covered by the system-as-is. The descriptive results the requirements were evaluated through the stakeholder in Table III reinforce this interpretation. Under the tight questionnaire introduced in Sect. V, and inter-rater agreement interpretation, no requirement achieved unanimous agreement was analysed using Krippendorff’s Alpha. Table II reports regarding functionality mapping, and even under the lenient the agreement values obtained for the three selected quality interpretation only 50% of requirements were judged as mapped dimensions, together with the value for functionality mapping consistently enough to support a majority-based interpretation. used later to answer RQ2. The findings therefore suggest that the main limitation was not the understandability of the elicited requirements, TABLE II: Agreement values but rather the difficulty of establishing a shared view of Agreement on Alpha value legacy system coverage. Stakeholders appeared to hold different Understandability 0.94 understandings of what the existing system actually supported. Correctness 0.90 This is consistent with the well-known ambiguity and erosion of Functionality mapping 0.45 knowledge surrounding long-lived legacy systems [15], but also The results show very high agreement on understandability with the inherently partial viewpoints of different stakeholder and correctness, with alpha values of 0.94 and 0.90, respectively, roles [42]. Although not a novel finding per-se, it quantifies reflecting the effectiveness of the different viewpoint sharing the magnitude of the viewpoint differences. The divergence workshops. Agreement alone, however, does not indicate in stakeholder viewpoints is also reflected in the prioritisation whether the requirements were judged positively or negatively. results, where agreement was reached for only 20% of the We therefore also examined the extent to which the require- requirements. However, this specific result was considered ments satisfied the selected quality dimensions. Following surprising, given that a Delphi method-based workshop was Davis et al. [37], quality was interpreted as the proportion specifically organised after requirements elicitation interviews of requirements satisfying each measure. Because categorical with the specific objective of achieving a shared understanding ratings do not allow meaningful averaging, we report two of the target system’s goals. interpretations: a tight interpretation, in which all raters had The results in Table III also highlight that the legacy system to agree, and a lenient interpretation, in which a majority was generally not considered to include the majority of the judgement was sufficient. envisioned functionality. On the one hand, this suggests that the Table III shows that the resulting specification performed renewal process was actually highly needed, as several needs strongly on understandability and, to a sufficient extent, also were not currently satisfied. On the other hand, it might indicate

that the way the RE practices were implemented tended to target novel needs, leading stakeholders to focus on what is missing, rather than envisioning the complete system. RQ2—Gap Analysis Consistency. The resulting requirements specification enabled gap analysis in the sense that stakeholders could use it to assess legacy system coverage requirement by requirement. However, the relatively low agreement shows that this assessment was not sufficiently consistent to support strong conclusions about reuse potential. Furthemore, while the implementation of the RE approaches supported the identification of novel requirements, they were not effective in eliciting requirements already satisfied by the existing system. VIII. S PECIFYING L EARNING : D ISCUSSION The following observations outline reflections that emerged during the final plenary workshop. The reflections were further elaborated by the authors based on their experience and the existing literature. At the end of each paragraph, we provide some actionable suggestions (using the symbol ▶), to be assessed in future studies. Stakeholder Needs and the System-as-is. Overall, the findings show that the intervention was successful in producing a requirements specification that stakeholders largely considered understandable and, to a considerable extent, correct (RQ1), but less successful in establishing agreement on functionality mapping to the legacy systems (RQ2). This suggests that the main challenge was not only eliciting requirements for the system-to-be, for which substantial disagreements were already observed during prioritisation, but also reconciling partially different stakeholder views on what the legacy systems already provided. From this perspective, the main value of the gap-analysis exercise was diagnostic: it revealed fragmented knowledge across stakeholders, and showed that legacy system modernisation requires, first and foremost, a reconstruction of a shared understanding of the existing systems. This apparently confirms the perspective of part of the literature [10], in which legacy system understanding is the first step of modernisation endeavours3 . On the other hand, it should be noted that, in the case discussed, the initial uncertainty of the problem, and the similarity with the industrial experience from Khadka et al. [16], triggered the authors to start from stakeholders’ needs, rather than the status quo, i.e., the legacy system. The participants agreed that this was likely a mistake that should have been prevented, e.g., by dedicating more time during the interviews to understand the current system. However, RE practices appear to be strongly biased towards the development of novel systems, and even in the cases in which interview guidelines—also used in our interview design—recommend to understand the system/process-as-is [32], [33], this mostly serves the goal of identifying the problems with the current system, rather than 3 Interestingly, Wolfart et al. [10] derives a general process from the literature, and the elicitation of stakeholder needs is not included in the process, remarking the scarce attention of the literature to the RE dimension.

the features that actually work and should be retained. Novel guidelines are needed that specifically target the understanding and reconstruction of the system-as-is, not only in terms of functionality, as done in the literature, but also in terms of needs that it already satisfies. Understanding the rationale underlying legacy system behaviour can help identify features that are no longer required, as the conditions or needs that originally motivated them may no longer apply. ▶ Requirements elicitation in legacy system renewal should adopt a two step interview process with associated scripts, one to reconstruct the system-as-is (including both strenghts and weaknesses), and the other one oriented to define novel requirements for the system-to-be. From Stakeholder-centric RE to Evidence-based RE. When stakeholder perspectives diverge strongly and knowledge about legacy functionality has eroded over time, further progress appears to require complementary practices, both stakeholdercentric and system- and data-centric. These may include additional rounds of reconciliation among stakeholders, and, more importantly, systematic examination of evidence from the legacy systems themselves, such as existing reports, configurations, process traces, documentation, or implementation artefacts. These forms of triangulation can help move the renewal effort from a stakeholder-perceived view of the current and desired situations toward a more evidence-based and collectively validated understanding. While a stakeholder-centric RE process like the one enacted can bring the organisation to the point where major ambiguities become explicit, additional evidenceoriented and consensus-building activities are needed to enable robust modernisation decisions. ▶ In legacy system modernisation, elicit information from stakeholders, but make sure to contrast opinions and viewpoints with system evidence, e.g., reports, documentation, logs, and artefacts. The Role of Automation and Large Language Models (LLMs). To support evidence-based modernisation, automation is expected to play an important role, especially given the typical size and layered evolution of legacy systems, where functionality, design decisions, and operational assumptions accumulate over time, much like strata in an archaeological site. This suggests the need for approaches that integrate stakeholdercentric RE practices with automated system-understanding techniques. Relevant examples include feature location, which aims to identify whether and where a given feature is implemented in a software system [43]; specification mining, which aims to infer likely behavioural rules or specifications from executions or software artefacts [44]; process mining, which reconstructs observed business or operational processes from event data and execution logs [45]; and architecture recovery, including mining software repositories for architectural knowledge, which aims to reconstruct higher-level structural views of a system from source code and related artefacts [46]. In addition, recent studies suggest that large language models (LLMs) may support automated architecture recovery [47], [48], thereby offering a promising complement to more established reverse-engineering techniques. Together, these techniques point toward hybrid

approaches in which stakeholder input is complemented with to legacy system modernisation to ensure that project uncerautomatically recovered evidence about the system. tainty is incrementally reduced. By introducing innovations ▶ When analysing system evidence, exploit LLMs and through controlled iterations, these tailored practices yield automation in general, using recent research solutions for tangible product increments that directly facilitate stakeholder architecture recovery, specification mining, and process mining. consensus. ▶ The RE community should engage more closely with ▶ Modernisation-specific backlogs should be defined that the mining software repositories and software architecture account for existing, desired, and obsolete features, with communities to develop joint strategies for evidence-based associated uncertainty measures or qualifiers. legacy system modernisation. IX. T HREATS TO VALIDITY Stakeholder Unavailability and Insufficient Evidence. In a) Internal Validity: The study was conducted as an action our study we experienced first-hand that stakeholder-centric RE is subject to inherent practical limitations, which may research intervention in a real industrial setting, which makes have strongly affected the results of the study. In industrial it difficult to isolate the effect of each individual RE practice settings, including the one considered in this study, stakeholder on the final outcome. The observed results stem from the availability is often limited, so participation across activities combination of stakeholder identification, interviews, thematic is necessarily based on sampling, representation, and best analysis, prioritisation, and questionnaire-based evaluation, effort rather than complete and continuous involvement of all rather than from any single step in isolation. Moreover, the order identified stakeholders. Consequently, even repeated activities of the activities, although justified by previous experiences [16] with intense stakeholder involvement may fail to produce and by established RE literature [36], could have affected the a fully shared understanding. This was visible in our case, results. Stakeholder participation also varied across activities, where disagreement persisted despite several opportunities for and not all identified stakeholders took part in all phases. As interaction. We have suggested that evidence-based RE could a consequence, the resulting requirements specification and address the problem. However, in the present case, evidence was evaluation outcomes may have been influenced by who was only available to a limited extent, and the main repository of available, how actively they participated, and how representative knowledge about the legacy systems were the stakeholders their contributions were of the broader organisation. b) External Validity: The study concerns a single modernithemselves. This suggests the need for RE practices that explicitly account for knowledge uncertainty and can support sation effort in one multinational energy company, focused on successful renewal despite limited stakeholder involvement and a specific reporting-related legacy system. The organisational setting, the nature of the system, the available stakeholders, limited available evidence. ▶ When the sources of evidence are limited, make sure to and the company’s ongoing strategy all shaped the intervention. explicitly account for uncertainty in knowledge and require- For this reason, the findings cannot be assumed to generalise ments, e.g., associating the different information items elicited directly to other organisations or domains. In particular, the with both stakeholder agreement and evidence support scores. suitability of the selected RE practices may vary depending The Need for Agile Renewal. A main reflection of the action on system complexity, the availability of documentation and research team is that, to address the problem of stakeholder other evidence, the maturity of the organisation’s processes, availability and limited evidence, stakeholder-centric RE for and the extent to which legacy knowledge is still held by legacy system modernisation should be organised as an iterative stakeholders. The study should therefore be interpreted as an and incremental learning process rather than as a one-shot in-depth industrial investigation that provides analytical rather planning exercise. Because stakeholder availability is inher- than statistical generalisation. Nevertheless, according to caseently limited, involvement must often rely on representative based generalisation principles [49], our conclusions might be participation, best effort, and progressive inclusion of those applicable to contexts that share similar characteristics with stakeholders who are most likely to reduce the most critical our study settings: multi-national energy companies dealing remaining uncertainties. In such a process, renewal would with system modernisation; large legacy systems for data proceed stepwise, focusing on small slices of functionality analytics and reporting; involvement of diverse stakeholders, and revising priorities as new understanding emerges. Where at management, user, and IT level. conflicting stakeholder accounts remain unresolved, the process c) Construct Validity: Several constructs in the study were should draw on additional evidence from the legacy systems operationalised in ways that may only partially capture the phethemselves whenever such evidence is available. This suggests nomena of interest. First, the effectiveness of the intervention a direction that is compatible with agile and backlog-driven was assessed through two main lenses: the perceived quality ways of working, for example by maintaining a living renewal of the resulting requirements specification and its usefulness backlog of requirements, ambiguities, evidence needs, and for supporting requirements-based gap analysis. While these candidate migration slices. In this sense, approaches inspired are reasonable operationalisations for this study, they do not by Scrum or other agile methods may be useful as templates for exhaust all possible notions of effectiveness in legacy system structuring renewal into short cycles of elicitation, validation, modernisation. Second, requirement quality was assessed implementation planning, and reassessment. through understandability and correctness, which are only a ▶ Agile software engineering techniques should be tailored limited set of the quality attributes outlined by Davis et al. [19].

Third, understandability was merely estimated by asking users but to progressively reduce uncertainty and build a sufficiently whether they considered the requirements understandable. evidence-based basis for modernisation decisions. While this self-assessment may not fully capture underlying AI Disclosure. ChatGPT 5.4 was used to assist in revising the comprehension barriers in a multi-lingual environment, the risk language and presentation of the manuscript. The authors take of misinterpretation was mitigated because the requirements full responsibility for the final text. were written using a simple language. Fourth, gap analysis was operationalised through stakeholder judgements of whether R EFERENCES each elicited requirement was already fully, partially, or not [1] J. Bisbal, D. Lawless, B. Wu, J. Grimson, V. Wade, R. Richardson, supported by the legacy system. This captures one important and D. O’Sullivan, “A survey of research into legacy system migration,” aspect of gap analysis, but not broader process, organisational, Trinity College Dublin, Tech. Rep., 1997. or architectural gaps. [2] R. C. Seacord, D. Plakosh, and G. A. Lewis, Modernizing legacy systems: software technologies, engineering processes, and business practices. The qualitative parts of the study introduce further constructProfessional, 2003. related uncertainty, since coding and thematic analysis neces- [3] Addison-Wesley G. Visaggio, “Comprehending the knowledge stored in aged legacy sarily involve researcher interpretation. The Delphi workshop systems to improve their qualities with a renewal process,” International Software Engineering Research Network, Tech. Rep. 97-26, 1997. mitigated this threat to some extent, but could not eliminate it [4] ——, “Ageing of a data-intensive legacy system: Symptoms and remedies,” entirely. Finally, the agreement analysis should be interpreted J. Softw. Maint.: Res. Pract., vol. 13, pp. 281–308, 2001. with caution, as the chosen operationalisation of inter-rater [5] M. Battaglia, G. Savoia, and J. Favaro, “Renaissance: A method to migrate from legacy to immortal software systems,” in CSMR’98, 1998, agreement reflects observed consistency in this setting rather pp. 197–200. than a fully theory-neutral measure of underlying truth. X. C ONCLUSION This paper investigated the role of stakeholder-centric RE practices in legacy system modernisation. Through an action research study in a multinational energy company, we found that these practices were paramount in producing requirements that stakeholders largely considered understandable and correct. However, when the resulting requirements were used to assess which ones were already supported by the legacy system, substantial disagreement emerged, pointing to fragmented understanding of the existing system. This suggests both that stakeholder-centric practices, as implemented in our study, were insufficient on their own, and that elicitation requires stronger support from automated techniques combined with human judgement to understand the system-as-is. The need for a stronger human + automated RE combo is bound to be required for large modernisation where employee turnover and any other organisational rewiring exercise change the project knowledge structure to a point where drift between old and new becomes unmanageable. This would also lead to assume that an organisation/community-centric approach—as opposed to a stakeholder-centric one—may prove beneficial in the future, as systems become larger and more unmanageable. The industrial participants agreed that stakeholder-centric RE practices are a non-negotiable starting point. While they were not sufficient on their own to resolve conflicting interpretations of the actual behaviour of the legacy systems, they gave solid grounds to progress in the modernisation efforts. They allowed them to make their idea more explicit and gave them the opportunity to see that an agreement and knowledge problem existed. Requirements elicitation research should pose a stronger emphasis on the pre-existing system as a source of requirements, and RE techniques should be developed to elicit and combine stakeholder and system knowledge, possibly captured through automated methods. The goal of RE for legacy system is not to fully resolve the renewal problem in one pass,

[6] W. Hasselbring, R. Reussner, H. Jaekel, J. Schlegelmilch, T. Teschke, and S. Krieghoff, “The dublo architecture pattern for smooth migration of business information systems: An experience report,” in ICSE’04, 2004, pp. 117–126. [7] M. Grieger, M. Fazal-Baqaie, G. Engels, and M. Klenke, “Concept-based engineering of situation-specific migration methods,” in International Conference on Software Reuse. Springer, 2016, pp. 199–214. [8] L. Márquez, D. G. Rosado, H. Mouratidis, D. Mellado, and E. FernándezMedina, “A framework for secure migration processes of legacy systems to the cloud,” in CAiSE. Springer, 2015, pp. 507–517. [9] J. Fritzsch, J. Bogner, A. Zimmermann, and S. Wagner, “From monolith to microservices: A classification of refactoring approaches,” in DEVOPS’18. Springer, 2018, pp. 128–141. [10] D. Wolfart, W. K. G. Assunção, I. F. da Silva, D. C. P. Domingos, E. Schmeing, G. L. D. Villaca, and D. do Nascimento Paza, “Modernizing legacy systems with microservices: A roadmap,” in EASE’21. ACM, 2021, pp. 149–159. [11] T. I. Mohottige, A. Polyvyanyy, C. J. Fidge, R. Buyya, and A. Barros, “Reengineering software systems into microservices: State-of-the-art and future directions,” IST, vol. 183, p. 107732, 2025. [12] H. Sneed and C. Verhoef, “Re-implementing a legacy system,” JSS, vol. 155, pp. 162–184, 2019. [13] J. Crotty and I. Horrocks, “Managing legacy system costs: A case study of a meta-assessment model to identify solutions in a large financial services company,” API, vol. 13, no. 2, pp. 175–183, 2017. [14] W. K. Assunção, L. Marchezan, L. Arkoh, A. Egyed, and R. Ramler, “Contemporary software modernization: Strategies, driving forces, and research opportunities,” TOSEM, vol. 34, no. 5, pp. 1–35, 2025. [15] R. Khadka, B. V. Batlajery, A. M. Saeidi, S. Jansen, and J. Hage, “How do professionals perceive legacy systems and software modernization?” in ICSE’14, 2014, pp. 36–47. [16] R. Khadka, A. Saeidi, S. Jansen, J. Hage, and G. P. Haas, “Migrating a large scale legacy application to soa: Challenges and lessons learned,” in 20th Working Conference on Reverse Engineering, 2013, pp. 425–432. [17] B. Nuseibeh and S. Easterbrook, “Requirements engineering: A roadmap,” in FOSE’00, 2000, pp. 35–46. [18] C. Palomares, X. Franch, C. Quer, P. Chatzipetrou, L. López, and T. Gorschek, “The state-of-practice in requirements elicitation: an extended interview study at 12 companies,” REJ, vol. 26, pp. 273–299, 2021. [19] A. Davis, O. Dieste, A. Hickey, N. Juristo, and A. M. Moreno, “Effectiveness of requirements elicitation techniques: Empirical results derived from a systematic review,” in RE’06. IEEE, 2006, pp. 179–188. [20] M. Staron, Action research in software engineering. Springer, 2020. [21] A. L. Friedman and S. Miles, “Developing stakeholder theory,” Journal of Management Studies, vol. 39, no. 1, pp. 1–21, 2002. [22] S. Vijayakumar, K. Krishna-Prasad, and R. Holla M., “Assessing the effectiveness of moscow prioritization in software development: A holistic analysis across methodologies,” TIoT, vol. 10, Oct. 2024.

[23] M. H. Hasan, M. H. Osman, N. I. Admodisastro, and M. S. Muhammad, “Legacy systems to cloud migration: A review from the architectural perspective,” JSS, vol. 202, p. 111702, Aug. 2023. [24] L. Carvalho, A. F. Garcia, W. K. G. Assunção, T. E. Colanzi, R. Bonifácio, L. P. Tizzei, R. M. de Mello, R. Cerqueira, M. Ribeiro, and C. Lucena, “Re-engineering legacy systems as microservices: An industrial survey of criteria to deal with modularity and variability of features,” in Handbook of Re-Engineering Software Intensive Systems into Software Product Lines. Springer, 2023, pp. 471–494. [25] L. García-Borgoñón, M. A. Barcelona, A. J. Egea, G. Reyes, A. Sainzde-la maza, and A. González-Uzabal, “Lessons learned in model-based reverse engineering of large legacy systems,” in CAiSE. Springer, 2023, pp. 330–344. [26] G. Hogan, P. Shalkauskaite, M. Zhu, M. Derwin, M. Yilmaz, A. McCarren, and P. M. Clarke, “Investigating systems modernisation: approaches, challenges and risks,” in EuroSPI’24. Springer, 2024, pp. 147–162. [27] A. Alexandrova, L. Rapanotti, and I. Horrocks, “The legacy problem in government agencies: An exploratory study,” in dg.o’15, 2015, pp. 150–159. [28] F. Hujainah, R. B. A. Bakar, M. A. Abdulgabber, and K. Z. Zamli, “Software requirements prioritization: A systematic literature review on significance, stakeholders, techniques and challenges,” IEEE Access, vol. 6, pp. 71 497–71 523, 2018. [29] C. Pacheco and I. Garcia, “A systematic literature review of stakeholder identification methods in requirements elicitation,” JSS, vol. 85, no. 9, pp. 2171–2181, 2012. [30] H. Alshenqeeti, “Interviewing as a data collection method: A critical review,” English Linguistics Research, vol. 3, no. 1, pp. 39–45, 2014. [31] R. Barbour and J. F. Schostak, “Interviewing and focus groups,” in Research Methods in the Social Sciences. Sage Publications, 2005, pp. 41–48. [32] B. Donati, A. Ferrari, P. Spoletini, and S. Gnesi, “Common mistakes of student analysts in requirements elicitation interviews,” in REFSQ’17. Springer, 2017, pp. 148–164. [33] A. Ferrari, P. Spoletini, M. Bano, and D. Zowghi, “Learning requirements elicitation interviews with role-playing, self-assessment and peer-review,” in 2019 IEEE 27th international requirements engineering conference (RE). IEEE, 2019, pp. 28–39. [34] V. Braun and V. Clarke, “Thematic analysis,” in APA Handbook of Research Methods in Psychology, H. Cooper, P. M. Camic, D. L. Long, A. T. Panter, D. Rindskopf, and K. J. Sher, Eds. American Psychological Association, 2012, vol. 2, pp. 57–71. [35] K.-J. Stol and B. Fitzgerald, “The abc of software engineering research,” TOSEM, vol. 27, no. 3, pp. 1–51, 2018. [36] K. Pohl, Requirements Engineering, 2nd ed. Berlin, Heidelberg: Springer, 2025, xVIII, 889 pages. [37] A. Davis, S. Overmyer, K. Jordan, J. Caruso, F. Dandashi, A. Dinh, G. Kincaid, G. Ledeboer, P. Reynolds, P. Sitaram, A. Ta, and M. Theofanos, “Identifying and measuring quality in a software requirements specification,” in METRICS’93, 1993, pp. 141–152. [38] A. Ferrari, P. Spoletini, and S. Gnesi, “Ambiguity and tacit knowledge in requirements elicitation interviews,” REJ, vol. 21, no. 3, pp. 333–355, 2016. [39] K. Krippendorff, “Computing krippendorff’s alpha-reliability,” Departmental Papers (ASC), 2011. [Online]. Available: https: //repository.upenn.edu/asc_papers/43 [40] G. Schuh, C. Doelle, and S. Schloesser, “Agile prototyping for technical systems: Towards an adoption of the minimum viable product principle,” in Proceedings of NordDesign 2018, 2018. [41] D. R. Moogk, “Minimum viable product and the importance of experimentation in technology startups,” Technology Innovation Management Review, pp. 23–26, 2012. [42] B. Nuseibeh, A. Finkelstein, and J. Kramer, “Method engineering for multi-perspective software development,” IST, vol. 38, no. 4, pp. 267–274, 1996. [43] B. Dit, M. Revelle, M. Gethers, and D. Poshyvanyk, “Feature location in source code: a taxonomy and survey,” Journal of software: Evolution and Process, vol. 25, no. 1, pp. 53–95, 2013. [44] H. J. Kang and D. Lo, “Adversarial specification mining,” TOSEM, vol. 30, no. 2, pp. 1–40, 2021. [45] W. M. van der Aalst and J. Carmona, Process mining handbook. Springer, 2022, vol. 448.

[46] M. Soliman, M. Albonico, I. Malavolta, and A. Wortmann, “Mining software repositories for software architecture—a systematic mapping study,” IST, vol. 181, p. 107677, 2025. [47] D. Amalfitano, M. De Luca, T. Santilli, P. Pelliccione, and A. R. Fasolino, “Automated software architecture design recovery from source code using llms,” in ECSA’25. Springer, 2025, pp. 73–89. [48] A. Boronat and J. Mustafa, “Mdre-llm: A tool for analyzing and applying llms in software reverse engineering,” in SANER’25. IEEE, 2025, pp. 850–854. [49] R. Wieringa and M. Daneva, “Six strategies for generalizing software engineering theories,” Science of computer programming, vol. 101, pp. 136–152, 2015.