Business Requirement Documents are just no good...

…and should be abolished from the world of creating software

I had hoped the world could have wholeheartedly rejected Business Requirement documents by now. For too long I’ve seen the repeated scenario of only commencing the creation of a new initiative with a requirements document.

Unfortunately most organisations that have teams developing software still use these flawed anathemas to creativity as

the status quo. Despite agile approaches maturing and customer-centric modes of design emerging, requirements documents still persist. 

If you work in an organisation that doesn’t use business requirement documents any more, read no further. You are lucky; sense has prevailed at your place however in my experience, you are still the minority.

Let's face it; addressing this issue is not always the point you want to start your improvement work when there's much that could be dysfunctional with how a team is delivering software. But now, I find myself as mad as hell, and I'm not going to take business requirement documents anymore. I want to capture why I believe business requirement documents (henceforth referred to as BRDs) are just no good and should be abolished from the world of creating software.

Why are they flawed?

• No one wants to read a BRD, least of all the developers who are expected to divine critical functional aspects from these dull and uninspiring tomes. Usually long and boring, more worryingly, they are often not read at all. You can test this quite easily. Many years ago, a mischievous college embedded a ‘Bacon workflow’ flow chart into his BRD; essentially all paths lead to Bacon. This was missed by the dozens of named stakeholders supposedly reviewing the document. We even logged the Bacon workflow addition into the change log table at the start of the document, this passed review without comment.

• A BRD closes down options for solving business problems, as they pre-suppose solutions rather than describing the intent of the functionality that is wanted. It’s common to read in a BRD a series of ‘The system must [perform functionality X and Y]’ statements. Worse, the stated key business problem or reason is given little credence. And worse still, alternative options are spoken of briefly and swiftly ruled out at the start of the document. You get the impression the document is telling you “Just build exactly this. And get it done quickly please!”.

• BRDs constrain ideas, solutions and creativity. How can you know that something is 'Required' if you haven’t spoken to a customer of the software yet? Have you showed them some working code and elicited their feedback? Have you spoken to the development team to see what might be possible? Ideas, solutions and creativity to solve whatever business problem needs software, can only be explored by interacting with the team that will build the system, using collaborative discussion. A requirements document will narrow down options and ideas, and may be materially harming the business you are building for. Is the potential for great engaging solutions being left on the table?

• A BRD creates a delay, or negates conversations, that should be happening at the very start of your new initiative. Waiting for a BRD to be produced means precious time and opportunity is lost, when instead, the team could be exploring the problems that need solving.

• BRDs are a poor representation of what is needed. What do I mean by this? It’s simply not possible to represent the beautiful organic, changeable and dynamic nature of a software program in something so serial and static as a written document. As both a former developer and business analyst, I can attest that replicating every consequence of every path that may be chosen in a software program, with a document, would result in a document as large as the code you need to write. Which begs the question; why not just write the code itself?

• A BRD copes poorly with change, they are fixed at a point in time and then forever more, change must be 'controlled'. This factor then becomes a barrier to changing. Change becomes labor-some and more effort is needed to reflect a change. What if a change is something wonderful that a customer might love and might make the organisation money? Too bad, the change will cost you extra in documentation overhead.  BRDs imply change is a bad thing.

• Because a BRD copes poorly with change, it creates the need for inflexible central document repositories with version control. If you have experienced the pain, dread and helplessness of trawling through document versions trying to determine a static point in history then you will agree that document repositories should also go the way of the BRD.

• Documentation is open to interpretation. The English language is colourful and descriptive.  Even when using terminology of precision, the interpretation of the written word is in the eye of the reader. If you want to test this it's easily done: provide the same written instructions for drawing a simple diagram to 3 different people. No two people will draw the same drawing. Programming is a creative activity. A developer makes an interpretation of what is required; expecting to leave them alone with a BRD to convey what is required will result in a deviation from expectations.

But perhaps more serious than the purely practical reasons stated, there are a number of cultural problems with the use of BRDs in software.

• A BRD perpetuates a lack of trust between people who are supposed to be working together to create something. Sections such as 'Sign-off', 'Out of Scope' and 'Authored by' signify the same sinister nature, ie.

  ‘Who is responsible for agreeing to this?’

  ‘Who can I blame for getting it wrong?’

  ‘Someone agreed to this and I will prove it to them later.’

  ‘I won't start until you authorise me to.’

  ’I don't believe your spoken word can be trusted.’

  ‘I need to prove you can't blame me if this goes wrong later.’

  ‘If you change your mind you will pay.’

Such an absence of trust is a dysfunctional atmosphere in which to expect anything but pedestrian software can be created. The nature of a BRD with such sections and stamps of authority is a signal that trust is missing between the individuals of the organisation. Such an organisation cannot support the collaborative teamwork required for truly outstanding software.

A BRD becomes a barrier between team and customer. In the worst examples it represents an attempt to translate the needs of a non-technical business to a team of people who can only speak 'techno-bable', which is somehow insulting to both parties. Any person or document placed between the people that want some software and team that build it, delays the relationship building between team and business. Efforts should be made instead to get team and business working effectively together and this requires that they know each other on a more human level than via a document.

So if we abolish requirements documents, what else can we use as tools of communication between business and team?

Great question!

There are many answers and options, but the first thing to do is to ask that good question. “What else can we use?”. I commit to asking this question early and often, instead of accepting that a BRD must be the default thing that is created.

I hope you will stand up for #NoRequirementsDocuments as well.

For many alternatives to BRDs for capturing requirements, as well as compelling answers and ideas to put forth in face of organisations with mandatory BRDs, get in touch with us, we can help.