2.1. Systems engineering

Systems Engineering (SE) is an interdisciplinary methodology for developing complex systems through systematic management of requirements, interactions, and trade-offs (International Council on Systems Engineering (INCOSE), 2015). SE emphasizes defining customer needs and required functionality early, then documenting requirements, synthesizing designs, and validating the system (International Organization for Standardization (ISO), 2015). By systematically decomposing systems into manageable domains (Reference ScheithauerScheithauer, 2013) while maintaining holistic consideration of stakeholder requirements, SE provides the structured framework in which requirements engineering operates, particularly in complex domains such as automotive and aerospace development.

2.2. Requirements engineering activities

Requirements Engineering involves systematic activities for identifying, specifying, and managing requirements throughout the development process. Reference RuppRupp and Sophisten (2021) offers a comprehensive framework that organizes these RE activities into four main categories. The first category, Knowledge Elicitation, deals with gathering the necessary information, determining what requirements are needed, defining project visions and goals, understanding relevant business processes, clarifying the system context, and identifying where requirements come from. The second category, Deriving Good Requirements, is about ensuring quality by verifying requirements, bringing related requirements together, and continuously analyzing and refining them. The third category, Communicating Requirements, addresses how requirements are shared with different stakeholders, whether through alternative presentation formats, visual models, or natural language documentation. The fourth category, Managing Requirements, covers the ongoing work of editing requirements as they evolve, maintaining traceability throughout the project, and handling the various administrative tasks that arise during development. In this study, we use this framework as the analytical lens to map each identified AI application to specific RE activities (see Table 3). This reveals which parts of the RE process already receive AI support and which areas remain largely unexplored.

3.1. Research questions

Based on the identified gap in systematic understanding of AI applications in requirements engineering, this study poses three research questions:

RQ1: What AI applications for requirements engineering are reported in the systems engineering literature, and which RE activities do they address?

RQ2: What patterns emerge regarding industry domains, implementation status, and AI methods employed in current applications?

RQ3: What implications arise for future development of AI support in requirements engineering?

3.2. Research methodology

This study follows the Design Research Methodology (DRM) proposed by Reference Blessing and ChakrabartiBlessing and Chakrabarti (2009), which structures design research into four phases: Research Clarification, Descriptive Study I, Prescriptive Study, and Descriptive Study II. This paper specifically addresses the Descriptive Study I phase, which aims to build comprehensive understanding of the existing situation through systematic analysis as foundation for subsequent development and validation phases. To answer the research questions, a systematic literature review (SLR) was conducted following the process described by Reference Xiao and WatsonXiao and Watson (2019). The review proceeded through seven steps: (1) formulating research questions, (2) defining search strategy, (3) executing search, (4) applying selection criteria, (5) analyzing selected publications, (6) synthesizing findings, and (7) presenting results. Figure 1 visualizes the complete SLR process. To answer RQ1, the study first identifies relevant AI applications through this systematic literature review. Subsequently, these applications are mapped to Reference RuppRupp’s (2021) Requirements Engineering framework, which organizes RE activities into four main groups comprising specific activities. This mapping reveals which RE activities currently receive AI support and which remain largely unaddressed. Additional analyses of industry domains, implementation status, and AI methods address RQ2, while RQ3 is explored through synthesis of these findings in the discussion. Subsequent DRM phases (Prescriptive Study and Descriptive Study II) are beyond the scope of this paper.

Figure 1.

Process of SLR showing the seven steps according to Reference Xiao and WatsonXiao and Watson (2019)

3.3. Search strategy

To identify relevant publications, three scientific databases were selected: Scopus, Web of Science, and Google Scholar. These databases were chosen to capture both established academic publications and emerging research in the field. The search string was developed based on the main research areas: requirements engineering, artificial intelligence, and systems engineering. Since requirements engineering is sometimes referred to as requirements management in practice, both terms were included. Similarly, various abbreviations and full forms of artificial intelligence terms were incorporated to ensure comprehensive coverage:

(“Requirements Engineering” OR “Requirements Management”) AND (“AI” OR “Artificial Intelligence” OR “LLM” OR “Large Language Model”) AND (“Systems Engineering”)

After initial testing, the search string was also translated into German to capture relevant German-language publications, particularly from German-speaking academic and industrial contexts. Given the rapid development of AI technologies, particularly large language models, in recent years, the search was restricted to publications from 2020 to 2025 to focus on current approaches and technologies. Only peer-reviewed journal articles and conference proceedings in German or English were considered to ensure academic quality.

3.4. Selection process and criteria

The English search returned results across all databases: Scopus (331), Web of Science (42), and Google Scholar (around 5,800). The German search yielded 17 additional results, all from Google Scholar. For Scopus and Web of Science, all results were included in the screening process, while for Google Scholar, the first 100 results from both English and German searches were considered to focus on the most relevant documents. After removing duplicates, 490 publications remained for initial screening.

