Business Analyst Community & Resources | Modern Analyst

The Community Blog for Business Analysts

stobin

Presenting Reporting Requirements in a BRD

We have been struggling with what to include in a Business Requirements Document concerning reports. Because our BRD is more or less a contract between the client and our IT department, the greater the detail in this document the longer the time to obtain signoff. There are always modifications that are deemed necessary before signoff can happen. Often these modifications have technical impacts on design and development. I'm looking for suggestions on what to include and what not to include in the Reports section of the BRD. Comments are welcome.

Our current document includes the following:

7.1.1 Report Name

7.1.1.1 Description

7.1.1.2 Frequency

7.1.1.3 Selection Criteria (parameters used to select data for inclusion in the report)

7.1.1.4 Fields

7.1.1.5 Sort Order

7.1.1.6 Extraordinary Calculations

This entry was published on Aug 04, 2009 / stobin. Posted in Requirements Analysis (BABOK KA) . Bookmark the Permalink or E-mail it to a friend.

3 members liked this article

COMMENTS

charmy posted on Wednesday, August 5, 2009 12:40 AM

Hi,

charmy posted on Wednesday, August 5, 2009 12:43 AM

Hi,
One question: Are you trying to create a BRD for each report in your module? If yes then this detail is fine enough.

Also you can also give details of which user role will have access to that report (Role based access).

conniebarton posted on Sunday, August 16, 2009 6:16 PM

Hello,

I think it's important to include the delivery mechanism unless all reports in the organization are delivered through an existing mechanism. For example - is the report run in batch and made available online? Is it delivered through email? Posted to a web page? Be sure to include the levels of summary if any of the data is summarized. For example do you need daily weekly, monthly and annual totals? Counts by state, region, country? Are page breaks required? Does the report data need to be presented in a way that is exportable? Also, if you are replacing an existing report, it's often helpful to include a sample as an appendix.

Good luck!

Steve Jones posted on Wednesday, September 9, 2009 10:05 PM

Who is responsible for doing the report creation? If it falls within the parameters of the IT team, then yes, by all means include report information within the BRD. The alternative is to create separate BRDs for each reports, that way sign-off won't be quite as difficult.

If you decide to create separate BRDs, then make sure each is referenced within the main BRD in addition to including enough technical solution information to support the reporting needs. I agree that an entry for Users should be included but more importantly, Report Owners (those authorized to request changes in the future).

Whether you are creating separate BRDs for each report or including it within the larger BRD, a mock-up is important, especially since most customers are visual creatures.. they'll get a good idea of what to expect.

Cheers.

Harris Lloyd-Levy posted on Wednesday, November 4, 2009 10:30 PM

I think you're coming at this from the wrong angle.

If you want to stay within scope and estimate without antagonizing the business forget the detailed description of the report and just capture:
* What questions do stakeholder have that are answered by your report?
* What decisions do they make based on the report?

If you get a report that meets these requirements you won't have the business raising change requests. Conversely if you develop a report that doesn't meet these requirements you're getting into trouble with your business no matter how detailed the spec is.

http://consultnik.blogspot.com/2009/07/does-your-specification-destroy-trust.html

Alternatively just put time in your estimates for some set number and set complexity of reports and develop towards the end of the project iteratively.

Salman Saleem posted on Wednesday, January 13, 2010 11:07 PM

Hi,

While working with a solution that generates reports, the first thing you need to ask stakeholders, with respect to reports:

1. What is the objective of requesting automation for reports?
2. How do you intend to use these reports? For filing, recording purposes?
3. How does automation of reports enhances your current performance?

Then, once you receive the response to these, you will need to determine the nature of reports they may be requiring. Any department usually uses MS Excel to consolidate data into reports, so they may require charting as well. If you do not keep this under consideration, this might create complications for the development team, as MS Excel automatically determines the charting type to be used. Please confirm on this.

Once these two parts are confirmed, you might want to include the following headings:

1. Reports

Salman Saleem posted on Wednesday, January 13, 2010 11:10 PM

Salman Saleem posted on Wednesday, January 13, 2010 11:14 PM

MoChat posted on Wednesday, November 5, 2014 3:17 PM

Hello,

I am working on a BRD where

1) the reports are coming from multiple sources.
2) I was wondering if someone can please share the template
3) where should I be capturing the section consisting the details of the sources, if the source is disabled during the process, timeframe, whatever conversation I am having with my business users which need to be a part of BRD

Thanks
MC

Only registered users may post comments.

Modern Analyst Blog Latests

Jarett Hailes

Three Audacious Goals for Business Analysts in 2013

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...

Howard Podeswa

Hey IIBA, What’s Up With That?

Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...

Adrian M.

BA ABCs: “C” is for Class Diagram

Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN