arXiv CSopen access

From Textual Requirements to Microservice Architectures - A Comprehensive Evaluation of LLM-Based Design Synthesis

arXiv:2607.28307v1 [cs.SE] 30 Jul 2026

From Textual Requirements to Microservice Architectures: A Comprehensive Evaluation of LLM-Based Design Synthesis Danyllo Albuquerque

José Renan

Guillermo Rodríguez

VIRTUS/UFCG Federal University of Campina Grande (UFCG), Paraiba Brazil [email protected]

Federal University of Campina Grande (UFCG), Paraiba Brazil [email protected]

Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET), Universidad Nacional del Centro de la Provincia de Buenos Aires (UNICEN), Argentina Argentina [email protected]

Jorge Andrés Díaz-Pace

Emanuel Dantas

Ademar França

Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET), Universidad Nacional del Centro de la Provincia de Buenos Aires (UNICEN) Argentina [email protected]

VIRTUS/UFCG Federal Institute of Pernambuco (IFPE), Brazil Brazil [email protected]

Rui Barbosa State School, Rio Grande do Norte, Brazil Brazil [email protected]

Mirko Perkusich

Kyller Gorgônio

Angelo Perkusich

VIRTUS/UFCG Federal University of Campina Grande (UFCG), Paraiba, Brazil Brazil [email protected]

VIRTUS/UFCG Federal University of Campina Grande (UFCG), Paraiba, Brazil Brazil [email protected]

VIRTUS/UFCG Federal University of Campina Grande (UFCG), Paraiba, Brazil Brazil [email protected]

ABSTRACT

achieving higher agreement with the references under FS prompting (F1 ≈ 0.79 for ZS and ≈ 0.97 for FS). Communication recovery is more challenging, with ZS producing overly dense architectures characterized by high recall but low precision (F1 ≈ 0.61). FS prompting improves structural agreement and perceived architectural quality, achieving F1 ≈ 0.82 for communication recovery while reducing unsupported dependencies. Expert evaluation corroborates these findings, indicating that FS-generated architectures are consistently perceived as more modular, coherent, and plausible than ZS outputs. [Conclusion]. Within the evaluated scope, OpenAI o3 shows potential to support requirements-driven architectural synthesis, particularly when guided by minimal exemplar-based prompting. The results should be interpreted as model- and context-specific evidence from two relatively small systems and a single execution per condition, rather than as model-independent proof of effectiveness.

[Context]. Microservice architectures have become a dominant paradigm for modernizing monolithic systems. However, identifying appropriate services remains a challenging and largely manual task. Existing decomposition approaches are predominantly code-centric, limiting their applicability in early design stages where only textual requirements are available. [Problem]. Despite recent advances in Large Language Models (LLMs), there is still limited empirical evidence regarding their ability to synthesize complete microservice architectures directly from natural-language requirements, including both service definitions and inter-service interactions. [Goal]. This study investigates whether an LLM can bridge the gap between requirements engineering and architectural design by generating microservice architectures solely from textual requirements, and evaluates the structural agreement and perceived quality of the generated solutions. [Method]. We conduct a mixed-method study using the OpenAI o3 model under zero-shot (ZS) and few-shot (FS) prompting strategies across two systems (Bookstore and PetClinic), with one execution per system and prompting condition. Generated architectures are evaluated through (i) quantitative comparison with implemented reference architectures using precision, recall, and F1-score for service identification and communication recovery, and (ii) a blinded expert assessment of correctness, completeness, modularity, and plausibility, supplemented by a structured descriptive synthesis of open-ended feedback. [Results]. The findings indicate that OpenAI o3 can identify services from requirements,

KEYWORDS Large Language Models, Microservice Architectures, Design Synthesis, Software Architecture, Requirements Engineering, Empirical Software Engineering

1

Introduction

Legacy enterprise systems continue to support a substantial portion of organizational operations, yet many of them were originally designed as monolithic applications. While this architectural style simplifies early development, it increasingly conflicts with modern 1

Conference’17, July 2017, Washington, DC, USA

Silva et al.

• A mixed-method evaluation framework that combines quantitative structural agreement (service identification and interservice interactions) (RQ1–RQ2), blinded expert ratings of architectural quality (RQ3), and a structured descriptive synthesis of open-ended feedback (RQ4); • An analysis of how ZS and FS prompting strategies influence structural outcomes, revealing their impact on service identification and interaction recovery accuracy (RQ1–RQ2); • An examination of expert ratings and open-ended feedback that operationalizes correctness, completeness, modularity, and plausibility, while preserving divergent assessments and characterizing recurring strengths, weaknesses, and design issues in the generated architectures (RQ3–RQ4); • Evidence that minimal exemplar-based prompting improves both structural alignment and perceived architectural quality, highlighting its role as an effective mechanism for requirements-driven design support.

requirements such as scalability, continuous delivery, and rapid adaptation to evolving business needs [24, 38]. As a result, organizations are actively pursuing modernization strategies to transition toward more modular and flexible architectures [32, 41]. Among these strategies, the migration to microservice-based architectures has emerged as a dominant paradigm. Microservices decompose applications into loosely coupled, independently deployable services aligned with business capabilities [34, 37]. This paradigm enables scalability, resilience, and faster evolution [14, 27]. However, these benefits critically depend on the identification of appropriate service boundaries and the definition of coherent and well-structured inter-service interactions. Determining such boundaries and interactions remains a challenging and largely manual task. Existing approaches to microservice decomposition are predominantly code-centric, relying on static dependencies, runtime traces, or repository mining [1]. While effective in reverse-engineering existing systems, these approaches often fail to capture the semantic intent embedded in requirements and domain descriptions. As a result, they may produce architectures that are structurally consistent at the code level but misaligned with business logic, both in terms of service responsibilities and interaction patterns [29]. This limitation exposes a fundamental gap: architectural decomposition is inherently a requirements-driven problem, yet current automated approaches largely ignore requirements as primary input. In practice, architects still rely on manual interpretation of textual artifacts (e.g., user stories and business rules) to derive both service boundaries and inter-service interactions, making the process time-consuming, subjective, and difficult to scale [11]. In this context, recent advances in Large Language Models (LLMs) offer a promising alternative [12, 28, 46]. LLMs demonstrate strong capabilities in natural language understanding, abstraction, and structured generation, enabling them to extract domain concepts directly from textual descriptions [20, 51]. While prior work has explored LLMs in software engineering tasks such as code generation and requirements analysis [3], their role in end-to-end architectural synthesis from requirements remains largely unexplored and under-evaluated. This raises a key question: Can LLMs bridge the gap between textual requirements and architectural design by synthesizing coherent microservice architectures directly from natural-language inputs? To address this question, we conduct an empirical study of OpenAI o3’s ability to synthesize microservice architectures directly from textual requirements. Specifically, we evaluate the structural agreement and perceived architectural quality of architectures generated under zero-shot (ZS) and few-shot (FS) prompting strategies. The study combines quantitative comparison with implemented reference decompositions [21], blinded expert ratings, and a structured descriptive synthesis of open-ended expert feedback. Because the experiment covers one model, two relatively small systems, and one execution per prompting condition, the resulting conclusions are intentionally scoped to this empirical setting. This article makes the following contributions:

These contributions provide empirical evidence that LLMs can support architectural reasoning in scenarios where design decisions must be derived from high-level textual specifications, contributing to ongoing efforts toward AI-assisted software modernization and architectural evolution. Building on our previous study [31], which provided an initial exploratory investigation, this work advances the state of the art by introducing a rigorous empirical evaluation of LLM-based architectural synthesis, including a refined methodological design, an additional research question (RQ4), and a substantially expanded analysis combining quantitative metrics, qualitative evidence, and stronger theoretical grounding and implications. The remainder of this article is organized as follows: Section 2 outlines the conceptual and architectural foundations underlying this study. Section 3 reviews related work. Section 4 describes the study design and evaluation procedure. Section 5 reports the empirical results. Section 6 provides a deeper interpretation of the findings. Section 7 discusses implications for research and practice. Section 8 outlines threats to validity. Finally, Section 9 concludes the article.

2

Foundations

This section presents the conceptual and architectural foundations underlying this study. It introduces the principles of microservice decomposition, the challenges of defining service boundaries and inter-service interactions, and the role of textual requirements in early-stage architectural design [15]. Monolithic architectures consolidate application components, data-access logic, and deployment into a single codebase and execution unit. While suitable in early development stages, this architectural style becomes increasingly problematic as systems evolve and accumulate tightly coupled components, cross-cutting dependencies, and implicit business rules [1, 18]. Under these conditions, even localized changes may require rebuilding, retesting, and redeploying the entire application, increasing delivery time and operational risk. Microservice architectures address these limitations by decomposing applications into smaller, autonomous, and independent services, each aligned with a specific business capability or bounded

• An empirical evaluation of LLMs for generating microservice architectures directly from textual requirements, without relying on code or runtime artifacts; 2

From Textual Requirements to Microservice Architectures

Conference’17, July 2017, Washington, DC, USA

responsibility [14, 27]. In this paradigm, services encapsulate domain logic and expose functionality through well-defined interfaces, while the overall system behavior emerges from the inter-service interactions, realized through lightweight communication mechanisms such as REST APIs or messaging [49]. This paradigm improves modular evolution, supports technological heterogeneity, enhances fault isolation, and enables fine-grained scalability [18]. However, these benefits depend on the quality of the resulting decomposition in terms of high internal cohesion and low external coupling within services, and the correctness and efficiency of inter-service interactions [42, 45]. A central challenge in this transition is the accurate identification of service boundaries and the inter-service interactions. In legacy systems, such boundaries and interactions are rarely explicit, as responsibilities are often dispersed across modules and shaped by incremental changes over time [10]. Consequently, microservice decomposition is not merely a technical refactoring task, but an architectural recovery process that requires reconstructing domain structure and mapping it to modular service designs, as well as defining how these services coordinate and communicate [23]. Poorly defined boundaries may lead to overly coarse services that replicate monolithic limitations, or excessively fine-grained services that increase communication overhead and fragment business logic [35]. Similarly, poorly designed interactions may result in tightly coupled communication patterns, redundant dependencies, or inefficient data flows, ultimately degrading system modularity and performance [30]. To mitigate migration risks, incremental modernization strategies such as the Strangler Fig pattern are commonly adopted, allowing legacy functionality to be gradually replaced by new services [33]. Additionally, Domain-Driven Design (DDD) is frequently used to align decomposition with bounded contexts, domain concepts, and business rules [40]. This perspective emphasizes that effective microservice design depends on structural modularization and preserving the semantic integrity of the problem domain [44]. Given the complexity of manual migration, a wide range of automated and semi-automated approaches have been proposed to support service identification [1]. These approaches span structural, behavioral, and semantic techniques [32]. Structural approaches rely on static analysis of code elements and dependencies [1, 16, 30], while search-based and evolutionary techniques explore alternative decompositions using optimization strategies [17, 25]. Other methods leverage repository mining and co-change analysis to uncover latent service boundaries grounded in maintenance behavior [6]. Behavioral and hybrid approaches incorporate runtime information such as execution traces and logs to capture dynamic interactions [23]. Complementarily, semantic and lexical techniques exploit domain vocabulary, documentation, and embeddings to identify conceptually coherent modules [5, 35, 36, 39]. Most existing approaches rely on code-level artifacts (e.g., source code or execution traces) to support decomposition. These methods assume that such artifacts are available and sufficiently informative to guide the identification of service boundaries and interactions. While effective in scenarios where implementation data is accessible, this reliance limits their applicability in early design stages, greenfield contexts, or requirement-driven settings where such artifacts are not yet available [23, 35]. Furthermore, these approaches

