This article argues that the classical SDLC succeeded because it fit the economics and technical constraints of its time:  scarce computing resources, expensive errors, slow release cycles, heavy contractual governance, and relatively stable problem domains.  It then argues that the same model is increasingly misaligned with contemporary digital capability delivery, where requirements shift continuously, architectures evolve in production, feedback is immediate, and AI-assisted tools can participate across the full engineering workflow.  The central claim is not that lifecycle thinking has disappeared, but that the single-pass, handoff-heavy, documentation-first interpretation of SDLC has been overtaken by faster, more iterative, more executable forms of delivery. In that newer model (not Agile by the way), the primary asset is no longer a stack of static phase documents; it is a governed expression of intent.  Being objectives, constraints, capabilities, outcomes, and tests, all fed directly into automated and AI-enabled development systems under expert human oversight.

Before we move forward, let's understand more fully, where we started.

What the SDLC is and where it came from: 
According to NIST, the SDLC is "a formal or informal methodology for designing, creating, and maintaining software," while the broader system development lifecycle encompasses initiation, development or acquisition, implementation, operation, maintenance, and disposal.  In other words, SDLC is fundamentally a lifecycle framing device:  it partitions work into recognizable stages so that organizations can plan, review, govern, and control the creation of software-intensive systems.

Historically, staged lifecycle thinking emerged soon after business and defense computing became organizationally important. A recent historical review of information-systems development methodologies places the emergence of formal ISD methodologies in the 1950s and the "early methodology era" in the 1960-1980 period, when structured approaches became central to professional discourse.  The earliest widely cited explicit staged software process was Benington's description of the SAGE air-defense program, adapted from a 1956 symposium presentation. By 1970, Royce's paper supplied the now-canonical sequence of requirements, analysis, design, coding, testing, and operations.

It is therefore misleading to say that one person "invented" the SDLC. A more accurate account is that lifecycle thinking coalesced from systems analysis, defence and aerospace programming, and emerging software-engineering practice. Benington documented one of the earliest large-scale implementations of staged development for a complex real-time system.  Royce articulated a highly influenntial model of staged development and the dangers of applying it naively.  Later standards and bodies of knowledge normalised lifecycle language across the discipline.

Why the classical model worked in its original context:
The classical SDLC worked becuase it addressed a genuine problem of scale.  In Benington's retrospective account fo SAGE, the software was too large for one person to understand, required the training and coordination of my programmers, and demanded new tools, interfaces, records, documentation, and independent testing practices. He explicitly attributed SAGE's relative success to an engineering mindset: rationalising the job, defining documentation so others could understand what was being done, policing interfaces carefully, testing independently in successive phases, building development and test tools, and assigning a chief engineer to orchestrate their interplay.

In that environment, staged work products had real economic value.  IEEE software-engineering leaders such as David L. Parnas and Paul C. Clements later explained why organizations wanted an idealised "rational" process even if real projects never behaved perfectly rationally.  They argued that a standard process provides guidance, makes progress measurable, supports design reviews, eases knowledge transfer between projects, and helps outsiders review a project.  They also stated concrete reasons for a requirements document:  it supports uer review, reduces duplication and inconsistency, helps estimation, protects against knowledge loss through staff turnover, provides a basis for test planning, and constrains future changes.  Those arguments explain why documentation-heavy SDLC methods were not irrational bureaucracy at birth; they were a serious resopnse to coordination and accountability problems.

The model also fit procurement and release conditions that were much slower than today's.  Large defence, industrial, and enterprise systems were commonly delivered in large batches, with expensive deployment events and limited visibility into real user behavior until late in the process.  In that context, investing heavily in up-front specification and review coud appear prudent.  Benington's account even notes that, after the initial slip on the SAGE prototype, a disciplined approach enabled many later modifications to be delivered with only minor scheduled slips.  The historical case for the SDLC was therefore not fictional; it was rooted in the real needs of early large-scale softare programs.

Why the classical SDLC no longer fits contemporary delivery: 
The core weakness of the classical SDLC is that it assumes problem understanding can be stablised before solution learning.  That assumption has been under sustained critique for decases.  Parnas and Clements argued in 1986 that no software project proceeds in a perfrectly rational way becuase users rarely know exactly what they want, many crucial facts are discovered only during implementation, human beings cannot comprehend all relevant complexity up front, and external change frequently invalidates earlier decisions.  Their conclusion was blunt: the picture of a designer deriving a design from fixed requirements in a rational, error-free way is "quite unrealistic".

A related critique came even earlier.  The abstract of the 1982 paper by William Swartout and Robert Balzer states that, contrary to cliams that specifications should be completed before implementation begins, specification and implementation are inevitably intertwined.  That argument goes to the heart of why classical phase separation breaks down in practice: building the solution is often how the team discovers what the real problem is.

