Bear in mind the BRD will be used in a number of ways. Firstly the BRD is a statement of what the business want. It’s their shopping list so the business will have to agree with everything you have written. Secondly, for the IT or Change Team, the BRD is the main input in the design and implementation of the project.
Assuming you have completed the requirements elicitation process you are now looking at how to create a document that will make sense of the information you have collected and present it in the clearest, most comprehensive way possible. One crucial thing to remember is that we are writing requirements, not solutions. It’s a common trap a new business analysts can fall into. Throughout the document be careful not to be to prescriptive, describe requirements in terms of outcomes not hows…..
If you are working for a large corporation they will probably have a BRD template you have to follow but regardless if you use a template or not I think the following elements are really important.
Problem statement or objective – This should really be from the sponsor or from the business case. Having the objective in the document helps define the scope and gives context to the rest of the document.
Current state analysis – Improving an existing process relies on an understanding of what is currently happening. Through the elicitation process you will have learnt where any opportunities to improve lie and this will give you a starting point to validate or challenge the requirements the business offer. I always use diagrams and/or rich pictures in my documents, I find people will actually study a picture much more than they will read text. As part of the elicitation process you will probably have some material to hand that you can leverage.
Future state – Another thing I like to add before we get into the actual requirements is to create an overview, again the use of diagrams or rich pictures is best. Keep it really high level but the objective is to give the reader some context, a framework if you like, something that they use to hang the requirements from.
Summary table of requirements – Now we are getting in the meat of the document. The summary should list each and every requirement that is detailed further on. The idea here is that a reader can “at a glance” get a feel for the scope of the requirements. Each item in the list should be no more that a single sentence. (two at a push), later in the project this same list may be used as a starting point for user testing, therefore it’s useful if the requirements are phrased as “testable statements”. (I’ll cover this in a later post)
Detailed requirements – Taking each item from the summary table we now expand and write the requirement in detail. I use all the tools available, depending on the requirement I will write regular text, add examples, reference other sources, add diagrams and add tables. I will write in process steps or use cases. You name it I have used it. You need to try and find the best medium for your message. There are two points that apply to most situations though. First – Keep each requirement short, if you are using plain text and you are getting beyond two paragraphs consider breaking the requirement down further into smaller bits. And Secondly add examples, add as many examples as you can. There is no clearer way of explaining what you want than showing someone what an outcome should look like. (don’t confuse this with designing the process, its the outcome, not the how)
All my Business Requirement Documents have the above sections regardless of what the client asks for or the templates they provide. I consider these the core sections. Here are some others you may wish to include depending on how formal the project is: | Review and sign off tables | Revision History | In scope/ out of scope statements | Assumptions | Dependencies| Risks, issue & decisions log |
I attach a template here to get started with, please add or remove sections as it suits your project – Business Requirement Template (1315)