may yield decompositions that are structurally consistent but only partially aligned with domain concepts, stakeholder intent, or textual requirement descriptions. Assessing the quality of a candidate decomposition is itself a non-trivial problem. In the literature, microservice quality is commonly evaluated through architectural properties such as cohesion, coupling, granularity, and conceptual consistency [42]. Representative metrics include Structural Modularity Quality (SMQ) and Conceptual Modularity Quality (CMQ), which respectively assess structural separation and conceptual coherence [45], as well as semantic cohesion measures [26], and granularity indicators [47]. However, these metrics do not fully eliminate the need for human judgment, as architectural plausibility also depends on domain alignment and operational feasibility. The emergence of Large Language Models (LLMs), such as GPT4, Gemini, Llama, and DeepSeek, suggests a new paradigm for architecture-oriented automation [7, 13, 19, 20]. Unlike traditional code-centric approaches, LLMs can process natural-language artifacts (e.g., requirements, user stories, and domain descriptions) and extract latent domain concepts, relationships, and abstractions [46, 50]. This capability enables them to potentially generate structured outputs, including service candidates and interaction patterns, directly from textual inputs [5, 39, 43]. By operating at the domain-semantic level rather than implementation details, LLMs can support architectural reasoning in early design stages, when code-level artifacts are not yet available. This shift indicates that LLMs may act as a bridge between businesslevel descriptions and architectural design decisions, opening new possibilities for requirements-driven microservice decomposition.

3

Related Work

Prior research on microservice decomposition has predominantly focused on implementation-driven strategies. Most approaches infer service candidates (and inter-service interaction) from source code structure, execution traces, repository history, or dependency graphs, using clustering, heuristic rules, or search-based optimization to identify modular partitions [1, 6, 16, 17, 23, 25]. These methods have proven effective in modernization scenarios, where codelevel artifacts are readily available, but they generally assume that such artifacts are sufficiently rich and reliable to guide decomposition decisions. Building on this foundation, a second line of work incorporates semantic, lexical, API-level, and learning-based signals to improve service identification [2, 5, 9, 22, 35, 36, 39, 43]. By leveraging domain vocabulary, interface descriptions, and embedding-based representations, these approaches aim to better capture conceptual coherence and business functionality. Nevertheless, despite this shift toward richer representations, they still predominantly rely on code-level artifacts (e.g., code, APIs, execution data, or hybrid inputs) rather than treating textual requirements as a primary source of architectural knowledge. More recently, research in software engineering has explored the use of LLMs and related AI techniques for design-oriented tasks such as requirements analysis, architectural decision support, and model-driven generation [7, 13, 19, 20]. These studies demonstrate that language-based models can support reasoning over textual 3

Conference’17, July 2017, Washington, DC, USA

Silva et al.

artifacts and help derive design-relevant information [8, 12, 15, 46, 50]. However, most of this work focuses on isolated activities or intermediate artifacts rather than directly addressing the end-toend synthesis of microservice architectures from requirements. Among the studies closest to our research objective, Abgaz et al. [1] provide an important baseline by highlighting that decomposition research remains largely centered on implementation artifacts. Moving toward stronger semantic support, MicroDec [5] and MonoEmbed [39] integrate structural analysis with embeddings and learning-based techniques to identify service candidates, yet still operate primarily over code-level inputs. In a complementary direction, Dhar et al. [13] investigate LLM-based generation of architectural design decisions, while Ataei et al. [7] explore LLMdriven requirements elicitation; both contributions are relevant to early-stage design, but focus on adjacent artifacts rather than on the synthesis and evaluation of complete microservice architectures. Research Gap. Despite these advances, a fundamental gap remains at the intersection of requirements engineering and architectural design. Existing approaches predominantly rely on implementation artifacts or leverage LLMs for isolated or intermediate design tasks, but do not systematically evaluate their ability to synthesize complete microservice architectures directly from textual requirements. As a result, there is still limited empirical understanding of how accurately such architectures reflect reference decompositions, how well they capture inter-service relationships, and to what extent they are perceived as coherent and plausible by experts. To address this gap, this study adopts a requirements-driven perspective, treating textual specifications as the sole input to generate complete architectural artifacts—including services and interservice interactions—and evaluating them through a combined quantitative and expert-based framework. In doing so, it bridges the gap between requirements engineering and architectural design, providing systematic empirical evidence on the feasibility and limitations of LLM-based architectural synthesis. These limitations motivate the empirical investigation presented in this study.

4

that capture these complementary aspects and structure the analysis across both quantitative and qualitative dimensions. Table 1 summarizes the RQs along with their descriptions and motivations. Together, these RQs define a cohesive analytical framework that links structural recovery, architectural fidelity, and expert-based evaluation, enabling a systematic assessment of both the structural and practical validity of the generated architectures.

4.2

To answer the RQs, we designed a four-step methodology that integrates artifact preparation, prompt-based architectural generation, quantitative comparison with reference systems, and expert-based validation. Figure 1 presents an overview of the workflow and its corresponding inputs, activities, and outputs. The methodological design combines quantitative and qualitative evaluation. The quantitative component measures the degree of overlap between LLM-generated and reference architectures for service identification and inter-service communication, directly addressing RQ1 and RQ2. The qualitative component relies on expert judgment to assess how understandable, plausible, and architecturally sound the generated outputs appear in practice, thereby addressing RQ3. At the same time, the open-ended feedback supports the identification of recurring strengths, weaknesses, and design patterns for RQ4. This mixed-method design was chosen because purely structural similarity does not fully capture architectural quality. An architecture may resemble a numerically decomposed reference while still being perceived as poorly modularized or operationally implausible. Conversely, a design may differ from the implementation yet still be judged reasonable from a business or design perspective. The remainder of this section details each step of the methodology. All artifacts used in the study are publicly available to support transparency and reproducibility (see Artifacts Availability Section). Step 1: Dataset Preparation. This step establishes the foundational artifacts required for the study, including selecting case studies, preparing requirement descriptions, and extracting reference architectures. Its objective is to ensure that both the LLM’s input and the baseline for comparison are consistent, representative, and suitable for systematic evaluation. Selection of case studies. This study employed two software systems from the dataset curated by Imranur et al. [21]: (i) Bookstore and (ii) PetClinic. Both systems provide accessible requirement descriptions and sufficiently explicit architectural artifacts for systematic comparison, and they represent distinct functional domains. Their limited scale also makes it feasible to inspect services and interactions consistently during the quantitative comparison and expert review. The two cases were selected for controlled, in-depth experimentation, not as a statistically representative sample of microservice systems. Both contain a relatively small number of services and comparatively well-defined requirements. Consequently, they provide evidence about the feasibility of the evaluated procedure in bounded settings, but do not establish that the same performance will hold for larger systems, heterogeneous portfolios, safety-critical applications, or architectures with substantially denser interaction

Study Settings

This section presents the study goals and research questions (Section 4.1), followed by the research design, which outlines the methodological steps adopted in this study (Section 4.2).

4.1

Research Design

Goals and Research Questions

The goal of this study is to assess whether LLMs can generate microservice architectures directly from natural-language requirements, without relying on source-code artifacts. To address this objective, we adopt a dual evaluation perspective. First, we analyze the structural correspondence between LLM-generated and reference architectures, focusing on service identification and inter-service interactions. Second, we assess the perceived architectural quality of the generated outputs through expert evaluation, considering correctness, completeness, modularity, and plausibility. Together, these perspectives provide a comprehensive view that combines objective alignment with practitioner-oriented judgment. This evaluation is operationalized through a set of research questions (RQs) 4

From Textual Requirements to Microservice Architectures

Conference’17, July 2017, Washington, DC, USA

Table 1: Research questions, descriptions, and motivations RQ

Description

Motivation

RQ1

Can LLMs identify the individual microservice components from textual requirement descriptions?

Focuses on decomposition capability, i.e., whether an LLM can transform naturallanguage requirements into a plausible set of service components. This is fundamental, as microservice design begins with identifying bounded responsibilities and coherent service candidates.

RQ2

How accurately do LLMs recover the inter-service communication links present in the reference architecture?

Addresses architectural fidelity by evaluating whether the model can reconstruct services and their communication relationships, which are essential for defining an operational architecture.

RQ3

How do experts evaluate the quality of LLM-generated architectures in terms of correctness, completeness, modularity, and plausibility?

Introduces a practitioner-oriented perspective, assessing whether generated architectures are perceived as structurally sound and realistic by experienced software architects.

RQ4

What strengths, weaknesses, and design patterns do experts identify in LLM-generated architectures based on qualitative feedback?

Extends the evaluation to qualitative insights, capturing recurring strengths, weaknesses, and design patterns that help explain the behavior of LLM-generated architectures beyond numerical metrics.

1. Dataset Preparation

2. PromptingBased Generation

Input: textual descriptions of system requirements and reference architectural artifacts.

Input: standardized requirements and architectural generation instructions.

Activities: • selection of the case studies (Bookstore and PetClinic); • curation and standardization of requirements; • extraction of the reference architecture from the systems; • normalization of artifacts for comparison. Output: • consolidated requirements; • standardized reference architectures.

Activities: • LLM selection; • definition of the expected output format; • application of zero-shot; • application of few-shot; • generation of candidate architectures with services, responsibilities, and interactions. Output: • candidate architectures generated by the LLM under the ZS and FS conditions.

3. Quantitative Evaluation

Input: architectures generated by the LLM and reference architectures. Activities: • comparison of the identified services; • comparison of interactions between services; • classification into correct, missing, and extra elements; • calculation of precision, recall, and F1-score. Output: • quantitative metrics; • characterization of architectural errors.

4. Expert Validation Input: requirements, anonymized diagrams/descriptions, and evaluation form. Activities: • Preparation of evaluation materials and recruitment of expert participants; • quantitative assessment of architectures; • qualitative assessment of architectures. Output: • scores for correctness, completeness, modularity, and plausibility; • qualitative feedback regarding strengths, risks, and design choices.

Figure 1: Methodological workflow adopted in this study. topologies. Replication with additional systems is required to assess external validity. Requirements curation. To support requirement-driven architectural generation, the natural-language requirements of each system were curated and standardized before being presented to the model. This curation process had two main objectives: improving clarity and preserving semantic fidelity. In particular, the requirements were revised to remove unnecessary redundancy, reduce ambiguity, and normalize domain terminology while preserving the original functionality and business intent of the system. The curation focused on textual clarification rather than functional modification so that the evaluation would reflect the model’s architectural reasoning rather than differences in requirement phrasing. Each system was ultimately represented by a consolidated set of at least ten functional requirements expressed in declarative form. The requirements were organized to describe the target system’s expected functionalities in a coherent, self-contained manner. This