The screening followed two stages. First, all 490 titles were reviewed for alignment with these criteria, which resulted in 149 publications warranting filtering abstracts. After conducting the abstract analysis, 45 documents remained for full-text assessment. In the second stage, these 45 documents were read in full to verify their relevance. During this process, six publications could not be accessed despite attempts through institutional access and interlibrary services. After thorough assessment, 24 publications were excluded as they either lacked sufficient detail on AI implementation, focused primarily on AI engineering aspects rather than RE support, or did not provide transferable insights for systems engineering contexts. Forward and backward citation searches were conducted on the remaining 15 publications. While several additional documents were identified through these searches, none met all inclusion criteria when assessed, particularly regarding the timeframe (2020-2025) and the focus on practical AI application in requirements engineering. The final dataset thus consisted of 15 publications. Figure 2 illustrates this screening process, showing the systematic reduction from 490 initial search results through various filtering stages to the final 15 publications.

Table 1.

Overview of inclusion and exclusion criteria

Figure 2.

Flow diagram showing literature screening process

4.1. Overview of identified publications

Table 2 provides an overview of the identified publications, showing their industry domain, implementation status, specific RE tasks addressed, and AI methods employed. The column ‘State’ indicates whether the referenced work describes a framework (F) or applies an implementation (I) of an AI application. No distinction is made regarding whether the reference uses test data or real field data from industry.

Table 2.

Overview of identified publications on AI in RE

4.2. Description of identified publications

The identified publications are summarized below in order of appearance in Table 2.

