The Requirements Document is today's Alchemy

Have you ever heard someone say this? "If only we had better requirements"

For a large portion of human history people kept trying to turn something heavy and not super valuable:

Lead

Into something much more valuable:

Gold

They didn't have a lot of success, and not for lack of trying. Once we discovered the nature of atoms we realized that they are actually two different elements and you can't actually make lead into gold.  

In modern software development people are still trying to do something similar, we're trying to turn these:

Business Requirements Document

Into these:

Happy Customers

Unfortunately, like a lot of alchemists of old, we're not having a lot of success. It's not for a lack of trying either.  The good news is that just like Alchemy was the precursor to modern Chemistry, software development is in the process of evolving into something better.  We've started to learn why it's so hard to take a business requirements document and turn it into something that actually makes customers happy.

Here are a couple of the issues that make it challenging:

First off, we know that only small portion of communication is actually written, but let's pretend that we had technology that would allow us to convey our intent perfectly.  We would still never have a perfect document simply because one person can't think of everything. One person can't predict all of the possible outcomes, or what we might learn as we develop something.  Requirements documents are flawed because they imply a hand-off.  We'll never be able to write something, hand it off, and expect it to get done the way we want.

Second, we're fighting human nature. Everyone at some point has been absolutely convinced that they need something, it will make their life easier, it will solve a problem, or will just be the greatest thing since sliced bread. Well, we get said item and after trying it out we say something to the effect of "Huh", and it ends up in storage, the garbage, donated, or turns into a white elephant gift.

What we really need to make happy customers is collaboration and feedback.  It's okay to have a statement of intent, or even better to define the problem, but what we really need is that collaboration throughout the development process.  We need the customer, or someone that understands the customer needs like a product owner, to be involved.  Help the delivery team define the problem and the solution, do it together. 

Lastly, get things to the customer early and often so that you can get feedback.  We want customers to play with it, try it out.  Tell us what actually works and what doesn't and why.  Take that feedback and use it to make your product better.  In Agile software development everything is pushing us to deliver large functionality in small batches.  One of the great advantages to doing things this way is that we can actually get things out to customers to play with before we finish everything.  We can and should change course while we're developing large functionality based on customer feedback.

There's nothing wrong with the mistakes we've made as long as we learn from them.  True, ancient alchemists never did learn to turn lead into gold, but they did learn a lot of other things that gave us our modern day understanding of chemistry. Likewise we may not have learned to create the perfect requirements document, but in the process we're learning why it doesn't work and better ways to do things.  So let's make sure those hard lessons on requirements documents don;t go to waste, and let's make happy customers!

And the next time you hear someone say "If only we had better requirements" you can answer "yeah, probably not"