Towards a Software Reference Architecture for Natural Language Processing Tools in Requirements Engineering

Natural Language Processing (NLP) tools support requirements engineering (RE) tasks like requirements elicitation, classification, and validation. However, they are often developed from scratch despite functional overlaps, and abandoned after publication. This lack of interoperability and maintenance incurs unnecessary development effort, impedes tool comparison and benchmarking, complicates documentation, and diminishes the long-term sustainability of NLP4RE tools. To address these issues, we postulate a vision to transition from monolithic NLP4RE tools to an ecosystem of reusable, interoperable modules. We outline a research roadmap towards a software reference architecture (SRA) to realize this vision, elaborated following a standard methodological framework for SRA development. As an initial step, we conducted a stakeholder-driven focus group session to elicit generic system requirements for NLP4RE tools. This activity resulted in 36 key system requirements, further motivating the need for a dedicated SRA. Overall, the proposed vision, roadmap, and initial contribution pave the way towards improved development, reuse, and long-term maintenance of NLP4RE tools.

💡 Research Summary

The paper addresses a pressing problem in the field of Requirements Engineering (RE): while Natural Language Processing (NLP) tools have become popular for automating RE tasks such as elicitation, classification, traceability, and test‑case generation, most of these tools are built as isolated monolithic applications. Despite functional overlaps—e.g., many tools implement the same steps of reading input documents, preprocessing text, applying a model, and visualising results—developers repeatedly re‑implement these common components. Consequently, development effort is wasted, tools are difficult to compare or benchmark, documentation is often superficial, and most academic prototypes are abandoned shortly after publication. The authors argue that the root cause is the lack of architectural guidance, which forces each research team to start from scratch.

To remedy this, the authors propose a vision of moving from monolithic NLP‑for‑RE (NLP4RE) tools toward an ecosystem of reusable, interoperable modules. In this ecosystem, core pipeline steps (input parsing, preprocessing, processing, output handling) would be encapsulated in well‑defined modules with standardized interfaces. Such modularisation would bring four key benefits:

1. Improved Reuse – Common functionality (e.g., CSV parsing, tokenisation) would be provided once and reused across many tools, reducing the effort required to develop new research prototypes.
2. Improved Applicability – By swapping modules (e.g., replacing a CSV parser with a DOCX parser) without touching the rest of the system, tools could support a broader range of artefacts, languages, and use‑cases.
3. Improved Comparability – When tools share a common modular structure, researchers can replace a single module (e.g., a classification algorithm) while keeping the rest of the pipeline fixed, enabling fair benchmarking.
4. Improved Maintenance – Widely used modules could be jointly maintained by the community, extending their lifespan and reducing the risk of tool breakage after publication.

The authors illustrate this paradigm shift with a figure contrasting a monolithic tool (e.g., CiRA) on the left with a decomposed, module‑based architecture on the right, showing Input Parsers, Pre‑processors, Processors, and User Interfaces as independent, replaceable components.

To realise the vision, the paper outlines a research roadmap for developing a Software Reference Architecture (SRA) specific to NLP4RE tools. The roadmap follows the four‑step methodology proposed by Nakagawa et al. for SRA design:

1. Information Source Investigation – Gather data from five sources: (i) scholarly publications (systematic mapping studies), (ii) existing NLP4RE tools (descriptions, classifications), (iii) prior reference models and architectures, (iv) domain ontologies (e.g., OpenReq), and (v) stakeholders (researchers and practitioners).
2. Architectural Analysis – From the collected sources, elicit three categories of requirements: System Requirements (SR) covering functional and non‑functional needs, Architectural Requirements (AR) that abstract SRs into concerns the SRA must address, and Domain Concepts (DC) that capture the main entities (data sources, processing components, reasoning layers).
3. Architectural Synthesis – Design the SRA using multiple architectural views (design‑time modules, runtime components, deployment topology). The authors suggest UML diagrams and textual specifications, including interface contracts that guarantee interchangeability of modules (e.g., a common output format for all input parsers). An open platform for sharing, reusing, and evolving modules is also envisaged, together with tutorials or handbooks to foster adoption.
4. Architectural Evaluation – Validate the SRA through (a) a traceability matrix mapping SRA modules to existing tools (to demonstrate coverage and identify gaps), (b) perceived usefulness surveys among NLP4RE tool authors, and (c) concrete refactoring of existing tools—first internal (authors’ own tools) and then external (third‑party tools) – to show that the SRA can be applied in practice.

As an initial empirical contribution, the authors conducted a stakeholder‑driven focus group at the AIRE’25 workshop. Twenty participants were divided into four groups, each addressing one of the four requirement categories (functional, non‑functional, domain concepts, generative‑AI challenges). Over two iterative rounds, participants generated sticky‑note ideas, positioned them on a priority‑vs‑complexity matrix, and refined them through discussion. The consolidated outcome was a set of 36 system‑level requirements (identified as SRxx in the replication package). These requirements map directly onto the four improvement dimensions of the vision:

• Reuse – modularity, black‑box interfaces, reusable parsers, transparent intermediate steps.
• Applicability – configurability, multilingual support, handling of specific RE artefacts, explicit communication of input limitations.
• Comparability – support for evaluation, reproducibility under fixed conditions, version tracking, durable storage of artifacts and results.
• Maintenance – modular design, version control, robustness, recoverability, legal and data‑protection compliance.

The authors argue that these stakeholder‑grounded requirements provide concrete evidence that a modular, reference‑architecture‑driven approach can systematically address recurring challenges in NLP4RE tool development.

In conclusion, the paper makes three main contributions: (1) a clear articulation of the need to shift from monolithic to modular NLP4RE tools, (2) a detailed roadmap for designing a domain‑specific SRA based on established guidelines, and (3) an initial set of 36 system requirements derived from a focus group with NLP4RE experts. The authors plan future work to translate these system requirements into architectural requirements, assess existing tools against the emerging SRA, and iteratively design, implement, and evaluate the SRA in close collaboration with the community. This work lays a solid foundation for a sustainable, reusable ecosystem of NLP tools that can accelerate research and practice in requirements engineering.