Paper deep dive
From Code to Requirements: Agentic Reverse Engineering of Business Rules at Enterprise Scale
Garima Agrawal, Prasun Das, Priyanka L, Minisha N, Akshay Sarvade, Hemath Manivanan, Sravani Joshna, Prasad Kalyansundaram
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 93%
Last extracted: 9/22/2026, 5:10:27 AM
Summary
This paper introduces an agentic framework for automatically generating Business Requirements Documents (bRDs) from undocumented enterprise software. The system utilizes seven specialized agents to perform reverse engineering by analyzing source code, test suites, configuration files, and documentation. It employs static analysis for deterministic extraction and LLMs for synthesis, guided by expert cognitive models. The framework achieved a 98% cost reduction and generated bRDs in under nine minutes per service in a real enterprise deployment.
Entities (15)
Relation Signals (17)
Agentic Framework → developedby → Cognizant
confidence 99% · Affiliation: Cognizant, Plano, Texas, USA
Seven-Agent Cognitive Architecture → consistsof → Agent 2: Journey Mapping
confidence 95% · Agent 2: Journey Mapping enumerates every user and system journey...
Seven-Agent Cognitive Architecture → consistsof → Agent 3: Business Rules Extraction
confidence 95% · Agent 3: Business Rules Extraction surfaces every business rule...
Seven-Agent Cognitive Architecture → consistsof → Agent 4: Gap Analysis
confidence 95% · Agent 4: Gap Analysis compares legacy behavior against target architecture capabilities...
Seven-Agent Cognitive Architecture → consistsof → Agent 5: Synthesis
confidence 95% · Agent 5: Synthesis, Conflict Resolution, and bRD Lock is the quality gate...
Seven-Agent Cognitive Architecture → consistsof → Agent 6: Acceptance Criteria
confidence 95% · Agent 6: Acceptance Criteria translates every locked journey...
Seven-Agent Cognitive Architecture → consistsof → Agent 1: Discovery and Scoping
confidence 95% · Agent 1: Discovery and Scoping... Agent 2... Agent 3... Agent 4... Agent 5... Agent 6... Agent 7...
Seven-Agent Cognitive Architecture → consistsof →
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Business requirements for enterprise software systems are rarely captured in structured form; the logic resides instead in source code, configuration files, and institutional memory. When these systems must be migrated, extended, or audited, the absence of formal requirements artifacts forces teams into expensive, knowledge-losing manual reverse engineering. This paper presents an agentic framework that autonomously generates Business Requirements Documents (bRDs) through reverse engineering of undocumented enterprise software. Seven specialized agents collaborate to discover user journeys, extract business rules, and synthesize a locked bRD from code, test suites, configuration, and available documentation, supported by static analysis tools, guided by embedded expert practitioner cognitive models, and overseen by human reviewers at controlled escalation points. Measured on actual execution traces across a real enterprise deployment, the framework generates comprehensive bRDs in under nine minutes per service, with extracted rules independently corroborated against real production defect records. In a comparable prior migration to the same target architecture, delivery required over two years; on the present programme the framework achieves a cost reduction exceeding 98% against a baseline derived from actual repository metrics using IFPUG complexity models and industry benchmark labor rates.
Tags
Links
- Source: https://arxiv.org/abs/2609.22719v1
- Canonical: https://arxiv.org/abs/2609.22719v1
Trouble viewing inline? Open PDF directly →
Full Text
45,502 characters extracted from source content.
Expand or collapse full text
From Code to Requirements: Agentic Reverse Engineering of Business Rules at Enterprise Scale Garima Agrawal Prasun Das Priyanka L Minisha N Affiliation: Akshay Sarvade Hemath Manivanan Sravani Joshna Prasad Kalyansundaram Affiliation: Cognizant, Plano, Texas, USA Affiliation: garima.agrawal, prasun.das, priyanka.lnu2307c7, minisha.n, akshay.sarvade, Affiliation: hemathKumar.manivannan, malla.sravaniJoshna, prasad.kalyanasundaram@cognizant.com Abstract Business requirements for enterprise software systems are rarely captured in structured form; the logic resides instead in source code, configuration files, and institutional memory. When these systems must be migrated, extended, or audited, the absence of formal requirements artifacts forces teams into expensive, knowledge-losing manual reverse engineering. This paper presents an agentic framework that autonomously generates Business Requirements Documents (bRDs) through reverse engineering of undocumented enterprise software. Seven specialized agents collaborate to discover user journeys, extract business rules, and synthesize a locked bRD from code, test suites, configuration, and available documentation, supported by static analysis tools, guided by embedded expert practitioner cognitive models, and overseen by human reviewers at controlled escalation points. Measured on actual execution traces across a real enterprise deployment, the framework generates comprehensive bRDs in under nine minutes per service, with extracted rules independently corroborated against real production defect records. In a comparable prior migration to the same target architecture, delivery required over two years; on the present programme the framework achieves a cost reduction exceeding 98% against a baseline derived from actual repository metrics using IFPUG complexity models and industry benchmark labor rates. Keywords: Agentic AI, Requirements Reverse Engineering, Legacy systems, SDLC automation, Multi-Agent Systems 1 Introduction Enterprise software systems accumulate business logic over years of evolution, encoding rules and behaviors directly into source code, configuration files, and the institutional memory of personnel who may no longer be available. Modern microservice architectures face the same documentation gap through different mechanisms, including sprint velocity pressures, shifting team ownership, and the implicit assumption that working code is sufficient specification. In both cases, the Business Requirements Document (bRD), which formally captures user journeys, business rules, acceptance criteria, gap analyses, and risk dependencies, is absent precisely when it is most needed. The consequences are well understood in practice. Migration programs stall on undiscovered behavioral edge cases. Compliance audits require expensive manual archaeology. Producing a bRD manually demands a cross-functional team of business analysts, developers, quality engineers, and domain experts working in concert for weeks per component, decoding behavior from source code, test suites, configuration files, and tribal knowledge. Knowledge earned on one component does not transfer to the next. Every engagement restarts from near-zero. Recent advances in LLM-based agentic systems have addressed adjacent problems, including code generation Qian et al., 2024, automated testing Schäfer et al., 2024, and architectural recovery Canfora and Di Penta, 2007, but requirements reverse engineering from undocumented enterprise systems remains largely unaddressed. Where approaches exist, three critical limitations persist. First, existing tools rely on single data sources, typically source code alone, missing the distributed behavioral signal encoded across repositories, test suites, configuration files, and documentation simultaneously. Second, current agentic approaches exhibit heavy LLM dependence, invoking generative models for tasks better handled by deterministic static analysis such as AST parsing, pattern detection, and schema diffing, resulting in unnecessary token consumption and compounding hallucination risk. Third, no existing framework encodes domain expertise as a first-class architectural element. A senior business analyst questions differently than a retrieval agent; a quality engineer reads a test suite differently than a code parser. The cognitive models of experienced practitioners, including how they hunt edge cases, detect ambiguity, and surface regulatory risk, are absent from current designs Hong et al., 2024. A single-prompt approach cannot meet this challenge at enterprise scale. A component spans tens of thousands of lines across multiple repositories, together with tests, configuration, and documentation, exceeding any single context window; a model asked to hold all of it fills the gaps with plausible invention. The required reasoning also differs by expertise, from journey analysis to test-suite reading to regulatory scrutiny, and no single prompt performs all of these well. This paper presents a seven-agent cognitive framework that decomposes the work across specialized agents, each with a narrow brief, a deterministic tool belt, and a defined output contract. It addresses the three limitations directly: it integrates evidence from code, test suites, configuration, and documentation simultaneously; it employs static analysis as the primary extraction mechanism, reserving LLM reasoning for synthesis, conflict resolution, and plain-English translation; and it encodes expert practitioner cognitive models as agent-level capabilities that shape how each agent reasons, not merely what it retrieves. A knowledge layer enables reuse across successive runs. Critically, this is not a research prototype. The framework has been deployed on a large-scale enterprise environment spanning modern microservices and legacy systems, under human supervision: agents execute autonomously but escalate to human reviewers at defined decision points. The magnitude of the problem is concrete, as a comparable prior migration to the same target architecture for another product line required over two years of effort in practice. Against a baseline derived from actual repository metrics, manual bRD generation for a single service requires 117 person-hours on average, whereas the framework generates an equivalent bRD in a generation time of under nine minutes at an average LLM inference cost of $0.07 per service, both measured from actual execution traces. This generation time is distinct from human review and validation effort, which we report separately in Section 4. The contributions of this paper are as follows: 1. A seven-agent cognitive architecture for requirements reverse engineering that integrates multi-source evidence with embedded domain expertise. 2. A knowledge layer that supports reuse across successive runs and incremental regeneration as components change. 3. An effort and cost evaluation grounded in actual repository metrics and measured execution traces, using IFPUG-derived complexity models, comprehension-based effort modeling, and industry benchmark labor rates. 4. Artifact quality validation in which extracted rules are corroborated against independent production defect records, across both modern and legacy systems. The remainder of this paper is organized as follows. Section 2 reviews related work. Section 3 describes the framework architecture. Section 4 details the implementation and evaluation. Section 5 discusses the results and future work. Section 6 concludes. 2 Related Work The three limitations identified in Section 1 position this work within three research threads: requirements recovery, multi-agent LLM systems, and software effort estimation. Requirements Recovery and Reverse Engineering - Chikofsky and Cross Chikofsky and Cross, 1990 established the foundational taxonomy of reverse engineering, defining requirements recovery as its highest abstraction level. Canfora and Di Penta Canfora and Di Penta, 2007 note that most approaches recover structural artifacts such as call graphs and class diagrams rather than behavioral requirements, operate on single source types, and do not address the synthesis problem inherent in enterprise systems where behavioral signal is distributed across code, tests, configuration, and documentation. The recovery of user journeys, business rules, and acceptance criteria from undocumented systems remains largely unaddressed. Multi-Agent LLM Systems for Software Engineering - ChatDev Qian et al., 2024 frames development as a virtual organization of communicating agents; MetaGPT Hong et al., 2024 encodes standardized operating procedures into role-based workflows; and SWE-agent Yang et al., 2024 resolves software issues through iterative code analysis. AgentModernize Ahmed and Galib, 2026 addresses the downstream conversion of legacy code to modern components, reporting 91.2% business rule capture via a Behavioral Specification Graph; however, it operates on the modernization step and does not encode the questioning behavior of business, quality, and compliance specialists that our framework embeds as agent-level cognitive models. Related industrial work has demonstrated agentic pipelines for enterprise knowledge extraction Agrawal et al., 2026 and knowledge-graph augmentation to reduce hallucination risk Agrawal et al., 2024. All operate downstream of requirements, assuming specifications exist. Our framework addresses the upstream problem they presuppose: recovering behavioral specifications from systems where none were ever written. Effort Estimation in Software Engineering - COCOMO I Boehm et al., 2000 provides the foundational parametric effort model, and IFPUG Function Point Analysis IFPUG, 2009 a complexity measure grounded in functional components with industry-derived weights. ISBSG benchmark data ISBSG, 2017 supplies the Specify and Design phase ratios used in our manual baseline, while program comprehension studies Minelli et al., 2015; Xia et al., 2018 establish that 52–70% of maintenance effort is consumed by code reading, anchoring our comprehension rate of 100 LOC/hour. To our knowledge, no prior work has applied IFPUG-derived complexity weights specifically to reverse engineering effort estimation, an additional methodological contribution of this work. 3 Framework Design The gap established in Section 2, that existing approaches neither integrate behavioral signal across multiple source types nor encode domain expertise architecturally, motivates the design presented here. Rather than a monolithic prompt-driven system, we designed a cognitive pipeline of specialized agents that collaborate, share structured state, and defer to static analysis wherever deterministic extraction is possible, reserving LLM reasoning for the points where human-level synthesis is genuinely required. Figure 1 illustrates the end-to-end pipeline. 3.1 System Overview The pipeline accepts a software component as input, defined by its repository set together with whatever supporting artifacts exist: source code accessed through a Git Nexus connector, Jira issues, Confluence pages accessed through an MCP connector, API specifications, runtime call stacks, and application logs. These sources are read and parsed directly in full. The pipeline produces a locked bRD in two forms: a human-readable document for business and technical stakeholders, and a machine-readable json artifact for downstream SDLC agents in design, development, QA, and DevOps. A LangGraph orchestrator LangChain Inc., 2024a manages sequencing, parallel execution, confidence monitoring, and knowledge layer graduation. Agent 1 establishes scope; Agents 2 and 3 then run in parallel, both reading only the scope definition from Agent 1 and producing independent outputs: Agent 2 a journey inventory, Agent 3 a rules catalogue. Because they run concurrently, neither depends on the other’s output; the authoritative cross-linking of rules to journeys is performed later by Agent 5, which cross-examines all upstream outputs, resolves conflicts, and can dispatch corrections back to the responsible agent before locking. Agent 4 runs once both complete; Agent 5 is the quality gate that runs when all prior outputs are available; and Agents 6 and 7 run in parallel after the bRD is locked. A shared state store threads through the pipeline, carrying context forward and preserving a full audit trail. No prior bRD or knowledge base is assumed; this cold-start setting is the one this paper evaluates, and the knowledge layer (Section 3) describes how prior knowledge is reused when it does exist. 3.2 Agent DNA and Cognitive Model Every agent carries a shared base schema, termed Agent DNA, comprising six blocks: identity, skills, domain knowledge, cognitive model, house rules, and pipeline position. Three of these blocks encode direct responses to the three limitations of Section 1. Multi-source integration is encoded in the domain knowledge block: each agent knows where behavioral signal lives across production code, test suites, configuration, documentation, and issue trackers, and must consult a minimum of two independent sources before accepting any finding as valid. Static-first extraction is encoded in the tools block and house rules: each agent queries a registry of pre-built static analysis capabilities, performing AST parsing, pattern detection, schema diffing, and test suite mining deterministically. The LLM is invoked only for translation, conflict resolution, and narrative synthesis, operating on curated structured inputs rather than raw repository content, which minimizes token consumption and hallucination risk. Embedded domain expertise is encoded in the cognitive model block: each agent carries the thinking modes of a senior business analyst, including systems thinking, skeptical reading that treats documentation as hypothesis, edge case hunting, and ambiguity detection. These are operationalized through non-negotiable house rules: scope is never silently expanded, conflicts never silently resolved, confidence never inflated, and every assumption named, tracked, and owned. Figure 1: Seven-agent bRD generation pipeline. Agents 2+3 and Agents 6+7 execute in parallel. All agents read from and write to the shared state store. The knowledge layer compounds organizational knowledge across successive pipeline runs. 3.3 The Seven Agents Agent 1: Discovery and Scoping. The component under analysis is defined by a human expert, not by the pipeline: an engineer maps a named service to its candidate repositories and configures the run with the supporting sources listed above. Taking this human-provided scope as its starting point, Agent 1 scans repository file trees, catalogs source, configuration, test, and documentation artifacts, scores each for freshness and authority, maps upstream and downstream dependencies, and produces the scope definition all subsequent agents build on. It confirms which repositories, endpoints, and dependencies genuinely belong to the component and flags any that appear out of scope. Ambiguous boundaries trigger a human decision request before the pipeline proceeds. Agent 2: Journey Mapping enumerates every user and system journey through the component. It operates across four source types simultaneously: API endpoints and UI routes located by static scanning; code logic traced by AST parsing; documentation parsed by the document adapter; and test suites mined for encoded behavioral specifications. Test suite mining is architecturally significant: regression tests encode the journeys that development teams actually validated, including edge cases and error paths never formally documented. Actors and roles are extracted from authentication and authorization checks, endpoint access controls, and role references in tests and configuration, rather than assumed. Agent 2 produces a typed journey inventory covering happy paths, alternate paths, error paths, and edge cases per actor and channel, together with a test-to-journey coverage matrix. Agent 3: Business Rules Extraction surfaces every business rule embedded in source code, configuration files, and documentation. It applies pattern-based static analysis, using AST queries and Semgrep-style rule patterns over the parsed syntax tree, to identify conditional logic, validation guards, eligibility checks, and threshold constants, each returned with its file location and surrounding context before the LLM translates it into a plain-English rule with actor, condition, and outcome explicitly stated. Agent 3 produces a preliminary rule-to-journey linking, flags rules it cannot yet map, and raises regulatory signals for PII, financial, and compliance-relevant logic; the authoritative rule-to-journey linking is reconciled by Agent 5 once both inventories are available. Business rule with provenance (masked) "rule_id": "R-014", "statement": "Requests from an unsupported region are rejected before pricing runs", "source": ["EligibilityService.java:118", "regions.yaml"], "corroborated_by": ["RegionValidatorTest"], "confidence": "HIGH", "regulatory_flag": false, "journeys": ["J-02","J-05"], "assumptions": [] Agent 4: Gap Analysis compares legacy behavior against target architecture capabilities for every journey and business rule from Agents 2 and 3. It requires a target-state specification as input; where a target schema is available, a schema diff compares the legacy data model, entity fields and types extracted from code and configuration, against the target to identify added, removed, renamed, or retyped fields, and where none exists Agent 4 reports only the discovered baseline and flags the absence. Gaps are classified as clean map (legacy behavior maps directly), transform needed (an adaptation layer is required), missing (absent from the target), or deferred (resolution planned for a later cycle). Each gap is risk-scored by business impact and customer-facing exposure, and blocking gaps that prevent bRD lock are escalated to the human loop. Agent 5: Synthesis, Conflict Resolution, and bRD Lock is the quality gate of the pipeline. It cross-examines the outputs of Agents 1 through 4 simultaneously, detecting conflicts within and across agent outputs, coverage holes, confidence chain violations, and assumption dependency chains. Resolution proceeds in three phases: autonomous resolution using knowledge layer precedents and evidence weighing; pattern-based resolution for known conflict types, applying fixed precedence rules such as test evidence overriding documentation (Section 3, Artifact Composition); and human loop escalation only when a conflict requires a business judgment that cannot be resolved analytically. Human escalation surfaces a structured decision package comprising the exact conflict statement, evidence on both sides, a recommendation, and a single answerable question. Every human decision is logged permanently with full rationale. Agent 5 then assembles all validated artifacts into a coherent locked bRD in both human-readable and machine-readable form. A conflict resolved by precedence (masked)CONFLICT C-07 Journey J-04: an unlocked item is always eligible. Rule R-018 + test SuiteB#rejectsForeignLock: rejected when locked to another provider. RESOLUTION Test evidence prevails; J-04 amended, R-018 retained, exception branch added. logged: rationale, sources, confidence 0.91 Agent 6: Acceptance Criteria translates every locked journey and business rule into verifiable Given/When/Then acceptance criteria formatted as Gherkin scenarios Cucumber, 2024 for direct adoption in Behavior-Driven Development (BDD) test frameworks. It compares new criteria against the existing regression suite to identify coverage gaps and generates structured new test case suggestions. Agent 7: Risk and Dependency maps all system, data, and team dependencies, scans for regulatory and compliance obligations, scores each risk by likelihood and business impact, and produces a structured risk register fed into the locked bRD. Table 1 summarizes the input sources, static tools, LLM role, and output artifact for each agent. Table 1: Agent pipeline: input sources, static tools, LLM role, and output artifact. Agent Input Sources Static Tools LLM Role Output A1 Discovery Repos, docs, tickets File scanner, dependency mapper Scope synthesis Scope doc, artifact catalog A2 Journey Code, test suites, API specs, docs AST parser, test suite miner Journey typing, conflict resolution Journey inventory, coverage matrix A3 Rules Source code, config files, docs Pattern matcher, AST parser Rule translation Rules catalog, regulatory flags A4 Gap Journey inventory, rules, target specs Schema diff, API parser Gap classification Gap register, risk scores A5 Synthesis All agent outputs, knowledge layer Vector store Conflict resolution, bRD assembly Locked bRD (human + machine) A6 AC Locked bRD, test suite Regression comparator AC authoring AC document, Gherkin feature file A7 Risk Scope, journeys, rules, gaps Dependency scanner Risk narrative Risk register, dependency map 3.4 State Store and Human Loop Each run maintains a two-layer state store. Layer 1 is a rolling context summary, the briefing every agent reads on activation, carrying current scope, summaries, open items, confidence flags, and handoff notes from the preceding agent. Layer 2 is an append-only immutable event log recording every finding, decision, tool call, and conflict with full provenance: agent, timestamp, source references, confidence, and graduation flags. The summary is working memory; the log is the audit trail. The human loop is a controlled escalation mechanism, not a default. Agent 5 escalates only when a conflict cannot be resolved from available evidence, an assumption chain exceeds its risk threshold, or confidence on a critical-path journey falls below the minimum, surfacing a structured decision package and pausing the pipeline pending response. 3.5 The Knowledge Layer The knowledge layer separates this framework from single-run approaches. It maintains a knowledge graph whose nodes represent the core artifacts of requirements engineering, components, journeys, business rules, actors, data entities, gaps, and decisions, each carrying full provenance. Relationships are classified as structural, discovered, inferred, or emergent, with emergent patterns crystallizing when the same finding recurs across three or more components. The layer can serve prior knowledge when it exists, enforces domain and regulatory boundaries on reads and writes, detects conflicts, and quality-gates findings before they become permanent. Access follows the two operating modes. Within a single cold-start run, agents persist their structured artifacts to the store and later agents read the specific named artifacts they require directly, by identity rather than by similarity search. This keyed access avoids threading all accumulated state through the orchestrator, which would otherwise exceed context limits and lose information. Across runs, when a prior knowledge base or partial bRD exists, a vector index enables retrieval of previously established rules, journeys, and decisions so that incremental changes to a component reuse existing knowledge rather than rediscovering it. This cross-run reuse and the resulting reduction in token cost are architected properties of the knowledge layer; they are not among the cold-start results reported in Section 4. 3.6 Artifact Composition and Traceability The agents do not produce independent outputs stitched together at the end; each acceptance criterion is generated from the intersection of three upstream artifacts, with each mapping to one clause of a Given/When/Then specification: AC=Rule⏟Given+Journey step⏟When+Test / Gap closure⏟ThenAC= Rule_Given\;+\; Journey step_When\;+\; Test / Gap closure_Then A behavior is treated as expected only where all three intersect, making every criterion bidirectionally traceable to a governing business rule (Agent 3), a journey step (Agent 2), and executable test evidence. Where sources conflict, resolution follows a fixed precedence: Test evidence≻Business rule≻JourneyTest evidence\; \;Business rule\; \;Journey Test evidence is treated as ground truth, business rules override aspirational journeys, and conflicting journeys are realigned to the production baseline. This precedence is what allows Agent 5 to lock the bRD deterministically rather than through free-form synthesis, ensuring generated criteria remain verifiable rather than aspirational. 4 Implementation and Evaluation 4.1 System Configuration The framework described in Section 3 was deployed on a real enterprise Java codebase and evaluated across two use cases: modern undocumented microservices and a legacy migration pilot. The pipeline is orchestrated using LangGraph LangChain Inc., 2024a with LangSmith LangChain Inc., 2024b providing agent observability, token tracing, and execution monitoring across all runs. Repository access is provided through the Model Context Protocol (MCP) GitHub Nexus connector Anthropic, 2024b, surfacing enterprise Git repositories to the agent pipeline without custom integration. The LLM layer is configurable at runtime between GitHub Copilot Enterprise GitHub Inc., 2024 and Claude API Anthropic, 2024a via a YAML configuration file, making the framework model-agnostic and adaptable to organizational licensing constraints. 4.2 Evaluation Setup We report an industrial case study of a single enterprise deployment. Due to confidentiality constraints, all service and repository identifiers are anonymized; no client or system names are disclosed. The programme comprises 18 modern services spanning 39 repositories. Token and coverage measurements were captured from LangSmith execution traces for 14 of these services; the remaining four are included at the programme level for effort and cost comparison but were not instrumented for per-run token capture. Coverage figures therefore report the 14 measured services, while the programme-level comparison in Table 5 spans the full 18-service, 39-repository scope. One legacy pilot feature establishes cross-repository feasibility; the legacy results are reported as feasibility evidence, not as a general claim. We evaluate against three research questions: RQ1: Can a multi-agent LLM framework systematically recover structured business requirements from undocumented enterprise software systems, both legacy and modern, with sufficient coverage and fidelity for downstream SDLC use? RQ2: Does agentic requirements recovery achieve meaningful reduction in effort and cost compared to manual reverse engineering, without sacrificing artifact accuracy? RQ3: How faithfully do agentically generated bRDs capture system behavior, as assessed against existing test coverage and independent defect records? (a) RQ1: Coverage and Artifact Scale. Table 2 reports the coverage footprint across 14 measured services from LangSmith traces. The pipeline discovered 280 business journeys, extracted 1,612 business rules, and mapped 327 test cases to generated artifacts, drawing evidence simultaneously from source code, test suites, configuration files, and documentation. This multi-source integration directly addresses the first limitation identified in Section 1: no single source type would have recovered this behavioral signal alone. Journey discovery ranged from 3 to 42 per service and rules from 10 to 187, reflecting genuine complexity variation across the portfolio. Average generation time, the automated compute time per service exclusive of human review and validation, was 8.78 minutes. The machine-readable bRD produced for each service is directly consumable by downstream design, development, QA, and DevOps agents without translation overhead, addressing the SDLC-ready design principle stated in Section 3. Table 2: Coverage footprint across 14 measured services. Metric Total Avg/Service Business journeys 280 20.0 Business rules 1,612 115.1 Test cases mapped 327 23.4 Journey range 3–42 — Rules range 10–187 — Tests range 3–42 — Avg generation time (min) 122.85 8.78 RQ1 is answered affirmatively. The framework recovers structured behavioral artifacts at enterprise scale, integrating evidence across multiple source types simultaneously, at an average generation time of 8.78 minutes per service. (b) RQ2: Effort and Cost Reduction. We compare agentic measured effort against a manual baseline modeled from actual repository metrics for the 19-repository sample and projected to the full programme. The baseline is a model, not a stopwatch measurement of manual work on these services; it is derived using the equations below from real class, method, and LOC counts. Table 3 characterizes the repository sample; Table 5 presents the programme-level comparison. The complexity index (CI) weights are derived from IFPUG average component weights IFPUG, 2009: class count maps to Internal Logical Files and External Interface Files (combined average weight 17, normalized to 0.45); method count maps to External Inputs, Outputs, and Inquiries (combined average weight 13, normalized to 0.26); production LOC modulates complexity within components (0.17); and test LOC maps to the Value Adjustment Factor (0.11). The comprehension rate of 100 LOC/hour is grounded in empirical studies establishing that program comprehension accounts for 52–70% of software maintenance effort Minelli et al., 2015; Xia et al., 2018. The team multiplier of 1.8 reflects the four-role composition required for manual reverse engineering: developer (100% code coverage), business analyst (40% business-critical paths), QA engineer (test code), and domain expert (validation). The 152-hour person-month and analysis and synthesis add-on rates follow COCOMO I Boehm et al., 2000 and ISBSG phase effort benchmarks ISBSG, 2017 respectively. Labor cost uses a blended rate of $58/hr derived from BLS 2024 occupational wage data U.S. Bureau of Labor Statistics, 2024 and Salary.com surveys Salary.com, 2025. For the agentic cost model, three components are reported separately. LLM inference cost is computed from actual LangSmith token counts at Claude Haiku benchmark pricing, a generalizable reference independent of organizational licensing. The one-time setup phase (framework configuration, MCP connector setup, and team training) is non-recurring and amortizes across all future runs. Human review is one hour per service. Tooling license costs are excluded as they vary by contract. The two sides are therefore not accounted symmetrically: the manual baseline is a full loaded-labor model, whereas the agentic figure isolates the recurring marginal cost. We report the comparison on this basis and treat the resulting reduction as indicative of order of magnitude rather than as a controlled measurement. Manual Effort Derivation Model ①IFPUG Complexity Index IFPUG, 2009 CI=0.45ncls+0.26nmth+0.17nloc+0.11ntstCI=0.45\,n_cls+0.26\,n_mth+0.17\,n_loc+0.11\,n_tst n(⋅)n_(·): min-max normalized values within dataset. Classes → ILF+EIF (0.45); Methods → EI+EO+EIQ (0.26); Prod. LOC → complexity modulator (0.17); Test LOC → Value Adjustment Factor (0.11). ②Base Hours Minelli et al., 2015; Xia et al., 2018 BaseHrs=TotalLOC100×1.8BaseHrs= TotalLOC100× 1.8 100 LOC/hr: purposeful RE of enterprise Java (comprehension: 52–70% of maintenance effort Minelli et al., 2015). 1.8×: four-role team multiplier (Dev + BA + QA + Domain Expert). ③ISBSG Phase Add-ons ISBSG, 2017 AnalysisAdd=max(12, 0.18×BaseHrs)AnalysisAdd= (12,\ 0.18× BaseHrs) SynthAdd=max(8, 0.13×BaseHrs)SynthAdd= (8,\ 0.13× BaseHrs) 0.18: ISBSG Specify phase ratio (RE mean 18% ISBSG, 2017). 0.13: ISBSG Design phase ratio for reengineering. Floors: 12 hrs (analysis), 8 hrs (synthesis). ④Total Hours, Person-Months, Cost Boehm et al., 2000; U.S. Bureau of Labor Statistics, 2024 Hrs Hrs =BaseHrs+AnalysisAdd+SynthAdd =BaseHrs+AnalysisAdd+SynthAdd PM PM =Hrs÷152 =Hrs 152 Cost Cost =Hrs×$58 =Hrs×\$58 152 hrs/PM: COCOMO I standard Boehm et al., 2000. $58/hr: blended rate (BLS 2024 U.S. Bureau of Labor Statistics, 2024; Salary.com 2025 Salary.com, 2025). Agentic Cost Model ①LLM Inference Cost CLLM=Tin106×$0.80+Tout106×$2.40C_LLM= T_in10^6×\$0.80+ T_out10^6×\$2.40 TinT_in, ToutT_out: input/output tokens from LangSmith traces; divided by 10610^6 per standard API pricing convention. Pricing: Claude Haiku benchmark. ②One-Time Setup (non-recurring) Three-week framework configuration, MCP connector setup, and team training. Incurred once; amortizes across all future runs. Not included in recurring cost per service. ③Human Review Creview=18hrs×$58=$1,044C_review=18\,hrs×\$58=\$1,044 One hour per service for output review and validation. Recurring LLM cost per service: Cmarginal=CLLM≈$0.07C_marginal=C_LLM≈\$0.07 Based on average 47,694 tokens per service at Haiku benchmark pricing. Human review and setup costs excluded; see Table 5. Table 3: Repository sample characteristics (19 of 39 repositories; identifiers anonymized). Metric Min Max Production LOC 556 107,810 Test LOC 0 82,378 Class count 22 1,791 Method count 47 15,228 IFPUG CI 0.001 0.957 Manual hours (repo) 48 3,896 Table 4: Agentic token measurements across 14 services (LangSmith traces). Metric Min Max Avg/Svc Input tokens 5,500 45,230 29,482 Output tokens 3,300 28,150 18,211 Total tokens 8,800 73,380 47,694 Cost – Haiku ($) 0.014 0.104 0.066 Generation (min) 3.00 12.45 8.78 Table 5: Programme-level comparison: manual derived vs. agentic measured (39-repository programme scope). Metric Manual (derived) Agentic (measured) Scope 39 repositories 18 services, 39 repos automated Total human hours 34,981 hrs ∼ 18 hrs review Person-months 230 PM <<1 PM recurring One-time setup N/A ∼ 3 months (non-recurring) Team of 5 duration ∼ 40 months <<1 week LLM inference cost N/A $1.18 (Haiku benchmark) Total cost $2,028,869 One-time setup ++ $1.18 LLM Cost reduction >>98% Time reduction 99.4% The cost reduction exceeds 98% even when the one-time setup investment is included, since setup is non-recurring and amortizes across all future runs. The recurring LLM inference cost per service is approximately $0.07, so the marginal cost of each additional service is negligible relative to the modeled manual baseline. RQ2 is answered affirmatively. On this modeled comparison, agentic requirements recovery reduces cost by more than 98% and generation time by 99.4% relative to the manual baseline, while producing the coverage-rich artifacts demonstrated under RQ1. (c) RQ3: Artifact Quality Validation. RQ3 asks how faithfully generated bRDs capture system behavior. Two checks are applied, and we are explicit about what each does and does not establish. Test coverage mapping establishes traceability between generated journeys and existing tests; defect corroboration provides independent check that extracted rules are faithful. Test coverage mapping (traceability). For each measured service, generated journeys were matched to existing regression test cases automatically, through shared source references rather than manual inspection. A journey is traceable when at least one regression test maps to it. Across 14 services, 327 test cases were mapped to generated journeys. Because Agent 2 also uses test suites as a discovery source (Section 3), this mapping demonstrates traceability and internal consistency rather than independent validation; the independent check is provided next. Defect corroboration (independent). To test faithfulness against a source the pipeline never saw, we used production defect records. When a service is tested, defects are logged and triaged, and developers routinely record in the triage notes the business rule that was violated. These triage descriptions are written by engineers for a different purpose and were not part of the pipeline’s input, so they serve as an independent, human-authored statement of the system’s real rules. For each sampled service we drew a set of logged defects and, using an LLM-as-judge, compared the rule cited in each defect’s triage against the rules the pipeline had extracted. A defect corroborates when the bRD contains a rule matching the one the developer independently referenced. This checks the property that matters for artifact quality: that the agents recovered rules genuinely present in the system rather than generating fluent but ungrounded text. Across five sampled services, over 100 defects were examined; because a single triage may cite more than one rule, matches are counted at the rule level, and 115 distinct bRD rules were each corroborated by at least one defect triage that named the same rule. Where the judge could not match a defect, typically due to identifier formatting differences or the defect not concerning a business rule, the case was escalated to human review and non-rule defects were set aside as out of scope. Per-service defect counts and identifiers are withheld for confidentiality. RQ3 is answered affirmatively. Extracted rules match the rules developers independently cited when triaging real production defects, evidence that the pipeline recovers faithful system behavior rather than plausible but ungrounded text, while test mapping confirms generated journeys trace to verified tests. 5 Discussion The framework shows that automated requirements reverse engineering at enterprise scale is achievable without sacrificing artifact quality, making bRD generation a continuous activity throughout the migration lifecycle rather than a deferred one. The significance is concrete: a comparable prior migration to the same target architecture for another product line required over two years of effort in practice, whereas the framework produces the foundational artifacts for an equivalent programme in days. On the modern side, generated bRDs give feature development and agile delivery the behavioral baseline they rarely have, and the defect corroboration shows extracted rules match those developers independently relied on, so the artifacts are faithful, not merely comprehensive. Several limitations bound these results. The manual baseline is modeled from actual repository metrics rather than observed directly, and the two cost sides are not accounted symmetrically, so the reported reduction is an order-of-magnitude indication, not a controlled measurement. The study covers one enterprise Java codebase and a single legacy pilot; generalization to other languages and domains remains future work. Because extraction is static-first, behavior resolved only at runtime (dependency injection, reflection, dynamic proxies) and rules outside application code (stored procedures, triggers, message routing) are under-represented or out of scope, and coverage metrics do not verify completeness. Where source is sensitive, the model-agnostic design permits locally hosted models. The deployment is deliberately human-supervised at this maturity stage. Where a component lacks a usable test suite, the pipeline still runs, capping affected findings at lower confidence and reporting the gap as a risk. The planned next step is autonomous scheduled execution in which bRDs regenerate as code changes, using the knowledge layer’s incremental mode to reprocess only the delta, countering drift between a living codebase and its documentation. The same principles extend to downstream agents for code generation, review, and testing, completing the agentic SDLC pipeline this work initiates. 6 Conclusion Enterprise software systems carry decades of behavioral knowledge that exists nowhere in formal documentation. This paper presented an agentic framework that recovers it systematically through multi-source integration, static-first extraction, and embedded expert practitioner cognitive models. Deployed on a real enterprise environment spanning modern microservices and a legacy migration pilot, the framework shows that requirements reverse engineering is tractable at scale and at negligible recurring cost, with extracted rules corroborated against independent production defect records. The result is not merely a faster path to bRD generation but a foundation for a fully agentic SDLC pipeline, in which design, development, testing, and deployment agents build on a shared, machine-readable specification the knowledge layer maintains as the codebase evolves. References Agrawal et al. (2026) G. Agrawal, S. Gummuluri, and C. Spera Beyond RAG: A LLM-based FAQ matching framework for real-time decision support in contact centers. In Proceedings of the 59th Hawaii International Conference on System Sciences (HICSS-59), p. 1786–1793. Cited by: §2. Agrawal et al. (2024) G. Agrawal, T. Kumarage, Z. Alghamdi, and H. Liu Can knowledge graphs reduce hallucinations in LLMs? A survey. In Proceedings of the 2024 Conference of the North American Chapter of the Association for Computational Linguistics (NAACL): Human Language Technologies, p. 3947–3960. External Links: Document Cited by: §2. Ahmed and Galib (2026) S. N. Ahmed and M. Galib AgentModernize: preserving business logic in legacy modernization with multi-agent llms and behavioral specification graphs. arXiv preprint arXiv:2605.17535. Cited by: §2. Anthropic (2024a) Anthropic Claude API. External Links: Link Cited by: §4.1. Anthropic (2024b) Anthropic Model context protocol: an open standard for connecting AI assistants to data sources. External Links: Link Cited by: §4.1. Boehm et al. (2000) B. Boehm, C. Abts, A. W. Brown, S. Chulani, B. K. Clark, E. Horowitz, R. Madachy, D. Reifer, and B. Steece Software cost estimation with COCOMO I. Prentice Hall. Cited by: §2, §4.2, §4.2, §4.2. Canfora and Di Penta (2007) G. Canfora and M. Di Penta New frontiers of reverse engineering. In Future of Software Engineering (FOSE 2007), p. 326–341. External Links: Document Cited by: §1, §2. Chikofsky and Cross (1990) E. J. Chikofsky and J. H. Cross Reverse engineering and design recovery: A taxonomy. IEEE Software 7 (1), p. 13–17. External Links: Document Cited by: §2. Cucumber (2024) Cucumber Gherkin reference: BDD specification language. External Links: Link Cited by: §3.3. GitHub Inc. (2024) GitHub Inc. GitHub Copilot Enterprise. External Links: Link Cited by: §4.1. Hong et al. (2024) S. Hong, M. Zhuge, J. Chen, X. Zheng, Y. Cheng, C. Zhang, J. Wang, Z. Wang, S. K. S. Yau, Z. Lin, L. Zhou, C. Ran, L. Xiao, C. Wu, and J. Schmidhuber MetaGPT: meta programming for a multi-agent collaborative framework. In Proceedings of the 12th International Conference on Learning Representations (ICLR 2024), External Links: Link Cited by: §1, §2. IFPUG (2009) IFPUG Counting practices manual (CPM). Technical report International Function Point Users Group. Note: ISO/IEC 20926:2009 Cited by: §2, §4.2, §4.2. ISBSG (2017) ISBSG Planning projects—phase effort ratios. Technical report International Software Benchmarking Standards Group. External Links: Link Cited by: §2, §4.2, §4.2, §4.2. LangChain Inc. (2024a) LangChain Inc. LangGraph: build resilient language agents as graphs. External Links: Link Cited by: §3.1, §4.1. LangChain Inc. (2024b) LangChain Inc. LangSmith: observability and testing for LLM applications. External Links: Link Cited by: §4.1. Minelli et al. (2015) R. Minelli, A. Mocci, and M. Lanza I know what you did last summer: an investigation of how developers spend their time. In Proceedings of the 23rd IEEE International Conference on Program Comprehension (ICPC 2015), p. 25–35. External Links: Document Cited by: §2, §4.2, §4.2, §4.2. Qian et al. (2024) C. Qian, W. Liu, H. Liu, N. Chen, Y. Dang, J. Li, C. Yang, W. Chen, Y. Su, X. Cong, J. Xu, D. Li, Z. Liu, and M. Sun ChatDev: communicative agents for software development. In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (ACL 2024), p. 15174–15186. Cited by: §1, §2. Salary.com (2025) Salary.com Business analyst salary. External Links: Link Cited by: §4.2, §4.2. Schäfer et al. (2024) M. Schäfer, S. Nadi, A. Eghbali, and F. Tip An empirical evaluation of using large language models for automated unit test generation. IEEE Transactions on Software Engineering 50 (1), p. 85–105. External Links: Document Cited by: §1. U.S. Bureau of Labor Statistics (2024) U.S. Bureau of Labor Statistics Occupational employment and wage statistics: software developers (SOC 15-1252). External Links: Link Cited by: §4.2, §4.2, §4.2. Xia et al. (2018) X. Xia, L. Bao, D. Lo, Z. Xing, A. E. Hassan, and S. Li Measuring program comprehension: A large-scale field study with professionals. IEEE Transactions on Software Engineering 44 (10), p. 951–976. External Links: Document Cited by: §2, §4.2, §4.2. Yang et al. (2024) J. Yang, C. E. Jimenez, A. Wettig, K. Lieret, S. Yao, K. Narasimhan, and O. Press SWE-agent: agent-computer interfaces enable automated software engineering. In Advances in Neural Information Processing Systems 37 (NeurIPS 2024), External Links: Link Cited by: §2.