preparation step was necessary because LLM-based generation is sensitive to ambiguity, lexical inconsistency, and incomplete contextualization. By standardizing the phrasing of requirements, we sought to reduce noise unrelated to the architectural reasoning capability being evaluated. Importantly, this curation was not intended to redesign or enrich the systems with additional features. Rather, it aimed to present the original business functionality in a clearer, more consistent textual form that could be consistently interpreted by both the model and the human evaluators. Extraction of the reference architecture. We reused the service and dependency information distributed with the curated dataset [21], which derives architectural characteristics from the corresponding open-source implementations. The dataset’s analysis pipeline uses SLOCcount to characterize source-code size and MicroDepGraph to recover and visualize inter-service dependencies. MicroDepGraph analyzes service declarations in Docker Compose 5

Conference’17, July 2017, Washington, DC, USA

Silva et al.

files and internal API calls in Java source code to construct the dependency graph. In this study, the resulting service and dependency records for Bookstore and PetClinic were the starting point for the reference architectures. We normalized this information into a common representation that documented: (i) the list of implemented services, (ii) the main responsibility assigned to each service, and (iii) the directed communication relationships among services. The same abstraction level was used for the reference, ZS, and FS alternatives so that formatting and notation would not determine the comparison or the expert judgments. These references are realistic because they originate from existing implementations, but their quality and representativeness are bounded by the selected repositories and by the extraction procedure. They are therefore treated as implemented baselines, not as optimal or unique decompositions. Precision, recall, and F1-score measure agreement with these baselines. An element classified as extra can still constitute a defensible alternative design choice; the label only indicates that the element is absent from the implemented reference. The blinded expert assessment complements this structural comparison by evaluating whether such alternatives remain correct, complete, modular, and plausible. Artifact normalization. To support consistent downstream evaluation, all artifacts were standardized before use. Requirements were formatted uniformly across systems, and reference architectures were rendered as structured diagrams and textual descriptions using the same level of abstraction later used for the LLM-generated outputs. This normalization step was especially important for the expert-review stage, as it reduced the chance that presentation format, notation style, or diagram layout would bias evaluators toward one alternative. At the end of this step, we obtain a consistent set of requirements and reference architectures that serve as input to the LLM and as a baseline for quantitative comparison. These artifacts are then used in the next step to generate candidate architectures under different prompting strategies.

narrative. For each system, the model was instructed to read the complete set of functional requirements and produce: • a set of proposed microservices; • a concise name for each service; • a description of the main responsibilities of each service; and • an explicit indication of which services communicate with which others. This output structure was chosen because it aligns directly with the study objectives. The identification of services addresses RQ1, while the explicit communication links address RQ2. Requiring service names and responsibilities also improves interpretability and supports the later expert assessment for RQ3. To reduce uncontrolled variability, the prompts emphasized that the model should propose services grounded in the given requirements and avoid excessive speculation beyond the textual evidence. Even so, the prompts did not specify the number of services or any target decomposition template, since doing so would constrain the model too strongly and interfere with the evaluation’s purpose. Application of prompting strategies. To analyze the effect of prior architectural guidance, we adopted two prompting strategies: • ZS prompting: the model received only the task instructions and the complete requirements of the target system. No example of architectural decomposition was provided. This condition evaluates the model’s unaided ability to infer service boundaries and interactions directly from the requirements. • FS prompting: the model received the same task instructions and requirements, but the prompt additionally included one illustrative example of a different system decomposition. This example was formatted as a structured list of services, responsibilities, and interactions. The purpose of this condition was to determine whether minimal exposure to the expected output format and reasoning style would improve the coherence and alignment of the generated architecture. The authors manually curated the FS example from a system different from Bookstore and PetClinic. The exemplar did not reproduce the target requirement text and was intended to demonstrate the expected representation—a structured mapping from requirements to services, responsibilities, and directed interactions—at a comparable abstraction level. However, the original study did not quantify the exemplar’s domain similarity or decompositionpattern similarity to the target systems. The exemplar may therefore still act as a structural prior by suggesting a particular granularity or interaction density. Consequently, the observed FS improvement cannot be attributed exclusively to output-format clarification. A richer instruction-only prompt could potentially provide part of the same guidance without an explicit decomposition example, and a direct comparison between exemplar-based and instruction-only guidance remains necessary. Prompt design considerations. All prompts were written to be instruction-focused and as neutral as possible. We avoided wording that explicitly suggested particular services, architectural patterns, or implementation technologies for the target systems. This was important to reduce the risk that the prompt itself would impose a decomposition. Likewise, the two prompting conditions differed

Step 2: Prompt-Based Generation. This step focuses on generating candidate architectural decompositions from the curated requirements using LLM-based prompting strategies. Its objective is to assess how different prompting conditions influence the model’s ability to infer service boundaries, responsibilities, and inter-service interactions. LLM selection. To generate architectural decompositions from natural-language requirements, we used the OpenAI o3 model via the OpenAI API.1 The model was selected because the task requires natural-language understanding, abstraction over domain concepts, structured output synthesis, and multi-step reasoning about decomposition and dependencies. However, the experiment was not designed as a comparison among model families. Accordingly, the empirical results directly characterize OpenAI o3 under the reported prompts and execution period; broader claims about LLM-based architectural synthesis remain hypotheses to be tested through cross-model replication. Definition of output format. The prompts were designed to elicit a structured architectural proposal rather than a free-form 1 https://platform.openai.com/docs/models/o3

6

From Textual Requirements to Microservice Architectures

Conference’17, July 2017, Washington, DC, USA

Classification protocol. For service identification, each service proposed by the model was compared against the list of services in the reference architecture. Services were classified into three categories: • Correct: services that correspond to a reference service in scope and responsibility; • Missing: reference services not recovered by the model; • Extra: services proposed by the model that do not correspond to a reference service. For interaction alignment, the same logic was applied to communication links. Each proposed interaction was compared against the set of communication relationships present in the reference architecture and classified as correct, missing, or extra. Because architectural naming and granularity can vary across decompositions, the comparison was based on literal service names and the services’ semantic roles and responsibilities. In cases where naming differed but responsibility alignment was clear, correspondence was determined based on architectural function rather than exact lexical identity. This rule was necessary to avoid unfairly penalizing outputs that correctly captured the business responsibility by using alternative labels. The matching procedure was performed by manually inspecting the generated and reference architectures against these criteria. Illustrative matching example. Suppose that a generated architecture contains a Customer Management Service responsible for customer registration and profile maintenance, whereas the reference contains a Customer Service with the same responsibility. The generated service is classified as correct despite the lexical difference because its architectural scope is semantically equivalent. If the model additionally proposes a Notification Service that has no counterpart in the reference, it is classified as extra relative to that baseline; if an implemented Payment Service is not recovered, it is classified as missing. For interactions, a generated directed link Order Service → Inventory Service is correct only when the same semantically aligned dependency and direction are present in the reference. An unsupported or reversed-only link is extra, whereas an expected but absent link is missing. This example illustrates the protocol and does not correspond to a new empirical result. Metrics calculation. For both services and interactions, we computed precision, recall, and F1-score. Let 𝑇 𝑃 denote the number of correctly identified elements, 𝐹 𝑃 the number of extra elements, and 𝐹 𝑁 the number of missing elements. Then:

only in the presence or absence of the illustrative example, preserving comparability across the two settings. A complete set of prompts is available in the supplementary repository to support replication and secondary analysis. Generation of architectures. For each target system, we executed each prompting strategy once, obtaining one architectural proposal in the ZS condition and one in the FS condition. No repeated executions were performed to estimate run-to-run variability. The API configuration and prompt templates were kept unchanged across the two systems within each condition, and the exact outputs were recorded in the replication package. The outputs were then manually normalized into the same representation used for the reference architectures, preserving the proposed services, responsibilities, and communication links while standardizing only their presentation. Consequently, the quantitative values reported in this study describe the observed executions rather than a distribution of possible model outputs. This step produced three candidate architectures per system: the implemented reference architecture, the ZS LLM-generated architecture, and the FS LLM-generated architecture. These architectures are then used in the next step to perform a quantitative comparison against the reference systems, enabling the assessment of service identification and interaction recovery.

Step 3: Quantitative and Comparative Evaluation. The third step performs a quantitative comparison between the LLM-generated architectures and the reference decompositions. Its objective is to assess how accurately the model recovers both the set of services and the communication relationships among them, providing a structured evaluation of architectural correspondence. Comparison of Identified Services. The first stage evaluates service identification (RQ1) by comparing the set of services proposed by the model with those defined in the reference architecture. For each generated service, we assess whether a corresponding reference service exists with similar responsibilities and functional scope. This comparison considers service names and their semantic roles, including the business capabilities they encapsulate and the operations they are expected to support. To perform this matching, we analyze service descriptions and responsibilities to determine whether a generated service captures the same architectural function as a reference service. This allows us to identify whether the model correctly decomposes the system into meaningful and coherent service boundaries. Comparison of Inter-Service Interactions. The second stage evaluates interaction alignment (RQ2) by comparing the communication links among services. Each interaction proposed by the model—typically represented as a directed connection between two services—is matched against the set of interactions present in the reference architecture. The comparison focuses on whether the model correctly identifies which services should communicate and the directionality of these interactions. As with service matching, the evaluation considers semantic equivalence rather than exact representation, ensuring that interactions are assessed based on their architectural intent (e.g., data exchange, coordination, or dependency) rather than strictly on naming or notation differences.

𝑇𝑃 𝑇𝑃 + 𝐹𝑃

(1)

𝑇𝑃 𝑇𝑃 + 𝐹𝑁

(2)

𝑃𝑟𝑒𝑐𝑖𝑠𝑖𝑜𝑛 · 𝑅𝑒𝑐𝑎𝑙𝑙 𝑃𝑟𝑒𝑐𝑖𝑠𝑖𝑜𝑛 + 𝑅𝑒𝑐𝑎𝑙𝑙

(3)

𝑃𝑟𝑒𝑐𝑖𝑠𝑖𝑜𝑛 = 𝑅𝑒𝑐𝑎𝑙𝑙 = 𝐹1 = 2 ·

Precision indicates the proportion of generated elements that correspond to the implemented reference, while recall measures the proportion of reference elements recovered by the model. The F1-score summarizes this agreement when outputs may simultaneously omit elements and introduce alternatives. These metrics were computed separately for services and directed interactions. They operationalize RQ1 and RQ2 as structural correspondence with a particular implementation; they do not, by themselves, establish 7

Conference’17, July 2017, Washington, DC, USA

Silva et al.

• Completeness: the extent to which the architecture represents the functional capabilities, business responsibilities, and necessary coordination implied by the complete requirement set. Omitted required capabilities reduce completeness; • Modularity: the extent to which services exhibit cohesive responsibilities, clear ownership, separation of concerns, and limited unnecessary coupling. Blurred boundaries, duplicated ownership, excessive dependencies, or avoidable cycles reduce modularity; • Plausibility: the extent to which the architecture constitutes an implementable and operationally credible microservice solution, considering realistic dependency directions, data and responsibility allocation, deployment independence, and the treatment of cross-cutting concerns.

