Skip to main content
UploadLanguage (EN)Support
BusinessMobileSocial MediaMarketingTechnologyArt & PhotosCareerDesignEducationPresentations & Public SpeakingGovernment & NonprofitHealthcareInternetLawLeadership & ManagementAutomotiveEngineeringSoftwareRecruiting & HRRetailSalesServicesScienceSmall Business & EntrepreneurshipFoodEnvironmentEconomy & FinanceData & AnalyticsInvestor RelationsSportsSpiritualNews & PoliticsTravelSelf ImprovementReal EstateEntertainment & HumorHealth & MedicineDevices & HardwareLifestyle
Lionel Briand, profile picture
Uploaded byLionel Briand
252 views

LLDriven Requirements Engineering: Automating Dependency Detection and Impact Analysis

Explores using large language models to automate dependency detection, impact analysis, and traceability in natural language requirements for functional safety standards in regulated domains such as automotive and aerospace. Invited presentation at the RE 2026 conference

Software◦
Downloaded 24 times
uOttawa.ca | nanda-lab.ca School of Electrical Engineering & Computer Science | Nanda Lab LLM-Driven Requirements Engineering: Automating Dependency Detection and Impact Analysis Lionel Briand, University of Ottawa and Lero Centre https://www.lbriand.info 18/08/2026
Context 1 • Functional safety standards, e.g., automotive (ISO 26262), aerospace (DO-178C), and medical devices (IEC 62304). • Requirements and bidirectional traceability. • Loose “shall” requirements in natural language • Every feature addresses identified safety goals and is thoroughly verified. • An audit trail proves that all risks are mitigated. • Regulatory compliance. • Change impact analysis. ISO 26262 Functional Safety V-Model
Challenges 2 • Requirements can be interconnected through various types of dependencies. • Requirements frequently change through the development lifecycle. • Natural language requirements are often ambiguous. • Systems usually have large numbers of requirements. • Consequence: High manual effort, requiring expertise, under tremendous pressure.
Large Language Models 2 • Interesting potential to alleviate these challenges. • Deep semantic reasoning across unstructured natural language. • Account for context, implicit intent, and domain-specific constraints. • Applications: - Automated trace link recovery. - Requirements Change Impact Analysis (CIA). - Regulatory compliance.
Presentation 2 • Detecting dependencies between requirements (with General Motors and Aptiv) - Among system requirements - Between stakeholder requirements and system requirements • Impact of requirements changes on other requirements • Legal traceability to support regulatory compliance • Requirements-driven test minimization • Reflections and future research
Identifying Dependencies between System Requirements 17 “LEREDD: LLM-Enabled Requirement Dependency Detection”, Darif et al. https://arxiv.org/abs/2602.22456
Requirement Dependency Types 3 • Requires: if the fulfillment of one requirement is a prerequisite to the fulfillment of the other requirement. Example: "When operators enable one-pedal driving without specifying intensity preference, the system shall return to the last selected intensity level, including levels from previous power cycles." requires "The system shall provide an accessible interface allowing operators to enable or disable one-pedal driving functionality while the vehicle is in Accessory, Run, or Propulsion power modes." • 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). Example: "Changes to intensity level selection at constant pedal position shall transition vehicle behavior at rates not exceeding 0.20g/s" implements "System operation shall appropriately adapt to challenging environmental conditions while maintaining safe and predictable behavior." • Conflicts: if the fulfillment of one requirement restricts the fulfillment of the other requirement. • Contradicts: if the two requirements are mutually exclusive, then the fulfillment of one requirement violates the other. • Details: if both requirements describe the same action under the same condition, and one requirement provides additional details specifically regarding the shared action. • Is similar: if one requirement replicates partially or totally the content of the other requirement, resulting in redundancy. • Is a variant: if one requirement serves as an alternative to the other
Literature Review - Gap 6 • Existing approaches for automatically detecting requirements dependencies exhibit various limitations: • Retrieval-based approaches (e.g., TF-IDF): are restricted to binary classification and rely on fixed representations, failing to account for domain-specific context • Knowledge-based approaches use ontologies or graphs to represent domain knowledge but require substantial effort for development and maintenance. • ML-based approaches (e.g., Fine-tuned BERT): require large training datasets and struggle with the class imbalance inherent in dependency detection, as independent requirements typically far outnumber dependent ones. • LLM-based approaches are particularly relevant for requirement dependency detection, as they leverage inferential reasoning based on external sources and information while enabling automation. Research on LLM-based requirement dependency detection is scarce and confined to specific dependency types.
Objectives 7 This research aims to • Develop an LLM-based approach to detecting requirements dependencies. • Perform a large-scale, realistic evaluation The approach should: • Support the automated detection of dependencies from natural language requirements. • Cover various types of dependencies. • Not be sensitive to the class imbalance problem in requirement dependencies.
Approach - LEREDD 8 We developed LEREDD: LLM-Enabled Requirements Dependency Detection, an LLM-based dependency detection approach that automatically identifies direct dependencies between pairs of requirements. RAG for domain-related context retrieval ICL for task-related context retrieval - On a 5-point Likert scale - Improves results interpretability - Enables threshold analysis - Enhances LLM reasoning capabilities - Reveals LLM reasoning to easily trace and correct errors.
LEREDD : Evaluation Datasets 9 The evaluation of LEREDD covers 5 datasets (Automotive domain). Public datasets (Michigan State U. + industry) of automotive systems Industrial datasets of GM systems. Adaptive Driving Beam system • 413 requirement pairs • 5 dependency types Note: The ground truth (GT) of the public datasets was manually constructed and cross-validated by two researchers. It underwent several validation rounds to ensure its accuracy. Traffic Jam Assist system • 200 requirement pairs • 4 dependency types Active Park Assist system • 200 requirement pairs • 5 dependency types One Pedal system • 666 requirement pairs • 4 dependency types Traction Control system • 1485 requirement pairs • 4 dependency types
Public Datasets: Experiments with LEREDD 15 • 813 requirement pairs. • More than 400 experiments to assess different parameter configurations, prompting strategies, and comparisons with established baselines for requirements dependency detection. ✓ LEREDD achieved high overall F1-scores, ranging from 0.86 to 0.94. ✓ While LEREDD performs well on specific dependency types (with F1-scores above 0.70), its true strength lies in detecting non-dependent requirements, where it consistently yields F1-scores above 0.90 across all experiments. ✓ By effectively filtering non-dependent cases, LEREDD can substantially reduce the analysts’ overhead for dependency analysis as these cases account for the vast majority of requirement pairs.
Public Datasets: Comparison Against Baselines 16 LEREDD was evaluated against two baseline approaches: • TF-IDF & LSA: a retrieval-based approach that identifies requirement dependencies based on semantic similarity. • Fine-tuned BERT: A supervised ML-based approach trained on annotated requirement pairs (80%) and evaluated on the remaining 20%. Results below are based on these 20% (low support). ✓ LEREDD outperformed both baselines in overall accuracy, precision, recall, and F1-score (>0.87 in all experiments). ✓ LEREDD achieved higher F1-scores for No dependency and nearly all specific dependency types (by as much as a 40% increase in F1). ✓ The low F1 scores of LEREDD for certain dependency types is attributed to the extremely low support (e.g., 2 instances of conflicts in D1).
Conclusions 17 • LEREDD accurately identifies most independent requirement pairs. • This makes it cost-effective to maintain consistency across requirements and, in turn, requirements quality. • LEREDD fares much better than existing alternatives based on information retrieval and supervised learning (less practical). • Rare dependency types are difficult to predict, though. But LEREDD fares better in that respect too (F1 > 0.70). • Selecting the right dependency type is also difficult for human experts, as it is for the LLM.
Requirements Change Impact Analysis 17 “LLM-Driven Cost-Effective Requirements Change Impact Analysis”, Etezadi et al. https://arxiv.org/abs/2511.00262
Objectives 17 • Which requirements are likely to be affected by a change in requirements or a change request? • Can LLMs help account for implicit or semantic dependencies? • Only one study (2015) on inter-requirement CIA. • No use of recent NLP techniques. • Our approach: ProReFiCIA (Prompt-Refinement-Filtering for CIA)
Examples 17
Case Studies 17 We use WASP and SAT-DLink to find the best model-prompt combination (Exploration). SAT-DLink-Test is used as our test set and for comparison against baselines.
ProReFiCIA 17
Prompt Design 17 RICE template: • Role • Instruction • Context • Example • 64 Prompt variants (combinations of details 1-7) • 5 LLMs • Best combination?
ProReFiCIA 17 Lost-in-the-middle problem Reconsider shortened list of requirements that were not selected in the initial LLM execution Rank requirements according to confidence in impact NLI model determines whether a requirement entails the change rationale Combine with heuristic
Results (SAT-D-Link) 17 • Low cost (proportion of requirements per change rationale). • Refinement improves effectiveness (recall) at a higher cost. • Filtering helps reduce cost. • On average, the analyst can identify 85.7% of the impacted requirements by examining just 3% of the total set of requirement pairs. • Not perfect, but much more cost-effective than baselines.
General Conclusions from our Studies 17 • Many frequently changing LLMs to consider. • Small prompt changes can lead to significant differences in results. • Selection of examples in few-shot, domain information in context. • Combination with heuristics. • All these factors lead to extensive experimentation for a given task – there are guidelines but little theory to guide us. • Encouraging results but room for improvement. Good enough in a safety-critical context?
Research Avenues 17 • Multi-agent architectures: Decomposing complex requirements engineering workflows into specialized multi- agent teams (e.g., specialized extraction, reasoning, verification, and critique agents). • Close-loop validation with humans: coordination, conflict resolution, and convergence. • Knowledge-graph-enhanced RAG. • Assessing rationale generation with experts. • Fine-grained impact bounds to minimize the cost of CIA. • Better benchmarks. • Audit-Grade Rationale Generation: Certification authorities require complete transparency. Generating verifiable, step-by-step reasoning chains that justify why a link exists, why a change impacts a component, or how a requirement satisfies a regulatory clause is crucial for human-in-the-loop validation. • Under standards like DO-330 / ISO 26262-8, software tools used in development or verification must undergo tool qualification. Qualifying non-deterministic, deep neural architectures as trusted verification artifacts presents a major regulatory hurdle.
References 17 Etezadi, Abualhaija, Arora, Briand, “Classifier or Prompt: A Case Study on Legal Requirements Traceability”, Empirical Software Engineering (Springer), 2026 Pan, Niu, Briand, Hu, “Requirements Coverage-Guided Minimization for Natural Language Test Cases”, ACM TOSEM, 2026. Etezadi, Abualhaija, Arora, Briand, “LLM-Driven Cost-Effective Requirements Change Impact Analysis”, Accepted for publication in ACM Transactions on Software Engineering (TOSEM), ArXiv https://arxiv.org/abs/2511.00262, Darif, Niu, Abdelatif, Briand, Ramesh, Adiththan, “Automating the Detection of Requirement Dependencies Using Large Language Models”, ArXiv https://arxiv.org/abs/2602.22456 Niu, Pan, Briand, Hu, “TVR: Automotive System Requirements Traceability Validation and Recovery Through Retrieval-Augmented Generation”, ArXiv https://arxiv.org/abs/2504.15427
uOttawa.ca | nanda-lab.ca School of Electrical Engineering & Computer Science | Nanda Lab LLM-Driven Requirements Engineering: Automating Dependency Detection and Impact Analysis Lionel Briand, University of Ottawa and Lero Centre https://www.lbriand.info 18/08/2026