The historical trajectory of practice confirms the point.  In their brief history of iterative and incremental development, Craig Larman and Victor Basili show that by the 1980s and 1990s large programs and standards bodies were already moving away from strict single-pass waterfall thinking.  They report that a 1987 Defence Science Board report argued that complex systems are "simplest, safest, and even fastest" to build by putting a minimal version into actual use and then adding functions according to priorities emerging from use, and they note that 1990s methods tended toward less early specification work and stronger evolutionary analysis.

Modern empirical research reaches similar conclusions from a different angle. DORAs research program, run by Google Cloude, repeatedly finds that high performance is associated with continuous integration, automated testing, flexible infrastructure, fast code reviews, and user- centricity, while heavyweight external change approvals harm performance.  DORA's guidance on test automation explicitly identifies the drawbacks of separate, late testing phases: manual regression testing becomes a bottleneck, manual inspection is unreliable for complex systems, developers wait too long for feedback, defects become more expensive to triage and repair, and quality becomes someone else's problem. Its 2019 findings likewise recommend moving away from heavyweight external approvals toward peer review and automation earlier in the delivery lifecycle.

The result is not merely slower delivery. It is structurally higher risk.  Long handoffs separate problem knoweldge from implemenation knowledge. Static requirements documents drift away from evolving code and production reality.  Late integration turns uncertainty into expensive rework. Large batches raise the blast radius of change. These costs are exactly what the classical SDLC was intended to reduce, but under contemporary conditions they are increasingly generated by the method itself.

Why the single-pass SDLC is now effectively obsolete
Calling the classical SDLC "obsolete" requires some precision.  Lifecycle thinking is not obsolete.  Planning, requirements analysis, architecture, testing, operation, and retirement still matter.  What has become obsolete is the assumption that these concerns are best handled through long sequential phases, static handoff documents, and delayed validation.  that model had already become unstable long before the present AI wave.  The MIT lecture notes on software development processes summarize Royce's own position:  after presenting the ideal waterfall, he proposed fixes such as more design work up front, extensive design documentation, building the system twice in critical respects, planning and monitoring testing, and involving the customer earlier. In other words, even the paper most often associated with waterfall immediately modified the simple linear model because pure sequentially was inadequate.

Benington's retrospective is even more revealing.  He warned that insisting on precise top-down specifications before serioud coding was "terribly misleading and dangerours," explained that SAGE team began only after building a substantial experimental prototype, and estimated that a more evolutionary approach would have reduced their total development costs by roughly 50 percent. That is striking: one of the earliest architects of staged software engineering later argued that learning by evolutionary development would have been materially cheaper than a larger leap from up-front specification to full implemenation.

By the time the Agile Manifesto was published in 2001, the counter-position had been stated explicitly:  working software over comprehensive documentation and responding tochange over following a plan. Its principles make the point even more directly, calling for early and continuous delivery of valuable software, welcoming changing requirements even late in develoment, and deliverying working software frequently. Whatever one thinks of "Agile" as a branded movement, the manifesto captured a practical truth:  in digital environments, plans must remain revisable because the world, the market, the architecture, and the user all move faster than static documentation can.

DORA's 2025 research adds the AI-era extension of this argument.  Its central finding is that AI acts as an amplifier: it magnifies an organisations's strengths and weaknesses.  Teams with strong automated testing, mature version-control practices, fast feedback loops, user focus, and quality internal platforms gain throughput and product-performance benefits; teams with weak foundations see instability and little benefit.  This is the opposite of the classical SDLC promise that more stage gates and process layers inherently reduce risk. In an AI-enabled delivery environment, slow feedback and weak foundations are not neutral, they are liabilities that AI can accelerate into production faster.

Toward an intent-centric, executable, AI-enabled model: 
The emerging alternative is not "no process" and it is not "no documentation." It is a different kind of process with a different kind of documentation. The evidence points toward a model in which the central artefact is a governed expression of intent: user neds, busienss objectives, constrains, acceptance conditions, architecture boundaries, and verification criteria.  This is leaner than traditional phase documentation in one sense,it avoids large narrative handoff documents whose main function is to survive organisational fragmentation, but richer richer in another sense, because it is structure, living, traceable, and close enough (proximity) to implementation to drive design, code, testing and review.

This shift has dep roots.  In 1992, Norbert E. Fuchs argued that executable specifications allow early validation at an abstract level, reduce the time lag between specification and validation, clarify incomplete requirements through hands-on experience, and can even become the primary development document in a transformational approach. In modern terms, that is the conceptual bridge from static requirements to executable intent.