intrinsic architectural quality or prove that every non-reference element is incorrect. This distinction motivates the complementary expert evaluation. At the end of this step, we obtain quantitative metrics that characterize both the accuracy and the types of errors present in the generated architectures. These results provide the basis for subsequent expert validation, in which the perceived quality and practical plausibility of the architectures are assessed. Step 4: Expert Validation. The final step aimed to evaluate the perceived quality, correctness, and practical viability of the generated architectures from the perspective of experienced software architects. While the previous step measures structural correspondence with the reference systems, expert validation addresses RQ3 by assessing whether the architectures are understandable, coherent, and credible in practice, and RQ4 by eliciting qualitative insights into recurring strengths, weaknesses, and design patterns observed in the generated solutions. Expert recruitment and evaluation materials. We engaged six domain experts, each with at least five years of professional experience in designing distributed software systems. The inclusion criterion was intended to ensure that participants had sufficient practical familiarity with modular design, service separation, and architectural trade-offs to assess the alternatives meaningfully. Each expert received an evaluation package for both target systems (i.e., PetClinic and Bookstore). For each system, the package included:

Thus, correctness and completeness assess requirements alignment from different perspectives (validity of included decisions versus coverage of required capabilities), while modularity and plausibility assess structural quality and real-world feasibility. The scale anchors indicate the degree to which each architecture satisfies the corresponding operational definition. The evaluation procedure followed a controlled and blinded protocol. Experts reviewed each system independently: they first analyzed the textual requirements and then evaluated the three architectural alternatives using the same form and criteria. The alternatives were presented under identical conditions, enabling direct comparison. The assessment was conducted individually to avoid discussion effects and preserve independent judgment. The ratings were retained at the individual-expert level and consolidated descriptively by system, architecture variant, and evaluation dimension. We did not conduct a consensus meeting or replace divergent scores with an adjudicated value; disagreement was preserved as part of the evidence about architectural trade-offs. The resulting summaries support comparison among the alternatives for RQ3, but the six-expert sample is not used for population-level statistical generalization. Qualitative assessment. In addition to quantitative ratings, experts provided open-ended feedback to capture deeper architectural reasoning. Specifically, they addressed the following aspects:

• the full set of textual requirements; • three architecture descriptions and diagrams; and • a structured evaluation form. The three architecture variants corresponded to: (i) the implemented reference architecture, (ii) the ZS LLM-generated architecture, and (iii) the FS LLM-generated architecture. To reduce bias, the three variants were anonymized and labeled generically as A, B, and C. Their order was randomized for each expert, so that participants could not infer which architecture was the implemented baseline or which one was generated by the model. This blinding strategy was important because it prevented evaluators from favoring the reference architecture simply because it was known to be implemented, or from penalizing an architecture because it was known to be AI-generated. The expert-based evaluation was designed to assess both the perceived architectural quality of the generated solutions and the qualitative insights derived from expert judgment. To this end, the evaluation was structured into two complementary components: a quantitative assessment and a qualitative analysis. Quantitative assessment. Experts evaluated each architecture using a structured review form based on a 5-point Likert scale (1 = Very Poor, 5 = Excellent). Because these terms have multiple meanings in the literature, we adopted the following study-specific operational definitions:

• What are the main strengths of this architecture? • What weaknesses or risks do you identify? • Were there any surprising or non-obvious design choices? • What modifications would you recommend to improve this architecture? The open-ended responses were analyzed through a structured descriptive synthesis rather than a formal grounded-theory or full thematic-analysis protocol. First, responses were organized by target system, anonymized architecture variant, and questionnaire question. Second, semantically similar observations were grouped into recurring descriptive categories (e.g., excessive coupling, unclear responsibility allocation, unsupported infrastructure services, or coordination inefficiencies). Third, the categories were compared across the reference, ZS, and FS alternatives to identify repeated and contrasting assessments. Individual comments that disagreed with the dominant pattern were retained and considered in the interpretation rather than being forced into consensus. No inter-rater reliability statistic was calculated for this author-led synthesis. The

• Correctness: the extent to which the proposed services, assigned responsibilities, and interactions are traceable to the stated requirements and do not contradict them. Unsupported responsibilities or dependencies reduce correctness; 8

From Textual Requirements to Microservice Architectures

Conference’17, July 2017, Washington, DC, USA

procedure supports RQ4 by making the consolidation process transparent and helps interpret the RQ3 ratings, while its interpretive nature is acknowledged as a reliability limitation.

5

additional services. Under FS prompting, the model again generated eight services, successfully recovering all seven expected services while introducing only one additional service. Across both systems, ZS produced 11 correct services out of 14, with three missing and three extra services overall. In contrast, FS recovered all 14 expected services and introduced only one additional service. These results indicate that FS consistently improves coverage while reducing structural inconsistencies in the generated architectures. Metric-based evaluation. Figure 3 presents the corresponding precision, recall, and F1-score values.

Results

This section reports the empirical results according to the four research questions introduced in Section 4. We first present structural agreement for service identification (Section 5.1) and inter-service communication recovery (Section 5.2). We then report the expert ratings of perceived architectural quality (Section 5.3) and the structured descriptive synthesis of recurring strengths, weaknesses, and design patterns (Section 5.4). The experiments were conducted in May and June 2025 using OpenAI o3 via the OpenAI API. Each reported ZS or FS architecture corresponds to one execution, so the values characterize these recorded outputs and should not be interpreted as estimates of run-to-run stability. All artifacts—including prompts, generated outputs, normalized architectures, and evaluation materials—are available in the supplementary repository [4].

5.1

Identification of Microservice Components from Requirements (RQ1)

RQ1 investigates whether the LLM can infer the microservice components of a system directly from natural-language requirements. Figure 2 summarizes the results for both case studies and prompting conditions.

Figure 3: Precision, Recall, and F1-score for service identification across prompting strategies. The metric analysis confirms the trends observed in the raw data. In the Bookstore system, the F1-score increases from 0.77 under ZS to 1.00 under FS, reflecting both complete recovery and the absence of spurious services. In the PetClinic system, the F1-score increases from 0.80 to 0.93, indicating improved completeness and a reduction in over-segmentation. At the aggregated level, ZS achieves a precision of 0.79, a recall of 0.79, and an F1-score of 0.79. In contrast, FS achieves a precision of 0.93, perfect recall of 1.00, and an F1-score of 0.97. These improvements demonstrate that FS enhances both dimensions simultaneously, increasing coverage while constraining unnecessary service generation. Joint analysis and interpretation. Taken together, the raw and metric-based results reveal a consistent pattern. Under ZS, the model exhibits two types of errors: (i) missing services, indicating incomplete coverage of the domain, and (ii) extra services, suggesting over-segmentation of responsibilities. These behaviors vary with system complexity but consistently yield moderate precision and recall. In contrast, FS significantly reduces both types of errors. The elimination of missing services across both systems indicates that the model becomes more sensitive to requirement coverage, while the reduction of extra services suggests improved control over granularity. This indicates that the FS example provides implicit

Figure 2: Evaluation of services identified by prompt strategies. Analysis of raw results. The raw counts reveal distinct behaviors across prompting strategies. In the Bookstore system, the ZS condition generated six services, correctly identifying five of the seven expected services, missing two, and introducing one additional service. In contrast, the FS condition produced exactly the seven expected services, with no omissions or extra components, achieving perfect alignment with the reference decomposition. In the PetClinic system, which exhibits higher domain complexity, the ZS condition generated eight services, correctly identifying six of the seven expected services, missing one, and introducing two 9

Conference’17, July 2017, Washington, DC, USA

Silva et al.

Metric-based evaluation. Figure 5 presents the corresponding precision, recall, and F1-score values.

structural guidance, helping the model calibrate the decomposition process. Answer to RQ1. The results indicate that LLMs can infer microservice components directly from natural-language requirements with high effectiveness. While ZS prompting yields moderately accurate decompositions, FS prompting substantially improves both completeness and precision, enabling near-perfect recovery of service boundaries across different systems. This suggests that minimal exemplar-based guidance is sufficient to transform LLM outputs into reliable architectural decompositions.

5.2

Recovery of Inter-Service Communication Links (RQ2)

RQ2 evaluates whether the LLM can recover the communication relationships among services defined in the reference architectures. Figure 4 reports the interaction-level results.

Figure 5: Precision, Recall, and F1-score for inter-services communication across prompting strategies. The metric analysis confirms the trends observed in the raw data. In the Bookstore system, the F1-score increases from 0.67 under ZS to 0.86 under FS, reflecting both improved completeness and reduced over-generation. In the PetClinic system, the F1-score increases from 0.59 to 0.80, indicating that FS improves alignment even in more complex interaction graphs, where the number of potential dependencies is higher and more difficult to infer accurately. At the aggregated level, ZS achieves a precision of 0.48, a recall of 0.84, and an F1-score of 0.61. In contrast, FS achieves a precision of 0.72, a recall of 0.95, and an F1-score of 0.82. These results highlight a key characteristic of the interaction-recovery task: recall remains consistently high across both strategies, suggesting that the model generally captures relevant interactions, while precision varies substantially with the level of over-generated connections. This indicates that the primary challenge lies not in identifying potential interactions but in filtering out those that do not meet the requirements. Joint analysis and interpretation. Taken together, the results reveal a systematic behavior of LLMs in interaction inference. Under ZS prompting, the model tends to produce densely connected architectures, recovering most expected interactions but introducing many unsupported links. This results in high recall but low precision, particularly evident in the PetClinic system. In contrast, FS prompting significantly reduces over-connectivity while preserving high recall. Although some extra links remain, especially in the more complex system, the reduction is substantial, leading to a more balanced trade-off between completeness and correctness. This suggests that FS examples act as implicit constraints on interaction patterns, helping the model avoid excessive connectivity and produce more realistic architectural structures. Importantly, the interaction-recovery task remains more challenging than service identification. Even under FS prompting, the

Figure 4: Inter-Service communication identified by prompt strategies. Analysis of raw results. The raw interaction counts reveal a consistent pattern across both systems, characterized by high coverage but substantial over-generation under the ZS condition. In the Bookstore system, ZS produced 18 interactions, correctly matching 10 of the 12 expected links, missing two, and introducing eight additional connections. Under FS prompting, all 12 expected interactions were recovered, and the number of extra links was reduced to four. In the PetClinic system, which involves a more complex interaction structure, ZS generated 48 interactions, correctly identifying 22 of the 26 expected links, missing four, and introducing 26 additional connections. Under FS prompting, the model generated 34 interactions, correctly matching 24 of the 26 expected links, with two missing and 10 additional links. Across both systems, ZS correctly recovered 32 of the 38 reference interactions, with 6 missing and 34 extra links overall. In contrast, FS recovered 36 of the 38 interactions, reducing missing links to 2 and extra links to 14. These results indicate that while both strategies achieve high coverage, FS significantly reduces the number of spurious interactions. 10

From Textual Requirements to Microservice Architectures

Conference’17, July 2017, Washington, DC, USA

