Why you need software requirements

Software development works best when developers sit directly with the users, hearing about their experiences using the software, discussing changes and what should come next. Conversations replace the need for requirements, and ideas and concepts are quickly knocked together and pushed out the door. Developers confidently release to real users because processes ensure high quality and guard against adverse effects. Feedback happens in near real-time; often, a simple comment, under-the-breath muttering, or facial expression is enough to gauge reception. It sounds like pure fantasy, but commercial software really was built like this circa year 2000 when I first started out.

This approach works because individual developers know multiple technologies and can work up and down the stack, delivering entire working features themselves. Developers create database tables and stored procedures, develop middle-tier code, and author front-end interfaces (often not very good ones, I admit). They may have strengths in particular technologies, but what’s important is delivering whole solutions. Additionally, these developers converse with real-life humans, sketch out rudimentary designs, and even test finished code, a far cry from most developers today. The role was called an ‘Analyst / Developer’, a fitting title for all they did.

Modern software development, particularly in large corporations, is very different to the early 2000’s. Technical complexity means developers specialise in one or two technologies or frameworks, teams are distributed globally, ‘product ownership’ and ‘user experience’ are completely new functions not previously existing, and DevOps usually sits outside the development team. I’m not against any of this, nor am I advocating a return to an earlier time; rather, I’m pointing out how things have changed in the software development industry. Rapid progress has brought many benefits.

Unfortunately, the further you stray from close collaboration between users and developers, the greater the likelihood of things going wrong, and the greater the need to manage the software development process carefully. Developers not sitting with actual users, or user advocates, starts to break the close collaboration and direct feedback loop that avoids the need for software requirements and software specifications in the first place.

Modern software development, particularly in large corporations, has definitively broken the link between users and developers, leaving a communication chasm of monumental proportions. Users and developers no longer collaborate, sometimes they have never even spoken to one another (I’m not actually kidding). The feedback loop is broken too, needing to traverse through layers of user researchers, product owners, designers and business analysts, before ending up in ticketing systems like Atlassian Jira and Azure DevOps.

You need software requirements when users and developers are no longer sitting side by side. It’s far from perfect, and often only a poor approximation of close collaboration and direct feedback, but you need them to bridge the monumental communication chasm that exists today. Software requirements are an undisputed fact of modern software development, particularly in large corporate and enterprise settings. It’s true, irrespective of whether you philosophically agree with defining requirements, or not.

I often hark back to earlier times and lust for the simplicity of being an ‘Analyst / Developer’, but I’m also a realist who wants to help make things better, today. So I populate ticketing systems with the very best requirements I can produce, making use of the full breadth of analysis skills I have for the mutual benefit of users and developers, and everyone else now involved in software development.

If you are unhappy with your development team, they may need more detailed guidance.

Better software requirements can help with this.