The mesmerising allure of software requirements

Ever been captivated by the idea of a perfectly planned project? That’s the mesmerizing allure of software requirements.

All projects start with an idea. But that rarely feels like enough. You can’t build something if you don’t know what it is. Approach a civil engineer asking them to build a bridge. They will immediately want to know what materials you plan to use, what’s the required span, what should be the capacity, maximum load, what are the local weather conditions, are earthquakes likely, what surface you want, what top speed of the vehicles crossing the bridge, and so on. They will send you off to create a detailed specification, design the bridge, assemble the required materials and workforce and then, maybe, you can start putting it together.

This is the process we can imagine, relate to and internalise. It fits well with our predisposition towards the material world. Never mind the fact that this approach is not actually how modern bridges are built. Yet this sequential, specification-first approach feels safe. It promises predictability, clear budgets, and defined accountability. We can point to a document and say “this is what we agreed to build”.

It’s very tempting to approach creating software in a similar way - wanting to know, in great detail, what needs to be built before we engage in the development efforts. We are tempted to start with a meticulous blueprint. We often believe that capturing every detail helps us stay in control. Long gone, in most cases, are the endless pages of specification documents and modern tools offer an alluring alternative. Software project management solutions abound, presenting attractive UIs that facilitate easy capture, indexing, management and reporting of a virtually endless list of software requirements. Call them epics, stories, use cases - it doesn’t matter. It’s still the same illusion. It’s like collecting puzzle pieces, often without seeing the bigger picture. But even short, agile-friendly requirements can trap teams offering an illusion of control under a veil of certainty.

Software is different and your well-tried and valid instincts from the material world do not apply, in the same way, to bits and bytes that can be manipulated and altered at a moment’s notice. Building software is not like building something, it’s more like designing something, it’s like inventing something new. The beauty of working with software is that you don’t need to know exactly what you want and, to be frank, you almost never do.

I’ve lived on both sides of the spectrum. In the past I have experienced software projects heavily focused on capturing detailed and specific requirements. For some time, this was actually my main job - to express in writing - ideas, desires and needs of the users. To think and capture the functional requirements and the non-functional requirements. To pass them on to the development team and wait until a perfectly crafted piece of software emerges. Only it rarely did. My more recent decade, on the other hand, was spent experiencing software being built without formalised requirements, with no digital tools to capture or express them, no dedicated roles to specify what needs to be built. Instead I saw cross-functional teams collaborating tightly and regularly delivering solutions that were delightful to the users and provided them with real value. Sometimes in ways that surprised everyone involved. Who would have guessed that moving that button to the left of the screen would drive engagement up by 15%!

Requirements are supposed to express what’s in our minds — but the written word rarely does that well. Successful software teams understand that, and instead of using text, we create a shared mental model that evolves with the team. We do this by conversations, collaboration, co-creation and a lot of trial and error, not documentation.

There is one more, very important effect of shifting from written requirements to collaborative discovery. When we write-down, perfect and hand them over from function to function in a sequential manner we create a trap. It’s a trap that promotes boundary building, silos and shifting of responsibility very often leading to frustration and blame. We assume that our intent and expression of an idea was clear, precise and easy to understand. If the outcome is not what we have imagined, it’s not a problem of our specification, it’s an implementation problem. There is another way. We can choose instead to collaborate across boundaries, to create shared ownership, and provide opportunities to clarify everyone’s understanding. This approach tends to be more rewarding and is way more engaging for everyone involved. If we are there to see how our intent is interpreted and have an opportunity to correct, clarify or challenge our own ideas we feel more ownership and alway make progress more quickly. It’s really satisfying.

Requirements are important. And the best ones aren’t written down but discussed. They’re not isolated puzzle pieces - they’re part of a shared picture we build together. Understood, refined, and ultimately made real through the products we create; the only meaningful expression of what our users truly need and desire.