The Requirement of Requirements in Software Projects — Yakir Havin

Yakir Havin

The Requirement of Requirements in Software Projects

Published on July 22, 2026

Most people, if you asked them, would agree that Proper Planning Prevents Poor Performance. If you undertake a project, it needs to have a plan setting out what it aims to do and how it aims to do it. But knowing that a plan is critical to success and actually making that plan seem to be two different things altogether.

I recently read a famous IEEE article from 2005 called Why Software Fails, and one of the top reasons across a vast slew of major software project failures was “badly defined system requirements”. Technically worded like that, it sounds almost reasonable, as if it were just something that kinda happens, y'know. “Everything would have been fine, but we didn’t define the system requirements well.”

Huh?

Badly defined system requirements is corporate speak for having no real idea what you set out to do. You may have had a goal, even a realistic one, but you just missed out on the minor detail of planning how to achieve that goal. Just bad luck, I suppose. Next time we’ll get there.

I recently failed at my project of becoming a billionaire by the end of June — nothing catastrophic went wrong, I just didn’t plan how I was going to make up the almost billion dollar gap between my current and hoped-for wealth. Otherwise, all good.

The reason I’m writing about all of this is because I’ve experienced it a number of times as a freelancer building software and spreadsheet solutions for clients. I previously wrote about turning down projects that didn’t make sense, mostly due to spreadsheets being jammed in places that they shouldn’t, but the same thing applies in the rest of the software world.

It’s frustrating knowing that there are businesspeople with genuine problems that could be solved with elegant software solutions, but that the project doesn’t work out. More than the fact that money is being left on the table, it’s the fact that this situation is so preventable. The businessperson leaves the interaction feeling disappointed that they didn’t get somewhere concrete, and I add another brick in the wall of potential projects that never really took off. I’m happy that the project got scrapped as early as it did, before too much time, effort, and money got wasted, but when it happens repeatedly, the disenchantment grows.

For me, it usually goes something like this. I get a call from a businessperson looking to make something to help solve a process in their business. They’ve successfully identified that their current system isn’t doing what it should, or is requiring too much manual and repetitive work. (Since the birth of the LLM, the pre-existing appetite for automation and the relentless elimination of repetitive digital work has become insatiable. The alarm bell that goes off in someone’s head now when they realise they’re doing routine work is a good thing in principle — perhaps it’s gone a bit far and some non-technical folk are starting to fall prey to a disease previously only affecting developers — but that’s not the focus of this article.)

So I talk with the businessperson for around 30 minutes while they show me their current system and explain what’s wrong with it. Unknowingly, they’ve used a fair bit of domain-specific jargon that requires unpacking. These are shortcut words that their coworkers or industry understand but that they’ve forgotten other people completely do not. And this accidental tunnel vision extends from their language to their systems, where sometimes they implicitly believe that their workflow is a well-known one and of course I must know about it and know of a well-known solution to it. Once again, this is a good thought in principle, as many business problems are already solved and don’t require new wheels to be invented, but the devil is often in the details. Lord Varys once said that “a small man can cast a very large shadow”, and with software projects, sometimes a small, as-yet-unknown issue will completely throw off a solution and require an entirely new direction to be taken.

The breaking point then comes when the topic of the call turns to costs and time estimations. The IEEE article from above says “estimating how much an IT project will cost and how long it will take is as much art as science”, and this is as true nowadays as it was in 2005. It’s an inherently hard problem. But there’s also no issue with the potential client wanting to know what it would cost. The issue is that we’ve only spoken for at best 25 minutes, and it’s practically impossible for me to say much of real value at that point. Usually, I can tell fairly quickly if something will definitely not work. But most of the time, we’re in the middle zone where I could think of several potential solutions, but without knowing a whole lot more about the current system and the way the person works, I really can’t say for...