model continues to introduce additional links, indicating that inferring precise interaction structures from textual requirements requires not only identifying relevant services but also reasoning about coordination patterns, data flow, and dependency necessity.

tends to prioritize coverage at the expense of architectural discipline, leading to overly dense, highly coupled designs. These results are consistent with RQ2, which found that ZS exhibited high recall but low precision due to excessive interaction generation. The reference architectures occupied an intermediate position across all dimensions. They achieved relatively strong modularity (e.g., 4.00 in Bookstore), indicating well-structured and coherent designs, but lower completeness compared to ZS and FS. This suggests that the implemented architectures are conservative in scope, prioritizing stability and clarity over exhaustive requirement coverage. Interestingly, this pattern highlights a key contrast between humandesigned and LLM-generated architectures: while human-designed systems tend to avoid unnecessary complexity, LLM-generated solutions—especially under ZS—tend to over-generalize, introducing additional elements and interactions. The observed patterns remain consistent across both case studies, despite differences in domain complexity. In both Bookstore and PetClinic, FS dominates across all dimensions, ZS shows a clear imbalance between completeness and structural quality, and the reference architectures remain stable but less comprehensive. This consistency strengthens the validity of the findings and suggests that the effects of prompting strategies are robust across different domains. Importantly, these results provide insight into how LLMs perform architectural reasoning under different prompting conditions. While ZS prompting encourages aggressive requirementto-structure mapping and prioritizes coverage, FS prompting introduces implicit structural constraints that guide the model toward more coherent and modular designs. This highlights the critical role of contextual grounding in enabling effective architectural reasoning with LLMs.

Answer to RQ2. The results indicate that LLMs can recover most inter-service interactions from textual requirements, achieving consistently high recall across both prompting strategies. However, ZS prompting tends to yield overly dense interaction graphs with many unsupported links, leading to low precision. FS prompting substantially improves this behavior by reducing overgenerated connections while maintaining high coverage, leading to more balanced and plausible interaction structures. Nevertheless, interaction recovery remains more challenging than service identification, particularly in systems with higher structural complexity.

5.3

Quantitative Assessment of Architectural Quality by Experts (RQ3)

RQ3 examines how software architecture experts evaluate the generated architectures based on structured quantitative criteria. The evaluation was conducted in a blinded setting, where three architectural alternatives were presented anonymously as Architectures A (reference), B (ZS), and C (FS). Experts assessed each alternative across four dimensions: correctness, completeness, modularity, and plausibility, using a five-point Likert scale. Figure 6 summarizes the average scores assigned by the experts for both systems. Across both systems, the FS architectures consistently achieved the highest scores in nearly all evaluation dimensions. In the Bookstore system, FS reached 4.75 in correctness, 4.50 in completeness, 4.00 in modularity, and 4.50 in plausibility. A similar pattern was observed in the PetClinic system, where FS achieved 4.50, 4.00, 4.00, and 4.50, respectively. These results indicate that FS improves structural alignment with the requirements (correctness and completeness), and enhances perceived design quality (modularity and plausibility). The superior performance of FS architectures can be interpreted as a direct consequence of the structural guidance provided by exemplar-based prompting. Unlike ZS, which relies solely on implicit reasoning, FS appears to constrain the architectural search space, leading to solutions that are both comprehensive and structurally coherent. This aligns with the improvements observed in RQ1 and RQ2, where FS achieved near-perfect service identification and significantly reduced spurious interactions. Together, these findings suggest that FS enables the model to better balance coverage and organization. On the other hand, the ZS architectures exhibited a distinct quantitative profile characterized by high completeness but low plausibility and modularity. In both systems, ZS achieved relatively high completeness scores (4.25 in Bookstore and 3.75 in PetClinic), often exceeding the reference architectures. This indicates that ZS is effective at capturing a broad set of functional elements from the requirements. However, this gain is accompanied by a significant degradation in structural quality. Plausibility scores dropped to 2.00 in both systems, and modularity was notably lower (e.g., 2.50 in Bookstore). This divergence reflects a fundamental trade-off: ZS

Answer to RQ3. The quantitative expert evaluation indicates that FS prompting produces the highest-quality architectural proposals across correctness, completeness, modularity, and plausibility. While ZS prompting tends to increase completeness, it does so at the expense of plausibility and modularity. The reference architectures exhibit balanced but less comprehensive designs. Overall, FS prompting yields the most consistently well-rated architectures across both systems.

5.4

Qualitative Assessment of Architectural Strengths and Weaknesses (RQ4)

RQ4 investigates how experts perceive the architectural trade-offs introduced by different prompting strategies, focusing on recurring strengths, weaknesses, design patterns, and improvement suggestions. While RQ1 and RQ2 quantify structural alignment and RQ3 captures perceived quality through ratings, this analysis provides a deeper interpretation of why certain architectures are preferred, revealing how prompting influences architectural reasoning. To support this analysis, we examine expert feedback across two systems (Bookstore and PetClinic) and organize the discussion around three architectural variants (i.e., Reference, ZS, and FS). For each case, we analyze qualitative responses across strengths, weaknesses, surprising design choices, and suggested improvements. Bookstore system. Figure 7 provides a structural overview of the three architectural alternatives for the Bookstore system, 11

Conference’17, July 2017, Washington, DC, USA

Silva et al.

Figure 6: Average expert ratings for RQ3. highlighting clear differences in both the number of services (RQ1) and the density of inter-service connections (RQ2). At a high level, the reference architecture exhibits a compact and centralized structure, with a limited number of services and a relatively sparse interaction graph. This aligns with the results of RQ1 and RQ2, which showed that the reference solution achieved balanced service identification and a controlled number of interactions, resulting in a structurally coherent but functionally restrained design. In contrast, the ZS architecture presents a visibly denser and more complex interaction topology. Although it introduces additional services—consistent with the slight over-generation observed in RQ1—the most prominent difference lies in the number and directionality of connections. The interaction graph is highly interconnected, with multiple bidirectional links and cross-service dependencies, reflecting the high number of extra interactions identified in RQ2. This results in an architecture that is functionally expressive but structurally overloaded. The FS architecture occupies an intermediate position between these two extremes. While maintaining a service set comparable to the reference (RQ1), it introduces a richer interaction structure without reaching the level of over-connectivity observed in ZS (RQ2). The resulting topology appears more organized, with clearer communication paths and fewer redundant links, suggesting a more controlled expansion of the architecture. Taken together, these visual differences reinforce the quantitative findings from RQ1 and RQ2: while ZS tends to increase both service and interaction counts, leading to dense, potentially overconnected architectures, FS achieves a more balanced structure, preserving coverage while improving interaction organization. Qualitative analysis of expert feedback. The qualitative responses were analyzed across four dimensions: strengths, weaknesses, surprising design choices, and suggested improvements. These findings complement the quantitative results of RQ3 by explaining the patterns observed in expert ratings. Reference architecture. The reference architecture was consistently described as simple, well-structured, and easy to understand.

Experts highlighted the clear separation of responsibilities and the Order Service’s central role in coordinating the purchasing workflow. Low coupling and straightforward interactions were perceived as key strengths, as illustrated by comments such as “simple modules, low coupling” and “clear and understandable service definitions”. These perceptions are consistent with the relatively strong modularity scores observed in RQ3. However, several limitations were identified, particularly regarding functional coverage and service integration. Reviewers noted that some services were weakly connected or absent from the main workflow (e.g., “Auth Service does not participate in the cart or order flow”), which helps explain the lower completeness scores assigned to the reference architecture. The concentration of logic in the Order Service (e.g., “too much logic in Order Service”) was also identified as a potential structural risk. ZS architecture. This architecture was consistently associated with strong functional coverage, which aligns with its higher completeness scores in RQ3. Experts noted that most relevant services were present and connected (e.g., “complete coverage of functional requirements”), indicating that the model captured a broad set of domain responsibilities. However, this increased coverage came at the cost of structural quality. Reviewers frequently described excessive coupling and unnecessary interactions, with comments such as “Most microservices are coupled with each other” and “relationships between services seem unnecessary”. These observations provide a direct explanation for the lower modularity and plausibility scores observed in RQ3. Additional concerns regarding maintainability and scalability (e.g., “difficult to scale” and “It will be hard to maintain”) further reinforce the interpretation that ZS produces architectures that are functionally complete but structurally overloaded. FS architecture. This architecture received the most balanced qualitative evaluation, which is consistent with its superior performance across all quantitative dimensions in RQ3. Experts highlighted clearer service boundaries and more coherent interaction flows (e.g., “clear functional boundaries and clearer flows”), indicating improved structural organization compared to ZS.

12

From Textual Requirements to Microservice Architectures

Conference’17, July 2017, Washington, DC, USA

Figure 7: Comparison between the architectural variants for the Bookstore system. At the same time, FS maintained broad functional coverage, contributing to its high completeness scores. This combination of coverage and structural clarity explains the consistently high ratings across correctness, modularity, and plausibility. Nevertheless, some residual issues were still identified, particularly related to remaining dependencies in central services (e.g., “Order remains over-connected”) and unexpected design elements (e.g., “Auth service appears without an explicit requirement”). These observations help contextualize why FS, while superior, does not fully eliminate all structural concerns. PetClinic system. Figure 8 presents the architectural variants for the PetClinic system. Compared to the Bookstore case, this system exhibits a richer domain and a more complex interaction topology, making it a more demanding scenario for architectural inference. In the PetClinic case, the reference architecture was described as simple and restrained, with a clear overall structure. However, several reviewers questioned missing service responsibilities and limited functional decomposition, suggesting that the architecture underrepresented some domain aspects. The ZS architecture was again associated with both high functional coverage and structural complexity. Experts frequently reported excessive coupling, gateway-centered communication patterns, and bidirectional flows, all of which increased architectural complexity. The presence of auxiliary or loosely defined services was also noted, raising concerns about clarity and maintainability. The FS architecture was evaluated as the most balanced alternative. Reviewers highlighted improved organization of veterinarydomain services, clearer separation between responsibilities, and more consistent interaction patterns. Although some additional links remained, the architecture was generally perceived as more coherent and operationally plausible than the ZS variant. Qualitative analysis of expert feedback. The qualitative responses were analyzed across four dimensions: strengths, weaknesses, surprising design choices, and suggested improvements. These findings also complement the quantitative results of RQ3 by explaining the patterns observed in expert ratings.

Reference architecture. The reference architecture was generally perceived as simple and relatively easy to understand. Experts highlighted the presence of “Services are well identified” and a “The call flow seems realistic and consistent”, suggesting that the architecture provides a coherent and interpretable interaction structure. The relatively low number of connections was also considered a strength, as reflected in comments such as “low number of unnecessary connections” and “few modules (microservices)”, indicating a lean and straightforward design. These characteristics are consistent with the moderate-to-high modularity scores observed in RQ3. However, several limitations were identified. A recurring concern was the lack of important domain services, particularly the absence of a Pet Service (e.g., “No pet service created in the diagram” and “Services like Pet Service are lacking”). Experts also noted excessive reliance on infrastructural components, especially the Admin Server (e.g., “Heavy reliance on Admin Server” and “Configuration Service is only available through the admin server”). Additionally, some responsibilities appeared duplicated or unclear (e.g., “Modules with apparently duplicate responsibilities”), and certain interactions were considered poorly defined. These issues help explain the lower completeness scores observed in RQ3, as the architecture, while simple, fails to fully capture the domain structure. ZS architecture. This architecture was consistently associated with strong functional coverage. Experts emphasized that “All required services are available” and “all required services identified”, indicating that the model successfully captured most domain elements. The placement of the API Gateway was also considered appropriate (e.g., “API Gateway in correct position”), reinforcing the perception of improved structural alignment compared to the reference. However, this improved coverage came at the cost of structural quality. A dominant issue across evaluations was excessive coupling, with multiple experts highlighting that “all the microservices are unnecessarily connected” and “excessive coupling”. The architecture was frequently described as overly dense, with comments such as

