Skip to main content

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. I.e.:

‘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? Good 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, stay tuned for my next blog : ‘Completely removing Business Requirement Documents from your organisation.’


Comments

friso said…
Sounds to me like you want to get rid of bad BRDs. But I find a lot of value in good BRDs. A good BRD (IMHO) does what it says on the tin: it states the requirements the business has and for which you, the project team, are to find a solution.

Point-for-point rebuttal:
* I want to read a good BRD. It tells me:
- who wants the thing I'm about to build
- why do they want it, in business terms. I can shift the technology, as long as it aligns with the stated business goals
* A good BRD does not even descibe the intent of functionality (and stays really far from solutions), it 'just' tells you the problem your client is having. This actually is the hard part, getting people not to think in solutions.
* Business people can tell you what they require, because they pay their bills (or they should). Therefore they can tell if they are spending a lot on e.g. correcting mistakes in some process. Their business requirement is bringing that cost down. It's up to others (you?) to find a solution to that problem. If your solution entails skipping the entire step that is causing the problems because you found you don't really need the input, good on you!
* A good BRD creates a delay by starting conversations. In writing the BRD the team is exploring the problems that need solving.
* A good BRD is not a representation of software. It's a representation of business requirements (hence the name)
* A good BRD does not need to cope with change. It is the reason you're building what you're building. That reason may change, in which case you need to stop what you're doing en re-evaluate the whole situation.
* Documentation is most certainly open to interpretation. But I know of no other way of sharing these ideas with a group of people. More communication is obviously better and talking helps. No need to leave the developer alone with the BRD. But, as a developer, it's nice to have it as a reference after it's been talked through.

Maybe I've been lucky in the BRDs I've encountered, but I find that if I hold them to these standard they are extremely usefull to me.

Groeten,

Friso
Thumbs up. Especially for the Bacon Workflow idea. The other implicit problem is the one of sunk cost: BRD have to be used, otherwise somebody should admit that the money spent writing them has been wasted.

Cheers
Nick de Voil said…
Alexandra, I strongly agree with many of your points about change control, trust etc, but the documents you are describing are not BRDs. They are Functional Specifications. I think many people agree now that FS's are only useful on a small subset of projects. A BRD should never "pre-suppose solutions". If it does that, it isn't a BRD.

A BRD is a thinking tool. Yes, there is some closing down and constraining that goes on, but actually every human communication of any sort (oral or written) does that. Alberto's point about sunk cost points up a common misconception. So many people fail to realise that it's the process of writing the document that's valuable, not so much the document itself.
Friso, thanks for your thoughtfully written reply, it makes me want to ask if you have come across any alternatives to BRD's in the past? In the absence of anything else to describe a requirement I can understand why you would have these ideas, however see so many higher quality richer ways to communicate these days, such as user stories and frankly good old face to face conversations at the white board. It's hard to believe BRD's still exist when I see the results of true rich communication between business and technology - hence me writing this post :)
Alberto, couldn't agree more, thanks for commenting!

Nick, Thanks for commenting but I couldn't agree less with the sunk cost misconception. I've looked into the sunk cost fallacy at length. These days there are so many ways to speed up requirements elicitation and therefore delivery - and then therefore customer value, that I just can't stomach the waste associated with laborious documentation any more; the waste coming from the lack of value they create for the creators of software. Hence I wanted to write this blog, so I didn't have to have the same conversation every time I do any work with clients on requirements elicitation. As a prior software developer I find them so wasteful it's worthy of 'software crime' in my opinion :) Feel free to get in touch if you want some tips on alternatives.

Popular posts from this blog

My take on SAFe - Scaled Agile Framework for the Enterprise

Something I’ve observed recently amongst this agile/lean/start up/digitally disrupted community that I’m in, is there are a lot of‘SAFe haters’ dissing on SAFe out there.
Well I’ve just come from a giant organisation that is actually making a good fist of ‘doing SAFe’, so I feel like I’ve got an experienced based perspective on SAFe which might be of interest to some.
I’ve been chatting to people on this topic, it astonishes me the amount of opinion that is being shared on SAFe. The criticism and the eye rolling and statements about what it is and isn’t. There’s a growing anticipation over how it will be received and perceived at up coming Lean and Agile conferences, the sense of controversy is palpable. I’ve been soul searching over my own recent experiences. Digested into one sentence my opinion is: “SAFe – it ain’t so bad, but it’s not the answer either.”
So, in what ways do I thinkSAFe is good and can help?
Lining up iterations amongst several teams.
I’ve observed and executed a few…

Agile Australia 2011 Series - Agile Governance

If you are in an industry that is heavily into governance you need some structure and process around your projects or you could find your Agile projects getting usurped by the culture of command and control. So it’s important not to shy away from the topic but to work with the entities that enforce and monitor governance. In this way you can create something that is fast and easy and not laborious to work with.I work for an Apra regulated organisation and we made keenly aware of our obligation under Apra to evidence documented change when audited. However in all organisations I’ve ever worked in, there are boundaries that bend quite a bit, ways to change things and ways to get by that satisfy governance process without crippling your agile process.There’s almost two alternating schools of thought here which are ‘work within process’ and ‘decide to change the process’. It’s actually pretty easy for my team to work within process. Project approvals, mandates and PIDs that are important …