Skip to content
Gytis Gurklys

Requirements engineering digest, week 35 of 2026

24-30 August 2026
Automatic
  1. On the Time and Frequency Domain Representations of Signals for CPS Specification

    Claudio Mandrioli, Drishti Yadav, Domenico Bianculli

    arXiv (cs.SE) · preprint

    Most specification languages for cyber-physical systems describe signals in the time domain, which is a poor fit for shapes and dynamic behaviour that control and robotics describe in the frequency domain. The authors work out which classes of CPS requirement would gain from a time-frequency representation, propose Signal-Spectrum Temporal Logic for assertions over frequency intervals, and implement a monitor. Time-frequency specifications extend to traces built by linear interpolation and tolerate offset and high-frequency noise better.

    Abstract
    Specification languages are instrumental to the Verification \& Validation of Cyber-Physical Systems (CPSs). Most state-of-the-art specification languages use the time-domain representation of signals, which is not always suitable for describing signal shapes and dynamic behaviours. Instead, fields like control and robotics use the frequency-domain representation to characterise these behaviours. Time-frequency representations combine the capabilities of both domains. We investigate the use of time-frequency representations to specify CPS requirements. We analyse existing taxonomies of CPS requirements to identify which requirement classes can benefit from time-frequency representations. We derive the desiderata for a specification language that uses time-frequency representations and propose Signal-Spectrum Temporal Logic (S2TL), a language enabling assertions over frequency intervals and relations between frequency components. We operationalise the S2TL semantics for monitoring CPS traces, and implement a monitor. We define specification templates for the identified requirement classes and compare time- and time-frequency-domain formulations in terms of applicability, expression fidelity, and noise tolerance of monitoring. We observe that, while time-domain specifications are applicable only to input traces containing step-like changes or using constant interpolation, time-frequency specifications extend their evaluation to traces generated through linear interpolation, and improve tolerance to offset and high-frequency noise, while achieving comparable fidelity to the intended system properties.

    Source: arxiv.org/abs/2608.21167

  2. Human-AI Collaboration in Requirements Engineering: Evidence of the Negative Effect of LLMs on Requirements Inspection

    Giovanna Broccia, Julian Frattini, Chetan Arora, Maurice H. ter Beek, Alessandro Fantechi, Andreas Vogelsang, Alessio Ferrari

    arXiv (cs.SE) · preprint

    A crossover experiment with 34 participants inspecting textual specifications with and without a language model at their side. LLM support made smell detection less accurate, changed neither the severity classification nor the time taken, and, where inspection was learned with the model from the start, appeared to slow the skill down. Evidence that the assistant is not automatically an improvement, and may cost a novice inspector something they were trying to acquire.

    Abstract
    Background. Requirements inspection (RI) is a well-established practice for detecting potential defects in requirements artifacts early in the software lifecycle. Recent advances in large language models (LLMs) have stimulated interest in their potential to support requirements engineering (RE) tasks. However, empirical evidence on the effects of LLMs when used as collaborative assistants in human-performed RI remains scarce. Aims. We aim to investigate the impact of LLM support on human-performed RI, considering inspection effectiveness in terms of smell identification and severity classification (i.e., nocuous vs innocuous), as well as inspection duration. Method. We conducted a controlled crossover design experiment with 34 participants, who inspected textual specifications with and without LLM support, identifying and classifying requirements smells while recording inspection time. We analyzed the data using one Bayesian regression model per outcome variable, accounting for validity threats induced by the crossover design as well as covariates and mediators. Results. Results show that LLM support negatively affects smell detection accuracy but has no significant effect on smell classification or task duration. A learning effect is present across experimental periods, but reduced when RI is first performed with LLM support. Conclusions. Our findings provide empirical evidence that LLM support does not necessarily improve performance and may, instead, hinder it for novice inspectors. Moreover, the results suggest that learning RI with LLM-support from the beginning may slow down the skill acquisition process, implying threats for LLM-supported learning.

    Source: arxiv.org/abs/2608.21298

  3. SLICE: Specification-Level Isolation of Contract Enforcement

    Soohan Lim, Hyundong Jin, Yo-Sub Han

    arXiv (cs.SE) · preprint

    A problem specification states both what a function must compute and what its inputs must satisfy, and generators tend to honour one at the expense of the other. SLICE separates the two: it grounds the contract conditions in a specification graph, strips them out to leave a functional view, generates and ranks candidate bodies against that, then generates input-validation assertions from the contract and attaches them. An average 6.58% gain over the strongest baseline per model on ContractEval.

    Abstract
    Programming problems commonly specify both the computation a function should perform and the conditions that its inputs must satisfy. Large language models are widely used to generate code from these problem specifications, and the generated function must implement the required computation while enforcing the stated input conditions. The stated input conditions collectively form an input contract. Enforcing this contract is difficult: incomplete enforcement accepts inputs that should be rejected, whereas overly restrictive enforcement rejects inputs that should be accepted. Existing code generation methods do not provide a generation process that identifies both the input contract and the functional requirements and generates code that satisfies them jointly. We therefore introduce SLICE, a generation framework that identifies both requirements and addresses them through separate generation stages. SLICE consists of three stages: (i) Graph-based specification structuring, which grounds contract conditions to description segments in a specification graph and removes contract-only segments to form a functional view; (ii) Functional body generation, which produces multiple candidate function bodies through greedy and sampled decoding, ranks them using execution scores, and resolves ties using difference-region log probabilities; and (iii) Contract assertion generation, which generates input-validation assertions from the identified contract conditions and attaches them to the selected function body. We evaluate SLICE on ContractEval across four LLMs and compare it with six competing methods. Relative to the strongest evaluated baseline for each model, SLICE improves performance in generating code that satisfies both the functional requirements and the input contract by an average of 6.58%. Our code is available at this https URL.

    Source: arxiv.org/abs/2608.21483

  4. Large Language Models for Requirements Engineering: A Cross-Task Empirical Evaluation

    Jacek Dąbrowski, Manjeshwar Aniruddh Mallya, Alessio Ferrari, Mohammad Amin Zadenoori, Yijun Yu

    arXiv (cs.SE) · preprint

    Two studies that together cover five requirements engineering activities: a controlled experiment on five lightweight open-source models for feedback-driven classification and specification generation, and an industrial case study on two frontier models for traceability link identification and traceability explanation, on real project artefacts. Performance is strongly task-dependent and no model wins across the board, so the choice of model and prompting strategy has to be made per task.

    Abstract
    Requirements-related information is scattered across heterogeneous artefacts such as user feedback, developer discussions, and software repositories, making the extraction of actionable requirements knowledge labour-intensive and hard to scale. Large Language Models (LLMs) can support many Requirements Engineering (RE) activities, from classification and traceability identification to specification and explanation generation, but existing evidence is fragmented across tasks, artefact types, and evaluation settings, and studies rarely offer cross-task evaluations or replication packages. We present two complementary empirical studies evaluating LLMs across five RE-related activities. The first is a controlled experiment on five lightweight open-source LLMs for feedback-driven requirements classification and specification generation. The second is an exploratory industrial case study on two frontier LLMs for traceability link identification and traceability explanation generation using real project artefacts. Classification and traceability identification were assessed with quantitative metrics, and generation tasks through human evaluation. LLM performance is strongly task-dependent, ranging from moderate to high, and no single model consistently outperformed the others, indicating that effective adoption depends on selecting models and prompting strategies per task. Our contributions are: (i) the first cross-task empirical evaluation of LLMs spanning five RE-related activities, (ii) replication materials supporting reproducibility, and (iii) a broader understanding of the capabilities, limitations, and practical readiness of current LLMs for RE.

    Source: arxiv.org/abs/2608.21531

  5. Ontology-based Requirements Transformation

    Jan Novacek, Alexander Viehl, Oliver Bringmann, Wolfgang Rosenstiel

    arXiv (cs.SE), originally published at ISSE 2019 · published

    An ontology-based method for transforming the functional and environmental load requirements carried in Mission Profiles along a supply chain, expressed in OWL so that it integrates with model-based systems engineering and travels between heterogeneous tools. It also allows the parts of a Mission Profile that a supplier does not need to be stripped off before it is passed on, which is as much an intellectual property measure as an engineering one.

    Abstract
    This paper presents an ontology-based approach to the supply chain-aware transformation of functional and environmental load requirements given by so-called Mission Profiles (MPs). The approach aims at improving the efficiency of the engineering process through supporting the transformation process and enabling a better integration of the transformation into existing Model-based Systems Engineering (MBSE) processes. We propose a methodology and a supporting system which aids in the transformation process while the latter feature is obtained by constructing and working on models. Consequent utilization of the standardized language OWL to express model representations further enables better knowledge integration and transfer among hetero-geneous systems. In addition to that, this favors knowledge reuse across projects which can reduce overall costs. Moreover, the system enables stripping off irrelevant information from MPs, thus improving protection of intellectual property.

    Source: arxiv.org/abs/2608.21945

  6. Ontology-supported Design Parameter Management for Change Impact Analysis

    Jan Novacek, Ali Ahari, Alessandro Cornaglia, Frederik Haxel, Alexander Viehl, Oliver Bringmann, Wolfgang Rosenstiel

    arXiv (cs.SE), originally published at Euromicro SEAA 2018 · published

    Manages design parameters through an ontology so that change impact analysis can run over requirements traceability and captured expert knowledge, for hardware designs as much as software ones. It is assembled from a universal system modelling procedure for integrating models, a knowledge base holding what the experts know about the parameters, and a Mission Profile aware design platform, with OWL as the representation throughout.

    Abstract
    This paper presents an ontology-supported approach to the management of design parameters in engineering. This approach aims specifically at enabling Change Impact Analysis through Requirements Traceability and acquainted expert knowledge of design parameters. The approach is suitable for both software and hardware designs. The activities and features are mainly obtained by (1) the application of an ontology-based universal system modeling procedure proposal for model integration, (2) the utilization of a knowledge base for capturing expert knowledge and (3) a semantic Mission Profile Aware Design platform. OWL is used to represent information and the underlying data model can improve knowledge transfer among heterogeneous systems which are common in complex engineering projects. At the same time, effort to perform reasoning on such models can be reduced. A demonstration and hands-on description of two illustrative use cases complements the paper.

    Source: arxiv.org/abs/2608.21949

  7. An Interactive Agent for Requirement-Driven Candidate Sourcing

    Yuanpeng He, Fangjing Li, Xiangyu Ru, Kexin Sun, Kun Yang, Lijian Li, Chi-Man Pun, Qingsong Wen, Wenpin Jiao, Mingkai Guo, Yirong Feng, Daiheng Gao, Zhi Jin

    arXiv (cs.SE) · preprint

    Argues that finding people from a natural-language description is not an information retrieval problem but a requirements one: the request is under-determined, carries implicit constraints, admits many valid answers and has no acceptance criterion, so it has to be elicited, validated and verified before searching means anything. The agent does that through bounded elicitation, workflow templates and a two-stage commit protocol, and of the people it returns, 90% are surfaced by none of twenty strong baselines combined.

    Abstract
    Finding people from a natural-language description (“ML engineers transitioning to research roles in biotech”) is increasingly delegated to LLM agents and framed as information retrieval. We argue that it is fundamentally a requirements engineering task: such a request is an under-determined requirement with implicit constraints, many valid answers, and no acceptance criterion, so useful answers require eliciting, validating, and verifying the requirement before search can matter. We present DINQ TalentScout, to our knowledge the first interactive, requirements-driven candidate-sourcing agent (it elicits, validates, retrieves, and verifies a vague people-request into a justified slate through bounded elicitation, workflow templates, a two-stage commit protocol, and bidirectional termination guards) and TalentTrace, a benchmark that runs the requirements lifecycle (criteria-anchored validation, multi-model evidence-grounded oracle construction, and cost-aware verification). Across 21 systems and all 691 requirements, DINQ TalentScout dominates breadth (100% coverage at 2.5× the yield) and is near-orthogonal to the field, with 90% of the people it returns are surfaced by none of 20 strong LLM-plus-web baselines combined. Beyond breadth, an evidence-grounded judging of every system shows DINQ TalentScout recalls the most relevant real people: 0.241 of the union pool, 1.9× the next system, with a bootstrap 95% interval disjoint from every baseline. DINQ TalentScout is thus the strongest sourcing engine (the deepest real, reachable candidate pool), while precision-ranking LLMs serve as complementary verifiers.

    The source publishes this abstract as raw markup. Macros have been replaced by the text the publisher's own rendering shows for them, and the rest of the markup removed. The authors' wording is unchanged.

    Source: arxiv.org/abs/2608.23501

  8. Secret MCP: Evidence-Bounded and Context-Isolated Design Specification Generation from Web Screenshots

    Yeongjin Jo

    arXiv (cs.SE) · preprint

    Screenshot-to-code systems optimise for what renders, dropping the document structure, interaction logic, responsive rules and provenance that separate what was measured from what was guessed. Secret MCP produces one auditable design specification per web reference instead, against a 19-section contract that covers page inventories, responsive matrices, accessibility and acceptance criteria, and labels every claim as measured, observed, inferred or unknown, with each reference processed in isolation from the others.

    Abstract
    Screenshot-to-code systems optimize for rendered implementations, but screenshots omit document structure, interaction logic, responsive rules, and provenance needed to distinguish observation from guesswork. Multi-reference prompts also risk contaminating one reference with evidence or inferences from another. We present Secret MCP, an open-source local system that produces one auditable design specification per public web reference. It separates retrieval, evidence preparation, model invocation, storage, and inspection. Long captures are resized and tiled with overlap; evidence records preserve prepared- and source-space coordinates and a measured color palette. A 19-section contract covers page inventories, navigation geometry, responsive matrices, components, accessibility, acceptance criteria, and explicit labels for measured, observed, inferred, and unknown claims. References are processed sequentially through a sampler interface. The evaluated MCP adapter sends one sampling/createMessage request per reference with includeContext set to none; a fresh-process adapter provides a stronger boundary. We evaluate commit c130c9c at two levels. A live retrieval and fixture-model integration run selected two references after excluding a third, prepared nine evidence images, issued two sampling requests, and produced two documents with zero cross-reference identifier occurrences. A static audit of three externally generated design indexes found all 19 required sections in every document, one unique reference identifier per document, eight page specifications, 1,943 pixel-valued measurements, and 319 color literals. These tests establish orchestration invariants and syntactic contract compliance, not semantic or visual reconstruction accuracy. The sampler abstraction preserves these boundaries across direct model APIs and transports despite MCP sampling's 2026 deprecation.

    Source: arxiv.org/abs/2608.24944

  9. From Natural Language Requirements to Graphical User Interfaces: Automated Prototyping and Verification with Pretrained Language Models

    Kristian Kolthoff

    arXiv (cs.SE) · preprint

    Takes on two costs at once: turning natural-language requirements into GUI prototypes, and checking that a GUI meets the requirements it was built from. For the first, retrieval and reranking of GUIs from natural language plus adaptation of language models to GUI generation; for the second, verification of semantically complex requirements on static prototypes, and an agent that exercises a running application through generated interaction trajectories to check functional and non-functional requirements.

    Abstract
    Requirements elicitation is essential for developing interactive software systems, as it helps ensure that the resulting product meets stakeholder needs. Since elicitation typically relies on natural language (NL), misunderstandings can arise from its inherent ambiguity. Formal specifications can reduce ambiguity but require technical expertise. GUI prototyping therefore provides a valuable alternative by turning requirements into tangible visual artifacts that support communication, elicitation, and validation. However, creating high-fidelity prototypes remains time-consuming and costly. Similarly, requirements verification, which ensures that implementations conform to specified requirements, is still largely manual, while existing automated approaches are often limited to static, rule-based techniques. This work addresses two challenges: (C1) reducing the effort required to transform NL requirements into GUI prototypes, and (C2) reducing the effort required for requirements verification in GUI applications and prototypes. For C1, we introduce novel NL-based GUI retrieval and reranking methods, new benchmarks, and techniques for efficiently adapting LLMs to GUI generation, including proprietary GUI representations. Their effectiveness is demonstrated on a large benchmark with human annotations. For C2, we propose LLM-based methods for verifying semantically complex NL requirements on static GUI prototypes and introduce a multimodal LLM-based agent for verifying complex functional and non-functional requirements in dynamic GUI applications through automatically generated and evaluated interaction trajectories. Overall, the proposed methods substantially reduce manual effort in GUI prototyping and requirements verification.

    Source: arxiv.org/abs/2608.24749

  10. SpecMine: A Large-Scale Corpus of Spec-Driven Development Artifacts

    Shyam Agarwal, Anmol Singhal, Travis Breaux, Bogdan Vasilescu

    arXiv (cs.SE) · preprint

    Spec-driven development, where a structured natural-language specification steers an AI coding agent, has produced a wave of tooling since 2025 and no study of what those tools actually write. SpecMine is the corpus: 470,795 spec files across 73,030 public repositories attributed to 17 tools, enriched with repository metadata and commit history, plus 5,992 pull requests that touch a spec and a census-wide index of 2.4 million typed references linking specs to code.

    Abstract
    Spec-Driven Development (SDD) is a fast-emerging practice in which a structured natural-language specification, written by a developer, or (more often) drafted by an AI tool and then curated by the developer, drives an AI coding agent's implementation. A wave of tooling (GitHub Spec Kit [3], OpenSpec [4], AWS Kiro [5], and dozens of others) has appeared since 2025, yet the artifacts these tools produce have never been studied at scale. We present SpecMine, a corpus that captures SDD in public GitHub repositories through two censuses: a broad census of this http URL files covering most tools (470,795 files across 73,030 repositories, attributed to 17 named tools), and a Kiro census of its distinct requirements/design/tasks layout (98,574 files across 12,910 repositories). Each spec is enriched with full repository metadata, complete commit history, and parsed document structure. How a spec becomes code is itself an open question, so for 11 tools we sweep every pull request that touches a spec in their repositories with at least ten stars, capturing 5,992 such PRs across 581 repositories with their changesets. That makes the simplest workflow, spec and implementation changing together in one PR, directly observable, and a census-wide index of 2,421,323 typed references (1.28M to code files, 863k to sibling documents, 152k to PRs, 62k refs, 43k branches, 22k issues) gives a second, independent link from spec to code. SpecMine lets the community study, for the first time, how software is specified in the age of AI agents.

    Source: arxiv.org/abs/2608.25202

  11. Predicting LLM Performance from Prompt Linguistic Features: An Empirical Study in Requirements Engineering

    Quim Motger, Alessio Miaschi, Xavier Franch, Mohammad Amin Zadenoori, Alessio Ferrari

    arXiv (cs.SE) · preprint

    Asks whether a prompt can be judged before it is ever sent, by measuring its linguistic properties rather than paying for inference. Nine thousand controlled prompt variants over five open-source models on 625 annotated requirements: linguistic features predict performance across every target, syntactic and morphosyntactic ones carry most of the signal, and the patterns that hurt a model overlap with those that make a sentence hard for a person. Lexical variety turns out not to be a quality dimension at all.

    Abstract
    Background. LLM outputs are highly sensitive to prompt formulation: small wording changes can substantially affect output quality. This matters in software engineering, where prompts guide requirements analysis, code generation, and artefact synthesis. Poor formulations yield unreliable artefacts, yet practitioners lack principled ways to assess a prompt before inference, making selection depend on costly LLM calls and trial-and-error refinement. Aims. We investigate whether measurable linguistic properties of prompts can predict LLM performance before inference, enabling low-cost prompt selection and refinement, validated on binary requirements classification targeting F1, F2, precision, and recall. Method. We generate 9,000 linguistically controlled prompt variants from 100 initial prompts by varying 30 linguistic metrics, evaluated with five open-source LLMs on 625 annotated requirements. Regression predictors are trained via stratified 10-fold cross-validation with permutation-based significance testing; feature importance analysis identifies cross-LLM and model-specific predictors. Results. Linguistic features significantly predict prompt performance across all targets (R2 in [0.38,0.42], q<0.05). Syntactic and morphosyntactic features drive most predictive signal; cross-LLM predictors include compound dependency distribution, conjunction density, and word/sentence length, reflecting sensitivity to domain vocabulary and complex structures. Conclusions. Results suggest practical implications for prompt engineering, including overlap between linguistic patterns that reduce LLM performance and those that increase human comprehension difficulty, and the irrelevance of lexical variety as a quality dimension. More broadly, linguistic profiling combined with standard regression provides an effective, interpretable, low-cost prior before costly optimisation pipelines.

    Source: arxiv.org/abs/2608.27621

  12. Operationalizing Regulations into Code: A Model to Enhance Governance and Compliance in LLM Selection for Software Engineering

    Jonysberg Quintino, Hermano Moura, Filipe Calegário

    arXiv (cs.SE) · preprint

    Turns the obligations of the EU AI Act, the NIST AI Risk Management Framework, the GDPR, the LGPD and ISO/IEC 42001 into operational criteria for choosing a language model for a software project: a regulatory layer, a decision matrix with knock-out and weighted criteria, and an assessment protocol, with a feedback loop from operational results back to the norms. A pilot over 20 adversarial scenarios suggests the knock-out criteria can keep out a technically competitive model that carries unacceptable compliance risk.

    Abstract
    Integrating Large Language Models (LLMs) into the Software Development Life Cycle (SDLC) can improve developer productivity, but it also introduces security, privacy, and compliance risks during model selection. Regulations and frameworks such as the EU AI Act, the NIST AI Risk Management Framework (RMF), the General Data Protection Regulation (GDPR), the Lei Geral de Proteção de Dados (LGPD), and ISO/IEC 42001 establish obligations that are often difficult to translate into operational criteria for technical decision-making. This paper proposes a model to support governance and compliance in LLM selection for software engineering projects. The model is developed through Design Science Research (DSR) and is structured in three layers: (i) regulatory requirements, (ii) organizational governance capabilities, instantiated by a multi-criteria decision matrix with knock-out and weighted scoring criteria, and (iii) productivity and sustainability outcomes, operationalized by the LLM governance assessment protocol (PAG-LLM). A regulatory feedback loop connects operational results back to the normative layer, enabling iterative refinement of the model. A pilot evaluation with 20 adversarial scenarios based on Common Weakness Enumeration (CWE) and the OWASP Top 10 suggests distinct risk profiles between commercial cloud-based LLMs and local open-source LLMs. The results provide preliminary evidence that regulatory disqualification logic, particularly K.O. criteria, can prevent the selection of technically competitive models that nonetheless pose unacceptable compliance risks, demonstrating the feasibility of governance-oriented LLM selection in software engineering projects.

    Source: arxiv.org/abs/2608.27703