13

Conference’17, July 2017, Washington, DC, USA

Silva et al.

Figure 8: Comparison between the architectural variants for the PetClinic system. Answer to RQ4. Qualitative feedback indicates that ZS prompting tends to produce architectures with high functional coverage but excessive coupling and limited plausibility. FS prompting, in contrast, leads to more modular, coherent, and interpretable architectures, while still maintaining broad coverage. These findings suggest that prompting strategies directly influence the structural quality of LLM-generated designs, with FS prompting yielding more balanced and realistic architectural solutions across different systems.

“connecting everything with everything” and “All the services seem to be calling each other”. Another critical issue concerns the misuse of architectural roles. Experts noted that the Gateway was being invoked internally (e.g., “Gateway receives calls from other services” and “Gateway invoked internally, which breaks its entry-point role”), which violates its expected behavior. Similarly, Admin and Config services were seen as excessively central (e.g., “They appear in the middle of everything, which is neither necessary nor scalable”). These issues directly explain the lower modularity and plausibility scores observed in RQ3, indicating that while ZS improves completeness, it produces architectures that are difficult to maintain, scale, and justify structurally. FS architecture. This architecture received the most balanced qualitative evaluation, aligning with its superior performance in RQ3. Experts highlighted improvements in structural clarity and organization, with comments such as “cleaner and more controlled flow”, “cleaner, scoped flow with a single-entry gateway”, and “Good separation between Client, Pet, Visit, and Vet”. The correct positioning of the API Gateway as a single entry point was also emphasized (e.g., “API Gateway correctly positioned as main entry”), reinforcing a more disciplined architectural structure. In addition to improved modularity, FS maintained adequate functional coverage, which explains its high completeness and correctness scores. The architecture also showed reduced coupling compared to ZS (e.g., “relatively low coupling among the identified microservices”), indicating better control over service interactions. Nevertheless, some residual issues were still identified. Experts noted remaining unnecessary dependencies, particularly involving the Admin Service (e.g., “Admin still over-connected” and “The Admin Service continues to have more connections than necessary”). There were also concerns about unclear or unjustified links (e.g., “gateway ↔ Config path unclear” and “double arrow between Config and Admin feels out of scope”). Additionally, some design elements, such as the inclusion of certain infrastructural services, were perceived as not directly derived from the requirements (e.g., “Inclusion of API Gateway, which doesn’t seem to come strictly from the requirements”). These observations indicate that, although FS significantly improves architectural balance, it does not fully eliminate all inconsistencies. Still, compared to the other alternatives, it produces the most coherent and plausible architectural design.

6

Analysis

This section deepens the interpretation of the original findings through a secondary analysis of the quantitative results, generated architectural artifacts, and expert assessments. Rather than introducing new experiments, it reexamines the evidence already reported in the study to better characterize prompting effects, architectural error patterns, and expert evaluation dynamics. Comparative Secondary Analysis of Prompting Effects. A secondary reading of the quantitative results suggests that a key effect of FS prompting is not limited to higher accuracy. More fundamentally, it appears to introduce a form of structural discipline on the mapping between textual requirements and architectural decomposition. Across the two case studies, FS prompting produces a more consistent alignment with the reference architectures than ZS prompting, both in service identification and in inter-service communication recovery. In service identification, the reported F1 values increase from 0.77 to 1.00 in Bookstore and from 0.80 to 0.93 in PetClinic. In communication recovery, the same tendency is observed, with F1 increasing from 0.67 to 0.86 in Bookstore and from 0.59 to 0.80 in PetClinic. This difference is analytically relevant because the gain is not uniform across tasks. The improvement is greater and cleaner for service discovery than for communication recovery. This indicates that the model is more reliable at inferring candidate service boundaries from requirements than at reconstructing the full service dependency topology. In other words, the question of what services should exist appears easier for the model than the question of how those services should interact. From an architectural standpoint, this distinction is important because it places LLMs in a stronger position for early decomposition support than for precise interaction design. 14

From Textual Requirements to Microservice Architectures

Conference’17, July 2017, Washington, DC, USA

A cross-case comparison reinforces this interpretation. FS prompting improves both systems, but the improvement is more limited in the more interaction-heavy case. PetClinic still exhibits residual noise even under FS prompting, especially in communicationlevel recovery, suggesting that increasing architectural complexity amplifies the model’s tendency to introduce plausible but weakly justified dependencies. Thus, FS prompting should be interpreted less as a guarantee of correctness and more as a constraint mechanism that narrows the architectural search space. Taxonomy of Architectural Error Patterns The generated outputs also enable the identification of recurring categories of architectural error. A first pattern is the omission of low-salience responsibilities. Services that are weakly emphasized or only indirectly implied in the requirements are more likely to be omitted, particularly in ZS prompting. This suggests that the model privileges lexical prominence and central business entities when inferring service boundaries. A second pattern is the introduction of plausible but unsupported services. The study reports cases in which the model generates components, such as administrative, auditing, configuration, notification, or infrastructure-related services, that are architecturally reasonable in general but not sufficiently grounded in the requirements. These are not arbitrary hallucinations; they are better understood as overextensions of learned microservice design priors. A third pattern is topological inflation. Especially in ZS prompting, the model tends to create communication structures with too many edges, sometimes including bidirectional or cyclic dependencies. This is evident in the denser designs generated and is also reflected in expert criticism regarding maintainability, scalability, and role ambiguity. Such outputs may look comprehensive, but they weaken the separation of concerns and make the resulting architecture harder to justify operationally. A fourth pattern is boundary blurring between domain services and platform concerns. Some generated architectures treat gateway or infrastructure-oriented components as if they were central business services, or mix crosscutting concerns directly into core domain flows. This reduces conceptual clarity and affects modularity. Taken together, these patterns show that the model’s mistakes are structured rather than random. They emerge when requirements are underspecified, when generic architectural priors become dominant, and when prompting does not adequately constrain the space of acceptable decompositions. Cross-Case Analysis of Expert Perceptions The expert evaluation becomes more informative when interpreted as evidence of a quality trade-off, rather than merely a ranking. In both case studies, the FS architecture is the only generated variant that more consistently combines functional coverage with acceptable structural organization. By contrast, ZS outputs are not penalized primarily for lack of functionality, but for how they achieve coverage: excessive coupling, unclear service responsibilities, and implausible communication structures. This point is especially important because the experts evaluated the architectures along four distinct dimensions: correctness, completeness, modularity, and plausibility. The pattern reported in the study suggests that higher completeness alone is not enough to make a generated architecture acceptable. Experts appear to

value completeness only when it is delivered with coherent modular boundaries and realistic interaction design. This explains why architectures that seem richer in functionality may still receive lower plausibility assessments. The reference architectures also play an analytically useful role. They are not necessarily idealized solutions, but real, implemented decompositions that reflect practical trade-offs. Their comparison with the generated variants shows that architectural acceptance is shaped by whether the expected functions are present and whether the decomposition remains understandable, maintainable, and operationally credible. The FS condition stands out precisely because it approximates that balance more closely than the ZS condition. This distinction also affects the interpretation of precision, recall, and F1-score. A high score indicates close agreement with the selected implementation, not proof that the generated design is universally superior. Conversely, an element counted as extra may represent a plausible alternative boundary, infrastructure component, or interaction that is absent from the baseline. Such alternatives reduce structural precision by definition, but their architectural merit must be judged using requirement traceability and expert assessment. The quantitative and expert results are therefore complementary rather than interchangeable.

7

Implications

The findings of this study have implications for research, practice, and tool support at the intersection of software architecture, requirements engineering, and intelligent design support. Implications for research. The findings provide insights into how LLMs perform in requirements-driven architectural design and highlight directions for improving their effectiveness. In particular, they reveal task-specific limitations, structured error patterns, and the role of prompting in shaping architectural outcomes. • Service identification vs. interaction modeling. The results suggest that identifying service boundaries is a more tractable task for LLMs than recovering inter-service communication structures. This indicates that decomposition and interaction modeling should be treated as distinct subproblems, potentially requiring different prompting strategies or additional constraints tailored to each task. • Prompting as a control mechanism. FS prompting does more than improve accuracy; it appears to regularize architectural generation by constraining the search space, reducing omissions, and limiting unsupported additions. This highlights prompting as a mechanism that shapes architectural reasoning, rather than merely formatting model input. • Structured error patterns. The observed errors—such as the omission of low-salience responsibilities, the introduction of plausible but unsupported services, and the over-generation of interactions—suggest that model outputs are influenced by learned architectural priors. This motivates future research on error-aware prompting strategies, richer exemplars, and domain-constrained generation approaches. • Hybrid evaluation is necessary. Structural similarity metrics alone do not fully capture architectural quality. The results reinforce the need for hybrid evaluation approaches that 15

Conference’17, July 2017, Washington, DC, USA

Silva et al.

combine quantitative alignment with expert judgment, enabling assessment of modularity, plausibility, and operational feasibility. Implications for practice. The results indicate how practitioners can effectively use LLMs to support architectural design activities. They highlight both the potential of LLMs as assistants in early-stage decomposition and the conditions under which their outputs are more reliable and actionable. • Support for early-stage design. LLMs can assist practitioners in generating initial microservice decompositions directly from textual requirements, which is particularly valuable in early design stages where architectural artifacts are still limited or evolving. • Few-shot prompting improves reliability. The results show that even a single well-structured exemplar can substantially improve architectural quality, increasing coverage while reducing overgeneration. This makes FS prompting a practical and low-cost strategy for improving LLM outputs in realworld settings. • Human-in-the-loop is essential. Generated architectures should be treated as decision-support artifacts rather than final designs. While LLMs can accelerate decomposition, expert validation remains necessary to refine interaction structures, resolve ambiguities, and ensure architectural plausibility. • Dependence on requirement quality. The effectiveness of LLMgenerated architectures depends strongly on the clarity and consistency of input requirements. This reinforces the importance of well-structured requirement descriptions, clear domain terminology, and reduced ambiguity in requirement engineering practices. Implications for tool support. The study identifies opportunities to incorporate LLM-based architectural synthesis into software design tools. These insights point to new ways of supporting interactive, requirements-driven architectural exploration within development environments. • Integration into design environments. LLM-based architectural synthesis can be integrated into modeling tools and development environments to automatically generate initial service decompositions from requirement documents, supporting faster design initialization. • Interactive architectural exploration. Such tools can enable iterative refinement of architectures through natural-language interaction, allowing practitioners to explore alternative decompositions and adjust design decisions dynamically. • Improved traceability. Integrating LLMs into design workflows may strengthen traceability between requirements and architectural artifacts, helping maintain alignment between business intent and system structure throughout the development lifecycle. Overall, the findings position OpenAI o3 as a promising assistant for requirements-driven architectural exploration in the two bounded cases studied. Its primary observed value lies in accelerating early decomposition and expanding the design space, while its main limitation remains the need for human validation, particularly for interaction design and architectural plausibility. Generalization