Reference Timperley, Berthoud, Snider and TryfonasTimperley et al. (2025) used the LLM ChatGPT-4 in the aerospace sector to first create a list of functions from functional requirements. In a further step, an architecture was generated according to MBSE. For this purpose, different prompts were transmitted to the language model via a Python script, with the most detailed prompt with the most accurate task description leading to the highest traceability and the best result. Reference Zhang, Larsson, Larsson, Tian, Zhang and WangZhang et al. (2024) used various Bidirectional Encoder Representations for Transformers (BERT) models to match usage scenarios for Volkswagen vehicles with product features. They succeeded in identifying relevant requirements and uncovering undiscovered customer needs. The comparison was made by determining the semantic similarity between the textual content, which was calculated using cosine similarity. Reference Jiang, Sun, Zhu, Yan, Wang and ZhangJiang et al. (2025) examined customer requirements and fault characteristics of used products in the context of remanufacturing and translated them into design requirements. To identify the requirements, a similarity calculation based on cosine similarity was performed using a BERT model. This method was used to identify and merge requirements that were formulated differently but were semantically similar. In the railway industry, Reference BashirBashir (2024) uses BERT to identify requirements from extensive tender documents and allocate them to subsystems. The process model is domain-specific due to the large-scale nature of the industry. For requirement allocation, 15 correctly assigned requirements served as examples for BERT. Tests on real industry data showed significant reductions in processing time, fewer assignment errors, and improved traceability. To retrieve information from a large document repository within requirements management more quickly and efficiently, Reference Uygun and MomoduUygun and Momodu (2024) are developing a Q&A chatbot. For this purpose, a RAG is used, which enriches the LLM Nous-Hermes-13B-GPTQ with domain-specific information from a knowledge database, thereby improving requirements analysis. The chatbot can answer questions about documents from the automotive research sector. Due to the authors’ data protection concerns, the LLM is operated locally. Reference Schleifer, Lungu, Kruse, Van Putten, Goetz and WartzackSchleifer et al. (2024) developed a framework for structuring requirements and subsequently deriving use case diagrams from system requirements. Due to the lack of homogeneity of requirement sets in industry, rule-based approaches are only of limited suitability for the task. A potential analysis shows that NLP-supported assistance systems can achieve efficiency gains in requirements analysis and mapping. The usability of the developed framework has been verified with industry experts from the automotive industry, but no evaluation with real data has been carried out. Reference Riesener, Kuhn, Schümmelfeder, Xiao, Norheim, Rebentisch and SchuhRiesener et al. (2024) require a labelled data set for fine-tuning a named entity recognition (NER) model in the field of requirements management. To reduce the high manual effort involved in creation by requirements engineers, BERT is used for the automated analysis and classification of requirements. The requirements are processed sentence by sentence and the categories entity, action, attributes, relative operator and quantity are used for classification, as this structure reflects the typical structure of technical requirements. Using the automatic approach, the authors have succeeded in reducing the manual effort by more than 70%. Reference Gräßler, Oleff, Hieb and PreußGräßler et al. (2022) propose an AI-supported method for proactive management of requirement changes in complex technical systems. It combines NLP with graph-based approaches, using BERT to uncover semantic similarities between requirements and analyze dependencies. Based on these dependencies, a PageRank algorithm evaluates change impact and calculates change probability. The probability of a change is visually represented by node coloring in the graph. The authors also developed a prototype and tested it with real requirements from the automotive industry. Since the PageRank algorithm is not an AI but a graph-based algorithm, the task of change impact analysis and change probability assessment is not listed in Table 3 among the tasks of AI in the SE context. In order to identify requirement dependencies and more accurately recognize the classification of dependency types such as Requires, Refines, Refined by and Required by, Reference Gräßler, Oleff, Hieb and PreußGräßler et al. (2022) use a BERT model with active learning, known as active-BERT. The authors describe that both the quality and quantity of data are crucial success factors for establishing NLP solutions in requirements management. When merging requirements from different areas, there is a particular risk that semantically similar requirements will be formulated in different ways, making classification more difficult. Reference Gräßler, Preuß, Brandt and MohrGräßler et al. (2023) develop a method for automatic extraction and classification of requirements through data augmentation. Requirements from specification documents across three domains are manually classified into functional, non-functional, and unclassifiable. The LLM GPT-J then generates artificial requirements in these categories, which are manually checked and reclassified. However, combining real and augmented data negatively affected classification performance due to domain discrepancies. The authors conclude that artificially generated data is particularly helpful when domain-specific data is insufficient. Using a framework consisting of 18 standardised steps, Reference Dehn, Jacobs, Zerwas, Berroth, Hötter, Korten, Müller, Gossen, Striegel and FleischerDehn et al. (2023) systematically describe the possible use of artificial intelligence in the requirements engineering process. They define RE flow types, which function as data objects, and RE operations, which are applied to the data objects. The combination results in a total of 18 Elementary Process Steps (EPS), which can be represented as an input-output model. In addition, the authors provide a list of AI technologies for each process step. The list of recommended AI algorithms is not included in Reference Dehn, Jacobs, Zerwas, Berroth, Hötter, Korten, Müller, Gossen, Striegel and FleischerDehn et al. (2023) and no real-world application of the framework is described. Reference Van Remmen, Horber, Pickel, Goetz and WartzackVan Remmen et al. (2023) developed a framework to guide AI system design in requirements management. The framework identifies potential NLP applications by deriving NLP building blocks from literature and mapping them to Reference RuppRupp and Sophisten’s (2021) RE activities. It also integrates company-specific factors such as product typology and reference systems to provide implementation recommendations. The framework has been demonstrated only through an academic example, not yet validated in practice. Reference Van Remmen, Horber, Pickel, Goetz and WartzackVan Remmen et al. (2023) note that NLP potential increases with the number and complexity of requirements, thus growing as development progresses and requirements accumulate. Reference Bourdon, Rodriguez, Lesigne, Suchet, Fister, Montagne, Malhomme, Benmiloud-Bechet and PlanaBourdon et al. (2025) fine-tuned CurieLM, based on Mistral-7B-Instruct-v0.2, for nuclear engineering to automate requirements management tasks. Safety standards were used to generate specification reports and extract, classify, and structure requirements. Via a human–machine interface, engineers could apply INCOSE rules for reformulation, which the LLM executed and proposed for manual validation. While CurieLM occasionally misinterpreted or overapplied rules, human oversight ensured compliance. Requirement allocation followed a top-down subsystem approach, achieving the best results with low model temperature. In a case study, CurieLM reduced processing time by 88% for extraction, 87% for reformulation, and 66% for the Product Breakdown Structure, confirming the value of human-in-the-loop collaboration (Reference Bourdon, Rodriguez, Lesigne, Suchet, Fister, Montagne, Malhomme, Benmiloud-Bechet and PlanaBourdon et al., 2025). Reference Wang, Wang, Zhang, Ma, Shao and ChangWang et al. (2025) introduced an information extraction framework based on the five SysML requirement types: functional, interface, performance, physical, and design constraints. Unstructured requirement texts are pre-processed and analysed with ChatGPT-4, using few-shot learning to enhance accuracy. The extracted data form a knowledge graph revealing semantic relations between requirements. In a use case comparison, GPT-4 achieved 25% higher accuracy than BERT and 5% higher than GPT-3.5-turbo, improving overall traceability and requirement management. Reference Hovemann, Bita, Aldade, Von Heißen and DumitrescuHovemann et al. (2025) used the V-model to recommend advanced prompt engineering techniques for systems engineering activities. Four exemplary tasks were defined for each phase, and three use cases were implemented: AI-assisted correction of context diagrams, development of alternative system architectures, and derivation of test cases from requirements. The results, evaluated by experienced engineers, showed higher-than-expected quality. The study demonstrates that prompt engineering can add significant value to RE tasks with minimal effort, while further research is needed on task-specific adaptations.

4.3. Mapping to requirements engineering activities

To systematically analyze which RE activities receive AI support, the identified applications were mapped to Reference RuppRupp’s (2021) Requirements Engineering framework, which organizes RE activities into four main categories comprising specific sub-activities. Table 3 illustrates this mapping.

Table 3.

Mapping of identified publications to RE activities

The analysis reveals a clear concentration on specific RE activities, with four activities appearing in at least three references: determining requirements (4 references), analyzing and improving requirements (4 references), consolidating requirements (3 references), and establishing traceability (3 references). While Reference Bourdon, Rodriguez, Lesigne, Suchet, Fister, Montagne, Malhomme, Benmiloud-Bechet and PlanaBourdon et al. (2025) address five RE activities and Reference Wang, Wang, Zhang, Ma, Shao and ChangWang et al. (2025) cover three activities, two-thirds of the references focus on only a single RE activity. This pattern indicates that current AI solutions primarily target isolated RE tasks rather than providing comprehensive support across the RE process.