In 2025 LLMs Will Be the Secret Sauce in Software Development

AI, specifically large language models (LLMs), fundamentally changes software development. Those who have followed this trend have seen LLMs weave their way into every aspect of the development process, from the initial planning stages through maintenance and beyond.

When you look at the characteristics of successful software projects, one constant is solid requirements engineering. It’s like building a house — without a proper foundation and blueprint, even the most skilled builders will struggle. Effective requirements engineering creates the essential roadmap that guides the entire development journey.

Think of requirements engineering as the backbone of the whole operation. It’s not just about noting what the software needs to do; it’s a systematic process that helps define, document, and adapt requirements as the project evolves. In today’s fast-paced development environment, having this structured approach is more critical than ever.

The Importance of an Upfront Investment in Requirements

In traditional development cycles, the requirements phase is often the first to face time or budget cuts. Still, industry trends indicate a growing recognition of its importance, particularly for modernization projects. Investing in robust requirements engineering can dramatically reduce overall project costs and timelines, enabling faster iterations and improved outcomes.

Why has requirements-gathering historically been deprioritized in software development? First, there is constant pressure to deliver faster, better, and cheaper solutions. In this environment, reducing the scope of requirements gathering allows teams to compress project timelines. For instance, what might have been a six-week requirements phase gets condensed to two weeks, creating the appearance of significant time savings.

Another critical factor is the widespread misconception that requirements gathering is straightforward. Stakeholders may present a seemingly simple request — such as “I want a website where people can purchase my magazine” — without recognizing the complexity beneath the surface. This oversimplification overlooks crucial considerations: subscription models, payment processing systems, hosting infrastructure, mobile compatibility, content format specifications, file size limitations, and more.

This tendency to trivialize complexity, particularly among project sponsors, often leads to a “just build it” mentality. However, this frequently results in “unexpressed constraints” during development. When these previously unconsidered requirements surface mid-project, they significantly disrupt development timelines and project success.

A Structured Approach to Understanding Needs

Requirements engineering is vital to software development because it focuses on systematically extracting, organizing, and documenting what a system needs to accomplish. It ensures that all necessary functional and non-functional features are captured, setting the stage for successful project execution. There are two primary contexts where requirements engineering plays a pivotal role in two primary contexts: net-new application development and modernization or migration of legacy systems.

For new applications, product managers and business analysts collaborate closely with business users to understand their goals and desired features. They work alongside technical teams to ensure all aspects, including infrastructure needs and system limitations, are factored into the requirements. Meanwhile, with legacy systems, the emphasis is on eliciting and documenting the existing system’s functionality to guide its modernization.

A requirements-driven approach is shaping the future of software development. Modern tools like AI-assisted code generation excel at producing discrete code segments but often falter in tackling complex applications. This isn’t necessarily a limitation of the tools but a reflection of insufficient or incomplete instructions provided to them.

More effort will be allocated to capturing and refining requirements in a requirements-driven future, ensuring they’re detailed and precise enough to guide both human developers and AI-driven systems. This shift relies on breaking down problems into granular, actionable components that facilitate accurate code generation.

Two Sides of Requirements Engineering

Recently, at GitHub Universe, I presented the topic of a $700 billion hole in AI that no one is talking about. In a conference (and world) full of research and capital allocated to using AI to generate code, few have noticed the empirical evidence that 70% of software projects fail, based on Gartner’s 2024 project spend forecast of nearly $1 trillion. Of those projects that fail, 78% are due to poor requirements management, equating to a smaller — but still huge — $546 billion problem.

👁 Image

In my presentation, I asked the audience tongue-in-cheek, “So if attention is all you need, why is no one paying attention?” It’s a great question, but as outlined above, requirements gathering is something that few organizations pay proper attention to. There are generally two ways we see organizations using our tool for requirements: requirements encoding and requirement decoding.

Side 1: Requirements Encoding is the process of turning ideas into structured requirements that can be translated into code executable on a Von Neumann machine — essentially turning abstract human needs into instructions clear enough that multiple people from different disciplines can execute against them effectively. It’s tough to do, not because writing code is complex but because interpreting human intent is hard. If you’ve tried the classic “PB&J” example taught at almost every entry-level computer science class, you know how hard it is to translate needs when you know what the customer is asking for. In the real world, however, this classic thought experiment would change with the only instructions given being, “I’m hungry and need something with multiple ingredients.”

As I mentioned, this process is very difficult but the key to any project’s success. However, for many organizations, it’s the first place they cut budgets and timelines. This is incredible, given that we know from empirical evidence that strong requirements are the leading factor in project success.

Why oh why — if attention is all you need — is no one paying attention?

Side 2: Requirements Decoding

Now, there’s a flip side to requirements, which we call “requirements decoding” — the process of taking an existing application and “decoding” what it does from code into requirements. This is particularly crucial for legacy systems developed over multiple decades, where comprehensive system knowledge has often eroded. It may be easy to call this effort easy; you simply have someone click through an application and document what it does. Duh! But not quite.

If you’ve ever tried to modernize a large legacy system, you know that sometimes, when you poke it in one spot, something breaks over there, and no one knows why. The features from a UI/UX standpoint may seem disparate and unconnected, but engineers are doing their engineering things, and it doesn’t always make sense.

Decoding from a feature and code perspective into robust requirements is the only way to modernize any legacy system. It gives the modernization teams a clear understanding of end functionality and insights into what’s going on under the hood.

Organizations that use our models for legacy modernization typically go through three steps that have been shown to reduce human overhead by up to 48%.

1. Automated analysis and specification building. Analyze existing codebases and generate initial models and specifications. This process, often called “code-to-spec,” provides a foundation for understanding the legacy system’s current state.
2. Fine-tuning and enhancements. Collaborate with stakeholders to refine and enhance the generated requirements. This stage often involves adding new features or improving existing functionality to ensure the updated system aligns with current business objectives.
3. Context-driven code generation. We don’t care where or how code gets generated, whether by a human or machine. What we care about is delivering the intelligence to the person or machine so that they can write the best code as efficiently as possible. The “requirements intelligence” we built during the previous two steps is extensible to tools such as GitHub Copilot, making them better — significantly better.

An Evolving Landscape Requires Evolving Skill Sets

Looking ahead, the role of requirements engineering in software development will only become more important as systems become increasingly complex and interconnected. Translating human needs into precise technical requirements will remain a cornerstone of success. The difference between success and failure takes more than technical expertise; it requires uncovering and articulating the implicit needs, constraints, and expectations that business users may struggle to express directly.

Given this, the future will likely demand an even more sophisticated blend of technical knowledge, business acumen, and interpersonal skills. Successful project managers must continue to develop their ability to ask probing questions, challenge assumptions, and facilitate meaningful dialogue with stakeholders. The most valuable will be those who can bridge the growing gap between complex technical possibilities and fundamental human needs.

Ultimately, the art of requirements engineering goes well beyond documenting specifications. It’s about fostering a deep understanding that turns vague ideas into viable solutions. By investing in these foundational skills and processes, organizations better position themselves to deliver software that truly meets user needs and creates competitive advantages.

This article is part of The New Stack’s contributor network. Have insights on the latest challenges and innovations affecting developers? We’d love to hear from you. Become a contributor and share your expertise by filling out this form or emailing Matt Burns at mattburns@thenewstack.io.