to other LLMs, larger systems, and more complex organizational settings requires independent replication.

8

Threats to Validity

We discuss potential threats to validity following the four dimensions commonly adopted in empirical software engineering: construct validity, internal validity, external validity, and reliability [48]. Construct Validity. A first construct-related threat concerns the use of the implemented architectures as reference baselines. The selected repositories provide concrete decompositions and dependency records, but they are not guaranteed to be optimal, exhaustive, or representative of industrial microservice practice. Static extraction can also miss dynamic or externally configured dependencies. We therefore treat precision, recall, and F1-score as measures of agreement with these particular implementations rather than measures of architectural quality. Blinded expert evaluation was added to assess whether generated alternatives—including elements counted as extra relative to the baseline—were perceived as correct, complete, modular, and plausible. A second construct-related threat concerns how correspondence was established between the generated and reference architectures. Because service names and granularity may vary across decompositions, the comparison relied on lexical identity and the semantic alignment of responsibilities. While this choice avoids unfair penalization of alternative but reasonable labels, it also introduces interpretive judgment into the matching procedure. We mitigated this threat by applying explicit comparison criteria and documenting the resulting artifacts in the supplementary material. A third threat concerns the evaluation criteria themselves. Metrics such as precision, recall, and F1-score capture overlap with the reference architecture, but they do not fully reflect architectural soundness. Likewise, expert criteria such as correctness, completeness, modularity, and plausibility improve interpretability, but they still represent a partial view of architectural quality. For this reason, we combined automated comparison with quantitative and qualitative expert assessment. Finally, the FS condition introduces a specific construct threat. The exemplar came from a different system and did not reproduce the target requirement text, but the study did not formally measure its similarity to Bookstore and PetClinic at the domain or decomposition-pattern levels. It may therefore influence the model beyond clarifying the output format by suggesting a decomposition style, granularity, or interaction density. Different exemplars could produce different outcomes. Moreover, the current design does not determine whether a more detailed natural-language instruction without an explicit example would provide equivalent guidance. A factorial comparison among concise instructions, enriched instruction-only prompts, and multiple exemplars is needed to isolate these effects. Internal Validity. A key internal validity threat is the stochastic variability of LLM outputs. The study used one execution for each system and prompting condition; consequently, it does not quantify variance 16

From Textual Requirements to Microservice Architectures

Conference’17, July 2017, Washington, DC, USA

across repeated runs or establish the stability of the reported decompositions. Keeping the API configuration and prompt templates unchanged and releasing the exact outputs improves procedural reproducibility, but it does not eliminate sampling variability. Prompt phrasing, platform updates, and model-version changes may also alter the results. Future replications should use multiple independent executions per condition and report distributions or confidence intervals for the structural metrics. Another internal threat concerns the curation of the textual requirements. Although the curation process was intended only to reduce redundancy, ambiguity, and lexical inconsistency, any reformulation of the original requirements may affect what the model perceives as architecturally salient. We mitigated this by preserving the original functionality and business intent of the systems and by using the same curated requirements across prompting conditions. A further threat concerns expert evaluation. Although the experts had relevant professional experience and reviewed the architectures under blinded and randomized conditions, their judgments may reflect individual preferences, prior architectural beliefs, or different interpretations of the four dimensions. We mitigated ambiguity by providing explicit operational definitions and by retaining individual ratings and divergent comments instead of forcing consensus. Nevertheless, the small expert sample and the descriptive consolidation limit statistical and interpretive generalization. External Validity. This study was conducted on two relatively small systems with well-documented requirements: Bookstore and PetClinic. Their bounded size, limited number of services, and comparatively clear domains are suitable for controlled inspection, but they do not represent the scale, heterogeneity, legacy constraints, or interaction complexity of many industrial systems. The observed results may therefore change for larger architectures, safety-critical domains, noisy or conflicting requirements, and systems with asynchronous, event-driven, or dynamically configured dependencies. A related external-validity threat concerns model, language, and artifact style. All prompts and curated requirements were written in English, and all generations used OpenAI o3. The findings directly support conclusions about this model in the reported setting, not about every state-of-the-art LLM. Replication should cover additional case studies, substantially larger systems, multilingual and less standardized requirements, multiple model families and versions, and repeated executions within each condition. Reliability. Reliability concerns the replicability of the study procedures and findings. To support reproducibility, we released the curated requirements, reference architectures, prompt templates, generated outputs, evaluation forms, and supporting materials in a public repository [4]. We also documented the main stages of the study, including artifact preparation, generation, normalization, comparison, and expert assessment. However, some threats remain. Model behavior may change over time due to API, platform, or model-version updates beyond our control; recording the execution period, prompts, and outputs supports auditability but cannot guarantee identical future responses. The synthesis of open-ended comments was author-led and descriptive: responses were organized, grouped by semantic similarity, and compared across alternatives, but no independent coding

round or inter-rater agreement statistic was used. Researcher interpretation may therefore affect the resulting categories. Future work should preregister a formal qualitative protocol, employ independent coders, report agreement and disagreement-resolution procedures, and preserve a complete audit trail from quotations to categories.

9

Final Remarks

This study investigated whether an LLM, specifically the OpenAI o3 model, can synthesize microservice architectural descriptions directly from natural-language requirements. To this end, we evaluated the model’s ability to identify service boundaries, responsibilities, and inter-service interactions across two representative software systems under ZS and FS prompting strategies. For RQ1, the recorded OpenAI o3 outputs recovered most reference services from requirements alone, even in the ZS condition. Across the two systems, ZS correctly identified 11 of the 14 expected services, with a precision, recall, and F1-score of approximately 0.79. Under FS prompting, the model recovered all 14 expected services and introduced only one extra service overall, increasing precision to 0.93, recall to 1.00, and F1-score to approximately 0.97. In this evaluated setting, exemplar-based prompting produced closer agreement with the implemented service boundaries. For RQ2, the same general pattern emerged, although interaction recovery proved more challenging than service identification. In ZS, the model recovered most of the expected communication links, but at the cost of substantial over-generation, yielding high recall (0.84) but low precision (0.48), with an F1-score of approximately 0.61. Under FS prompting, interaction recovery improved considerably: the model correctly recovered 36 of the 38 expected links, while substantially reducing unsupported connections, resulting in a precision of 0.72, a recall of 0.95, and an F1-score of approximately 0.82. This suggests that FS prompting improves coverage and constrains the tendency of the model to produce overly dense architectural topologies. For RQ3, expert evaluation showed that the FS architectures were the most positively perceived alternatives across both case studies. Experts rated them highest in correctness, completeness, and plausibility, indicating that they provided the best balance between requirement coverage and architectural organization. In contrast, the ZS architectures were often seen as functionally rich but structurally risky, mainly due to excessive coupling and implausible interaction patterns. The reference architectures were generally perceived as cleaner and more stable, but also less comprehensive in functional coverage. Taken together, these results indicate that architectural usefulness depends on achieving both functional coverage and structurally coherent decomposition. For RQ4, the qualitative analysis further showed that the limitations of LLM-generated architectures are not random, but concentrated in recurring patterns such as omitted low-salience responsibilities, unsupported infrastructural additions, and overly dense communication structures. These patterns help explain expert preferences and provide useful guidance for future prompt design and architectural review workflows. Overall, the findings provide bounded empirical evidence that OpenAI o3 can support requirements-driven microservice design 17

Conference’17, July 2017, Washington, DC, USA

Silva et al.

as an assistant for early-stage architectural exploration. Its main observed strength lies in identifying candidate services and rapidly proposing alternatives from textual requirements. Interaction design remains more error-prone and requires expert validation of coupling, cross-cutting concerns, and deployment plausibility. The single FS exemplar was associated with closer reference agreement and more favorable expert perceptions, but the present design cannot separate the effects of output-format demonstration, exemplarspecific structural guidance, and stochastic variation. The results therefore motivate decision-support use and further controlled evaluation, not replacement of expert-driven design. Future work should expand this investigation in at least five directions. First, replications should include substantially larger and architecturally more complex systems from additional domains, including industrial and safety-critical contexts. Second, multiple LLM families and model versions should be compared, with repeated independent executions per condition to quantify output variability and metric stability. Third, controlled studies should disentangle exemplar effects by comparing concise ZS prompts, richer natural-language instruction-only prompts, and multiple exemplars that vary in domain and decomposition pattern. Fourth, longitudinal human-in-the-loop studies should examine how architects revise generated decompositions and whether the suggestions improve design outcomes over time. Finally, requirement-driven synthesis should be combined with static, dynamic, and repositorybased architectural evidence so that generated alternatives can be validated against implementation constraints rather than evaluated from requirements alone.

