Top 5 business requirements document tips

Understanding the business requirements and user requirements of any website or application is key to understanding what you are building and why. 

Documenting business and user requirements also allow for work to be prioritised and where discipline is needed in a project due to time, budget or resource restraints, for all parties to be easily able to know what absolutely must be done versus what could be done.

Our advice to clients is always to maintain tight discipline in any project and certainly always the first project; prove the concept, be brilliant and one thing, observe how users interact and then work out what to build and optimise.

Many people over-complicate the documentation of business requirements by trying to be too technical and clever.

The business requirements should be readable and understood by anyone in the business, not just IT or developers. Keep it simple

So, my top 5-tips for producing a business requirements document.

1. Structure is key!

You need to setup a logical and well-structured template. One that captures all critical areas and data required before we dive into any project.

2. Early bird catches the worm

It is important to identify all problems upfront so that you are across all possible issues and can start tackling these problems early on. There’s no point in sugar coating anything – it will just cause even more issues down the track.

3. Understand its purpose

A business requirements document is not there to show off your writing. It is there to gather critical data and understanding of the your needs, as well as to gather feedback on them. This documentation of both worlds then serves as the platform to nut out what each side wants/needs and paves the way to the 'how'. This document is also a point of collating any and all potential risks and/or problems. Above all, the fundamental reason for one is accountability and traceability.

How many times have a you been on a project where in one of the last phases someone pulled out of left-wing a requirement they 'mentioned' in the initial consultation that simply got lost along the way?

4. Sign-off

All your documents need to have a sign-off page. It is important all requirement documentation is approved and signed off; again, this is to ensure understanding on both-ends, as well as accountability and traceability.

5. As MJ sang… ‘make a change’

All these changes sound good on paper (and PC) but it's up to each member of the project to actually pick it up and roll with it. Change is a hard thing, especially one pushing for more structure, but it must be tried and tested before discounted. If all goes well, you will be surprised at the benefits you will reap across the board.