Organizations: University of Ottawa, Ottawa, Canada. · École de technologie supérieure, Montreal, Canada. · Research Ireland Lero Centre for Software Research, University of Limerick, Ireland. · General Motors, Detroit, Michigan, United States.
Requirements are inherently interconnected through various types of dependencies. Identifying these dependencies is essential, as they underpin critical decisions and influence a range of activities throughout software development. However, this task is challenging, particularly in modern software systems, given the high volume of complex, coupled requirements. These challenges are further exacerbated by the ambiguity of Natural Language (NL) requirements and their constant change. Consequently, requirement dependency detection is often overlooked or performed manually. Large Language Models (LLMs) exhibit strong capabilities in NL processing, presenting a promising avenue for requirement-related tasks. While they have shown to enhance various requirements engineering tasks, their effectiveness in identifying requirement dependencies remains unexplored. In this paper, we introduce LEREDD, an LLM-based approach for automated detection of requirement dependencies that leverages Retrieval-Augmented Generation (RAG) and In-Context Learning (ICL). It is designed to identify diverse dependency types directly from NL requirements. We empirically evaluate LEREDD against two state-of-the-art baselines. The results show that LEREDD provides highly accurate classification of dependent and non-dependent requirements, achieving an accuracy of 0.93, and an F1 score of 0.84, with the latter averaging 0.96 for non-dependent cases. LEREDD outperforms zero-shot LLMs and baselines, particularly in detecting fine-grained dependency types, where it yields average relative gains of 94.87% and 105.41% in F1 scores for the Requires dependency over the baselines. We also provide an annotated dataset of requirement dependencies encompassing 813 requirement pairs across three distinct systems to support reproducibility and future research.
Figures & tables
Dependency Type
Definition
Example
Requires
if the fulfillment of one requirement is a prerequisite to the fulfillment of the other requirement.
“If a car in an oncoming lane is within 500 feet of the ADB system, or a car in the same lane is within 250 feet, the subsystem shall decrease light intensity by 50%.” requires “The subsystem shall check for cars and road elements every 10 milliseconds and determine whether the subsystem shall decrease light intensity.”
Implements
if one is a higher-level requirement (e.g., a system or subsystem level requirement) that is fulfilled by the other lower-level requirement (e.g., a subsystem or component level requirement).
“The system shall verify communication between subsystems.” implements “The subsystem shall have checks to mitigate the chances of a cybersecurity attack.”
Conflicts
if the fulfillment of one requirement restricts the fulfillment of the other requirement.
“The system shall not irritate the driver with more than 3 updates or alerts in 10 minutes for the system.” conflicts with “The system shall alert the driver if any malfunctions or errors have been detected within 5 seconds.”
Details
if both requirements describe the same action under the same condition, and one requirement provides additional details specifically regarding the shared action.
“The system shall respond to the surroundings around it in less than 2.5 seconds by dimming the light intensity 50%.” details “The system shall gradually change the light intensity to ensure a smooth operation for the driver by decreasing the intensity of the light by no greater than 50% in one update.”
Is similar
if one requirement replicates partially or totally the content of the other requirement, resulting in redundancy.
“The system shall authenticate updates.” is similar to “The system shall verify the source of the update.”
TABLE I : Dependency Types Definitions and Illustrative Examples
Fig. 1 : LEREDD Framework.
Fig. 2 : Dependency Inference Prompt.
Dependency Type
ADB
TJA
APA
Total
Pilot study
Evaluation
# Requirements
100
313
200
200
813
Conflicts
1
10
-
4
15
Details
2
13
2
1
18
Implements
6
18
10
3
37
Is similar
-
3
1
3
7
TABLE II : Distribution of Requirement Dependency Types
LLM
Dependency
D1
D2
D3
Type
Acc
P
R
F1
Acc
P
R
F1
Acc
P
R
F1
GPT
No Dep
0.78 ± 0.01
0.89 ± 0.01
0.88 ± 0.00
0.88 ± 0.00
0.82 ± 0.00
0.96 ± 0.00
0.88 ± 0.00
0.92 ± 0.00
0.66 ± 0.01
0.93 ± 0.00
0.71 ± 0.02
0.80 ± 0.01
Requires
0.36 ± 0.01
0.44 ± 0.03
0.40 ± 0.02
0.39 ± 0.04
0.61 ± 0.06
0.47 ± 0.05
0.46 ± 0.02
0.62 ± 0.04
0.53 ± 0.01
Implements
0.57 ± 0.08
0.64 ± 0.07
0.60 ± 0.08
0.33 ± 0.05
0.40 ± 0.00
0.36 ± 0.03
0.07 ± 0.01
0.56 ± 0.16
0.13 ± 0.03
Conflicts
0.47 ± 0.05
0.22 ± 0.00
0.30 ± 0.01
N/A
N/A
N/A
0.67 ± 0.47
0.17 ± 0.12
0.27 ± 0.19
Details
0.25 ± 0.00
0.20 ± 0.00
0.22 ± 0.00
0.00 ± 0.00
0.00 ± 0.00
0.00 ± 0.00
0.00 ± 0.00
0.00 ± 0.00
0.00 ± 0.00
TABLE III : Experimental Results of Zero-Shot LLMs
Examples
BGE
SBERT
Cosine
Euclidean
Cosine
Euclidean
Avg
Max
Avg
Max
Avg
Max
Avg
Max
1
0.84 ± 0.01
0.83 ± 0.02
0.81 ± 0.01
0.83 ± 0.00
0.80 ± 0.01
0.81 ± 0.01
0.82 ± 0.02
0.81 ± 0.02
2
0.88 ± 0.01
0.87 ± 0.01
0.85 ± 0.01
0.88 ± 0.01
0.87 ± 0.01
0.91 ± 0.01
0.88 ± 0.02
0.88 ± 0.01
3
0.91 ± 0.01
0.89 ± 0.01
0.88 ± 0.02
0.89 ± 0.00
0.89 ± 0.00
0.92 ± 0.01
0.90 ± 0.00
0.90 ± 0.02
4
0.90 ± 0.00
0.87 ± 0.00
0.91 ± 0.00
0.90 ± 0.02
0.91 ± 0.00
0.91 ± 0.00
0.89 ± 0.01
0.88 ± 0.01
TABLE IV : Results of Few-shot Prompting for Configuration Selection with threshold-based re-annotation
Fig. 3 : F1 score Comparison of Few-shot Configurations
Metric
2 Chunks
6 Chunks
10 Chunks
Entire Doc
500c
1000c
500c
1000c
500c
1000c
Acc
0.96 ± 0.00
0.96 ± 0.01
0.97 ± 0.00
0.97 ± 0.00
0.96 ± 0.01
0.97 ± 0.00
0.96 ± 0.01
P
0.96 ± 0.00
0.97 ± 0.00
0.96 ± 0.00
0.97 ± 0.00
0.96 ± 0.00
0.97 ± 0.00
0.96 ± 0.00
R
0.96 ± 0.00
0.96 ± 0.01
0.97 ± 0.00
0.98 ± 0.00
0.95 ± 0.01
0.97 ± 0.00
0.95 ± 0.01
F1
0.96 ± 0.00
0.96 ± 0.00
0.97 ± 0.00
0.97 ± 0.00
0.96 ± 0.00
0.97 ± 0.00
0.96 ± 0.00
TABLE V : Experimental Results of RAG-based Contextual Augmentation
Dataset
Dependency
Zero-shot
Few-shot
Few-shot & RAG
Supp
Type
Acc
P
R
F1
Acc
P
R
F1
Acc
P
R
F1
D1
No Dep
0.75 ± 0.00
0.87 ± 0.00
0.86 ± 0.00
0.86 ± 0.00
0.91 ± 0.00
0.93 ± 0.00
0.97 ± 0.00
0.95 ± 0.00
0.91 ± 0.00
0.93 ± 0.00
0.97 ± 0.00
0.95 ± 0.00
229
Requires
0.34 ± 0.02
0.40 ± 0.02
0.37 ± 0.01
0.91 ± 0.00
0.73 ± 0.01
0.81 ± 0.01
0.90 ± 0.01
0.73 ± 0.01
0.81 ± 0.00
40
Implements
0.60 ± 0.03
0.70 ± 0.05
0.64 ± 0.01
0.73 ± 0.02
0.80 ± 0.03
0.76 ± 0.02
0.75 ± 0.01
0.87 ± 0.03
0.80 ± 0.01
18
Details
0.62 ± 0.09
0.41 ± 0.10
0.49 ± 0.08
1.00 ± 0.00
0.79 ± 0.04
0.89 ± 0.02
0.94 ± 0.05
0.74 ± 0.04
0.83 ± 0.04
10
Conflicts
0.53 ± 0.05
0.30 ± 0.00
0.38 ± 0.01
0.86 ± 0.00
0.60 ± 0.00
0.71 ± 0.00
0.94 ± 0.08
0.50 ± 0.00
0.65 ± 0.02
13
TABLE VI : Comparison of Different Prompting Strategies Across Three Systems
Dataset
Confidence score
Zero-shot
Few-shot
Few-shot & RAG
D1
5
59%
97%
95%
4
36%
3%
4%
D2
5
63%
98%
96%
4
36%
2%
4%
D3
5
35%
98%
97%
4
58%
2%
2%
TABLE VII : Comparison of Confidence Scores of Different Prompting Strategies Across Three Datasets
System
Dependency
TF-IDF & LSA
fine-tuned BERT
LEREDD
Supp
Type
Acc
P
R
F1
Acc
P
R
F1
Acc
P
R
F1
D1
No Dep
0.68
0.88
0.73
0.80
0.87
0.93
0.93
0.93
0.88 ± 0.01
0.92 ± 0.01
0.94 ± 0.02
0.93 ± 0.01
48
Requires
0.19
0.38
0.25
0.86
0.75
0.80
0.83 ± 0.02
0.62 ± 0.10
0.71 ± 0.08
8
Implements
N/A
N/A
N/A
0.50
0.67
0.57
0.70 ± 0.07
1.00 ± 0.00
0.82 ± 0.05
3
Details
N/A
N/A
N/A
0.67
0.67
0.67
1.00 ± 0.00
0.67 ± 0.00
0.80 ± 0.00
3
Conflicts
N/A
N/A
N/A
0.50
0.50
0.50
0.44 ± 0.08
0.50 ± 0.00
0.47 ± 0.05
2
TABLE VIII : Experimental Results of LEREDD Against Baselines for Intra-Dataset Evaluation across Three Systems
Training
Testing
Dependency
TF-IDF & LSA
fine-tuned BERT
LEREDD
LEREDD with RAG
Supp
Type
Acc
P
R
F1
Acc
P
R
F1
Acc
P
R
F1
Acc
P
R
F1
D2
D1
No Dep
0.70
0.86
0.76
0.81
0.67
0.84
0.79
0.82
0.84 ± 0.01
0.86 ± 0.00
0.98 ± 0.00
0.92 ± 0.00
0.86 ± 0.00
0.87 ± 0.01
0.98 ± 0.00
0.92 ± 0.00
229
Requires
0.18
0.30
0.23
0.16
0.28
0.20
0.68 ± 0.11
0.21 ± 0.03
0.32 ± 0.05
0.83 ± 0.06
0.27 ± 0.01
0.40 ± 0.01
40
Implements
N/A
N/A
N/A
0.00
0.00
0.00
0.64 ± 0.04
0.48 ± 0.03
0.55 ± 0.03
0.72 ± 0.03
0.67 ± 0.05
0.69 ± 0.03
18
Overall
0.76
0.69
0.72
0.69
0.67
0.68
0.82 ± 0.02
0.84 ± 0.01
0.81 ± 0.01
0.85 ± 0.01
0.86 ± 0.01
0.83 ± 0.01
287
D3
D1
No Dep
0.70
0.86
0.76
0.81
0.35
0.88
0.28
0.42
0.89 ± 0.00
0.91 ± 0.00
0.97 ± 0.00
0.94 ± 0.00
0.90 ± 0.00
0.91 ± 0.00
0.98 ± 0.00
0.94 ± 0.00
229
TABLE IX : Experimental Results of LEREDD Against Baselines for Cross-Dataset Evaluation across Three Datasets
Requirements engineering is a vital, yet labor-intensive, stage in the software development process. This article introduces ReqFusion: an AI-enhanced system that automates the extraction, classification, and analysis of software requirements utilizing multiple Large Language Model (LLM) providers. The architecture of ReqFusion integrates OpenAI GPT, Anthropic Claude, and Groq models to extract functional and non-functional requirements from various documentation formats (PDF, DOCX, and PPTX) in academic, industrial, and tender proposal contexts. The system uses a domain-independent extraction method and generates requirements following the Project, Environment, Goal, and System (PEGS) approach introduced by Bertrand Meyer. The main idea is that, because the PEGS format is detailed, LLMs have more information and cues about the requirements, producing better results than a simple generic request. An ablation study confirms this hypothesis: PEGS-guided prompting achieves an F1 score of 0.88, compared to 0.71 for generic prompting under the same multi-provider configuration. The evaluation used 18 real-world documents to generate 226 requirements through automated classification, with 54.9% functional and 45.1% nonfunctional across academic, business, and technical domains. An extended evaluation on five projects with 1,050 requirements demonstrated significant improvements in extraction accuracy and a 78% reduction in analysis time compared to manual methods. The multi-provider architecture enhances reliability through model consensus and fallback mechanisms, while the PEGS-based approach ensures comprehensive coverage of all requirement categories.
Muhammad Khalid, Manuel Oriol, Yilmaz Uygun
Constructor University Bremen, 28759 Bremen, Germany
Natural language requirements (NLRs) are essential for bridging communication gaps among diverse stakeholders in software development. However, the inherent ambiguity in NLRs can pose significant challenges. In particular, some requirements may be misinterpreted due to varying contextual knowledge and domain-specific expectations of the stakeholders, a phenomenon known as pragmatic ambiguity. This paper presents an approach for detecting and resolving pragmatic ambiguities in NLRs. The approach leverages retrieval-augmented generation techniques with novice, intermediate, and expert domain knowledge bases to simulate stakeholders with varying domain expertise and detect discrepancies in requirement interpretation. Candidate disambiguated requirements are generated using the expert domain knowledge base, with final validation by a requirements analyst required to ensure alignment with the intended functionality. We evaluate the approach on two requirements specification documents from the PUblic REquirements dataset, using four large language models: GPT-4o-mini, Mistral-7B, Llama-3.1-8B, and Qwen2.5-7B. Detection performance is assessed using macro-averaged accuracy, precision, recall, F1, and F2 scores. The resolution quality of the candidate disambiguated requirements is measured through human evaluation of relevance, clarity, and consistency. In this initial evaluation, results show that the proposed approach can detect pragmatic ambiguities and produce candidate disambiguated requirements that are relevant, clear, and consistent with the intended system functionality. Among the evaluated models, GPT-4o-mini achieved the highest macro-averaged recall (0.75) and F2 score (0.75) for pragmatic ambiguity detection. In the resolution task, GPT-4o-mini received the highest relevance scores from human evaluators, while Mistral-7B achieved the highest scores for clarity and consistency.
Modern LLM training pipelines increasingly rely on other models to generate data, filter corpora, judge outputs, and guide development decisions. These dependencies are recursive: a model may depend on an upstream artifact whose own dependencies are documented only in separate releases and artifacts. As a result, the full dependency structure is fragmented across heterogeneous public artifacts, with complexity and recursive depth far outpacing humans' ability to trace. We introduce ModSleuth, an agentic system that recursively reconstructs LLM dependency graphs from public artifacts with source-grounded evidence. We find that the primary challenge is no longer information extraction, but defining what constitutes a dependency and reconciling artifact references across inconsistent documentation. We address these challenges through a formalization that distinguishes direct and indirect dependencies, represents heterogeneous pipeline roles through operation-centered relationships, and resolves artifact identities across names, versions, and repositories. Applying ModSleuth to four public-artifact-rich LLM releases, we recover 1,060 source-verified dependencies and construct large-scale dependency graphs of modern LLM development. These graphs reveal multi-hop license obligations, train-evaluation coupling, discrepancies between released and training-time artifacts, and documentation inconsistencies that would otherwise be difficult to uncover. We release ModSleuth and the resulting dependency graphs to support transparent analysis of the increasingly complex ecosystems underlying modern LLMs.
Sanjay Adhikesaven, Haoxiang Sun, Sewon Min
University of California, Berkeley · Allen Institute for AI