Design Synthesis. Available at: https://doi.org/10.6084/m9.figshare.29974345.v4. (8 2026). doi:10.6084/m9.figshare.29974345.v4 [5] Khaled Alsayed and Omar Benomar. 2024. MicroDec: Hybrid Static + LLM Embeddings for Microservice Extraction. Journal of Systems and Software 203 (2024), 111622. [6] Wesley KG Assunção, Luciano Marchezan, Lawrence Arkoh, Alexander Egyed, and Rudolf Ramler. [n. d.]. Contemporary Software Modernization: Strategies, Driving Forces, and Research Opportunities. ACM Transactions on Software Engineering and Methodology ([n. d.]). [7] Mohammadmehdi Ataei, Hyunmin Cheong, Daniele Grandi, Ye Wang, Nigel Morris, and Alexander Tessier. 2025. Elicitron: A Large Language Model AgentBased Simulation Framework for Design Requirements Elicitation. Journal of Computing and Information Science in Engineering 25, 2 (2025). [8] Jacob Austin et al. 2021. Program Synthesis with Large Language Models. arXiv preprint arXiv:2108.07732 (2021). [9] Luciano Baresi, Martin Garriga, and Alan De Renzis. 2017. Microservices identification through interface analysis. In European Conference on Service-Oriented and Cloud Computing. Springer, 19–33. [10] Vincent Bushong, Amr S Abdelfattah, Abdullah A Maruf, Dipta Das, Austin Lehman, Eric Jaroszewski, Michael Coffey, Tomas Cerny, Karel Frajtak, Pavel Tisnovsky, et al. 2021. On microservice analysis and architecture evolution: A systematic mapping study. Applied Sciences 11, 17 (2021), 7856. [11] Rafael Capilla, Anton Jansen, Antony Tang, Paris Avgeriou, and Muhammad Ali Babar. 2016. 10 years of software architecture knowledge management: Practice and future. Journal of Systems and Software 116 (2016), 191–205. [12] Mark Chen et al. 2021. Evaluating Large Language Models Trained on Code. arXiv preprint arXiv:2107.03374 (2021). [13] Rudra Dhar, Karthik Vaidhyanathan, and Vasudeva Varma. 2024. Can llms generate architectural design decisions?-an exploratory empirical study. In 2024 IEEE 21st International Conference on Software Architecture (ICSA). IEEE, 79–89. [14] Nicola Dragoni et al. 2017. Microservices: yesterday, today, and tomorrow. Present and Ulterior Software Engineering (2017), 195–216. [15] Alessio Ferrari et al. 2017. Natural language processing for requirements engineering: A systematic mapping study. Comput. Surveys (2017). [16] Jonas Fritzsch, Justus Bogner, Alfred Zimmermann, and Stefan Wagner. 2018. From monolith to microservices: A classification of refactoring approaches. In International Workshop on Software Engineering Aspects of Continuous Development and New Paradigms of Software Production and Deployment. Springer, 128–141. [17] Matthias Gysel, Lukas Kölbener, Peter Gantenbein, and Olaf Zimmermann. 2016. Service cutter: A systematic approach to service decomposition. In European Conference on Service-Oriented and Cloud Computing. Springer, 185–200. [18] Hossam Hassan, Manal A Abdel-Fattah, and Wael Mohamed. 2024. Migrating from Monolithic to Microservice Architectures: A Systematic Literature Review. International Journal of Advanced Computer Science & Applications 15, 10. [19] Junda He, Christoph Treude, and David Lo. 2024. LLM-Based Multi-Agent Systems for Software Engineering: Literature Review, Vision and the Road Ahead. ACM Transactions on Software Engineering and Methodology. [20] Xinyi Hou, Yanjie Zhao, Yue Liu, Zhou Yang, Kailong Wang, Li Li, Xiapu Luo, David Lo, John Grundy, and Haoyu Wang. 2024. Large language models for software engineering: A systematic literature review. ACM Transactions on Software Engineering and Methodology 33, 8 (2024), 1–79. [21] Mohammad Imranur, Sebastiano Panichella, Davide Taibi, et al. 2019. A curated dataset of microservices-based systems. arXiv preprint arXiv:1909.03249 (2019). [22] Wuxia Jin, Ting Liu, Yuanfang Cai, R. Kazman, Ran Mo, and Q. Zheng. 2019. Service Candidate Identification from Monolithic Systems Based on Execution Traces. IEEE Transactions on Software Engineering 47 (2019), 987–1007. doi:10. 1109/tse.2019.2910531 [23] Munezero Immaculee Joselyne, Gaurav Bajpai, and Frederic Nzanywayingoma. 2021. A systematic framework of application modernization to microservice based architecture. In 2021 International Conference on Engineering and Emerging Technologies (ICEET). IEEE, 1–6. [24] Martin Kaloudis. 2024. Evolving Software Architectures from Monolithic Systems to Resilient Microservices: Best Practices, Challenges and Future Trends. International Journal of Advanced Computer Science & Applications 15, 9 (2024). [25] Goran Mazlami, Johannes Cito, and Philipp Leitner. 2017. Extraction of microservices from monolithic software architectures. In 2017 IEEE International Conference on Web Services (ICWS). IEEE, 524–531. [26] Thakshila Imiya Mohottige, Artem Polyvyanyy, Colin J. Fidge, R. Buyya, and Alistair Barros. 2025. Reengineering software systems into microservices: Stateof-the-art and future directions. Inf. Softw. Technol. 183 (2025), 107732. doi:10. 1016/j.infsof.2025.107732 [27] Sam Newman. 2015. Building Microservices. O’Reilly Media. [28] Erik Nijkamp et al. 2022. CodeGen: An Open Large Language Model for Code with Multi-Turn Program Synthesis. arXiv preprint arXiv:2203.13474 (2022). [29] Vinicius L Nogueira, Fernando S Felizardo, Aline MMM Amaral, Wesley KG Assunção, and Thelma E Colanzi. 2024. Insights on Microservice Architecture Through the Eyes of Industry Practitioners. In 2024 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 765–777.

ARTIFACT AVAILABILITY All artifacts used in this study — including requirements, prompting strategies, architectural outputs, evaluation scripts, and expert review templates — are available to ensure transparency, facilitate replication, and support future research endeavors [4].

ACKNOWLEDGMENTS This work has been partially funded by the project “iSOP Base: Investigação e desenvolvimento de base arquitetural e tecnológica da Intelligent Sensing Operating Platform (iSOP)” supported by CENTRO DE COMPETÊNCIA EMBRAPII VIRTUS EM HARDWARE INTELIGENTE PARA INDÚSTRIA - VIRTUS-CC, with financial resources from the PPI HardwareBR of the MCTI grant number 055/2023, signed with EMBRAPII.

REFERENCES [1] Yalemisew Abgaz, Andrew McCarren, Peter Elger, David Solan, Neil Lapuz, Marin Bivol, Glenn Jackson, Murat Yilmaz, Jim Buckley, and Paul Clarke. 2023. Decomposition of monolith applications into microservices architectures: A systematic review. IEEE Transactions on Software Engineering 49, 8 (2023), 4213– 4242. [2] Omar Al-Debagy and Péter Martinek. 2020. Extracting microservices’ candidates from monolithic applications: interface analysis and evaluation metrics approach. In 2020 IEEE 15th international conference of system of systems engineering (SoSE). IEEE, 289–294. [3] Danyllo Albuquerque, Everton Guimarães, Graziela Tonin, Pilar Rodríguezs, Mirko Perkusich, Hyggo Almeida, Angelo Perkusich, and Ferdinandy Chagas. 2022. Managing technical debt using intelligent techniques-a systematic mapping study. IEEE Transactions on Software Engineering 49, 4 (2022), 2202–2220. [4] D. W. et al Albuquerque. 2026. Supplementary Material. From Textual Requirements to Microservice Architectures: A Comprehensive Evaluation of LLM-Based 18

From Textual Requirements to Microservice Architectures

Conference’17, July 2017, Washington, DC, USA

[30] Idris Oumoussa and Rajaa Saidi. 2024. Evolution of microservices identification in monolith decomposition: A systematic review. IEEE Access 12 (2024), 23389– 23405. [31] Jose Pereira, Danyllo Albuquerque, Mirko Perkusich, Guillermo Rodríguez, Jorge Díaz-Pace, Kyller Gorgônio, and Angelo Perkusich. 2025. Toward Generating Microservice Architectures from Textual Requirements with Large Language Models. In Anais do XIX Simpósio Brasileiro de Componentes, Arquiteturas e Reutilização de Software (Recife/PE). SBC, Porto Alegre, RS, Brasil, 79–89. doi:10.5753/sbcars.2025.14591 [32] Francisco Ponce et al. 2019. Towards a systematic mapping study on microservices architecture. Journal of Systems and Software (2019). [33] Sivakumar Ponnusamy and Dinesh Eswararaj. 2023. Navigating the modernization of legacy applications and data: Effective strategies and best practices. Asian Journal of Research in Computer Science 16, 4 (2023), 239–256. [34] Yamina Romani, Okba Tibermacine, and Chouki Tibermacine. 2022. Towards migrating legacy software systems to microservice-based architectures: a datacentric process for microservice identification. In 2022 IEEE 19th International Conference on Software Architecture Companion (ICSA-C). IEEE, 15–19. [35] Ana Martínez Saucedo, J Andres Diaz-Pace, Hernán Astudillo, and Guillermo Rodríguez. 2024. On the Variability of Microservice Decompositions: A DataDriven Analysis. In 2024 L Latin American Computer Conference (CLEI). IEEE, 1–9. [36] Ana Martínez Saucedo and Guillermo Rodríguez. 2024. Migration of monolithic systems to microservices using AI: A systematic mapping study. In Congresso Ibero-Americano em Engenharia de Software (CIbSE). SBC, 1–15. [37] Ana Martínez Saucedo, Guillermo Rodríguez, Fabio Gomes Rocha, and Rodrigo Pereira dos Santos. 2025. Migration of monolithic systems to microservices: A systematic mapping study. Information and Software Technology 177 (2025), 107590. [38] Robert C Seacord, Daniel Plakosh, and Grace A Lewis. 2003. Modernizing legacy systems: software technologies, engineering processes, and business practices. Addison-Wesley Professional. [39] Khaled Sellami and Mohamed Aymen Saied. 2025. Contrastive LearningEnhanced Large Language Models for Monolith-to-Microservice Decomposition. arXiv preprint arXiv:2502.04604 (2025).

[40] Swetha Sistla. 2023. Domain-Driven Design in Modern Software Architecture Best Practices and Patterns. Journal of Mathematical & Computer Applications. SRC/JMCA-E130. DOI: doi. org/10.47363/JMCA/2024 (2) E130 J Mathe & Comp Appli 2, 1 (2023), 2–4. [41] Davide Taibi, Valentina Lenarduzzi, and Claus Pahl. 2017. Processes, motivations, and issues for migrating to microservices architectures: An empirical investigation. In IEEE Cloud Computing. [42] V Tapia and M Gaona. 2023. Research opportunities in microservices quality assessment: A systematic literature review. Journal of Advances in Information Technology 14, 5 (2023), 991–1002. [43] Imen Trabelsi, Brahim Mahmoudi, Jean Baptiste Minani, Naouel Moha, and Yann-Gaël Guéhéneuc. 2025. A systematic literature review of machine learning approaches for migrating monolithic systems to microservices. IEEE Transactions on Software Engineering (2025). [44] Victor Velepucha and Pamela Flores. 2023. A survey on microservices architecture: Principles, patterns and migration challenges. IEEE access 11 (2023), 88339–88358. [45] F. H. Vera-Rivera, C. Gaona, and H. Astudillo. 2021. Defining and measuring microservice granularity—a literature overview. PeerJ Computer Science 7 (2021). doi:10.7717/peerj-cs.695 [46] Yue Wang et al. 2023. A Survey of Large Language Models for Software Engineering. arXiv preprint arXiv:2308.xxxxx (2023). [47] Mineth Weerasinghe, Himindu Kularathne, Methmini Madhushika, Danuka Lakshan, Nisansa de Silva, Adeesha Wijayasiri, and Srinath Perera. 2026. From Monolith to Microservices: A Comparative Evaluation of Decomposition Frameworks. (2026). [48] Claes Wohlin, Per Runeson, Martin Höst, Magnus C Ohlsson, Björn Regnell, Anders Wesslén, et al. 2012. Experimentation in software engineering. Vol. 236. Springer. [49] Eberhard Wolff. 2016. Microservices: flexible software architecture. Addison-Wesley Professional. [50] Wei Zhao et al. 2023. Large Language Models for Requirements Engineering: A Survey. arXiv preprint arXiv:2305.xxxxx (2023). [51] Zibin Zheng, Kaiwen Ning, Qingyuan Zhong, Jiachi Chen, Wenqing Chen, Lianghong Guo, Weicheng Wang, and Yanlin Wang. 2025. Towards an understanding of large language models in software engineering tasks. Empirical Software Engineering 30, 2 (2025), 50.

19