Contemporary practice is no pushing that bridge much further.  DORA's user-centricity work argues that teams with strong user focus have materially better organisational performance and warns that AI without a user-centred "North Star" can accelerate teams in the wrong direction. The same DORA guidance identifieds spec-driven development as an emerging paradigm in which user needs and constraints are refined into documentation that becomes the source of truth for AI agents. GitHub describes the same pattern in operational terms:  the spec becomes a living, executable shared source of truth; the plan encodes architecture and constraints; tasks decompose the work into reviewable units; and the coding agent implements against that governed intent.  GitHub is explicit that the movement is from "code is the source of truth" toward "intent is the source of truth."

The technical basis for this model is increasingly plausible becuase large language models are already being applied across the software-engineering workflow, not just to code generation. A recent survey of LLMs for software engineering found research activity spanning five crucilal phases of the SE workflow and 112 code-related task types. A controleld experiment reported by Microsoft found developers with GitHub Copilot completed a coding task 55.8 percent faster, while a 2025 Microsoft Research study across three field experiments and 4,867 developers found a 26.08 percent increasein completed tasks. At the same time, a 2025 randomized study by METR found that experienced open-source developers working in familiar repositories took 19 percent long when AI tools were allowed.  The sound conclusion is therefore not that AI can replace engineering judgement, but that AI can perform substantial portions of the translation from intent to implementation when the work is well-scoped, the context is strong, and expert oversight remains in place.

A reasonable sysnthese of the evidence is that the post-SDLC model should minimize ceremonial documentation and maximise executable, decision-relevant artefacts.  In practice, that means expressingthe work as a compact chain of intent: strategic objective, user and business outcome, capability definition, constraints and policies, architecturual guardrails, acceptance criteria, and delivery telemetry.  The role of AI-enabled tools is then to expand, implement, test, and refine that intent, while experts valiate whether the result is correct, safe, viable, and valuable.

Requirementum QGR and the implications of this paper
Viewed through the argument of this paper, Requirementum QGR can be understood as an attempt to operationalize the shift from static SDLC documents towawrds expert-guided, executable intent. The model begins not with tickets or user stories, but with business strategy, operating context, domain rules, desired capabilies, and measurable outcomes.  Those are refined collaborateively by senior business-architecture and analysis roles together with domain experts, producing a more direct and higher-fidelity expression of intent that traditional phase-gated requirements handoffs typically achieve. This interpretation is consistent with the evidence that user-centric, high-quality documentation, fast feedback, and embedded quality practices outperform heavy approvals and late-stage verification.

From there, a Requirementum QGR workflow would treat requirements not as a final prose deliverable but as governed inputs to downstream executions:solution design, code generation, test generation, validation, deployment preparation, and continuous refinement.  That aligns closely with the executable-specification tradition described by Fuchs and with contemporary spec-driven development practices described by DORA and GitHub.  In that sense, the distinctive promise of Requirementum QGR is not "less thinking" or "no documentation"; it is fewer interpretive layers between business intent and working capability, with more human expertise concentrated where it matters most, problem framing, constraint definition, validation, and governance.

If this framing is correct, and we think it is, the practical importance of Requirementum QGR is that it supports a new division of labour.  Experts and analysts define the right thing to build, express it in a structured and testable way, and validate the result against business and operational reality. AI-enabled tools accelerate the conversion of that intent into architecture, code, tests, and deployment artefacts. The gain is not simply speed.  It is the possibility of replacing long documentation chains and repeated handoffs with a shorter path from objective to deployed capability, while preserving human accountability for quality, risk, and fitness for purpose. That is precisely the domain in which the classical SDLC is weakest and the post-SLDC model is strongest.

Open questions and limitation
Two cautions are necessary.  First, the evidence on AI-assisted software development is heterogeneous.  Controlled experiments and field studies show meaningful gains in some settings, but the METR study shows that experienced developers in familiar codebases can be slowed down by current tools.  Any claim that AI universally accelerates development would therefore be overstated.  The strongest evidence supports an expert-guided model in which AI is a force multiplier, not an autonomous substitute for architectural and domain judgement.

Second, declaring the SDLC "obsolete" should not be read as a rejection of lifecycle responsiblity, documentation, governance, or engineering discipline. The argument of this paper is narrower and more precise:  the single-pass, document-driven, handoff-heavy interpretation of the SDLC is no longer the most effective default for digital capability delivery, especially in an environment where modern tooling can execute structureintent and where feedback from testing and production is immediate.  What survives from the SDLC is the discipline to think clearly about requirements, design, verification, operation, and change. What does not survive intact is the assumption that these must proceed mainly through static documents and sequential organizational silos.

‍