There comes a time in every developers career where you will receive change request after change request on what in the beginning seems like an “easy” report. This can increase development time and create unnecessary tension and frustration between the end business user and the developer. How about those times where you encounter scope creep? Annoying right?
I have been put into a position to create business requirement documentation or a BRD for the reporting groups to help streamline the issues that we were facing in the above paragraph.
In general, I think the most important features are:
1. Report mock-up
This has been a LIFE SAVER! Seriously….This should be the easiest piece for the business user slapping together the document. Go into excel, create what you want the report to look like colors, layout, etc. Paste it into the requirements document. It alleviates any confusion for the developer on something as simple as the column headers or color schema.
Believe it or not this has been a tough one to get the business user to understand. Especially where I am now, they use different calculations for the same ‘meaning’ depending on the client. This can become confusing and flat out make a data warehouse impossible to obtain…But on the flip side, having these all up front can help the developer determine if the SQL engine will be best utilized in the dataset or within the RDL itself.
3. Roles – Developers, Testing, Approvals
Seems like a no brainer, but you would not believe how many times I have had to go back to the requestor and ask who will be validating and testing their material.
I highly encourage you to take a look at the document I have attached. It is the form I created and fine tune it to meet your organizations needs.