The Community Blog for Business Analysts

stobin
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.
Like this article:
  0 members liked this article

Related Articles

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
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. Report <1> -
a. Objective
b. Type
c. Frequency
d. User
e. Available Columns for the report (of the entire module)
f. Useable Columns for the report (of the specific report)
g. Advanced Functions
Salman Saleem posted on Wednesday, January 13, 2010 11:14 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. Report <1> -
a. Objective
b. Type
c. Frequency
d. User
e. Available Columns for the report (of the entire module)
f. Useable Columns for the report (of the specific report)
g. Advanced Functions
i. Count
ii. Sum
iii. Sorting Order
h. Calculations
i. Exporting / Printable Functions

Hope this helps.

BR.
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.


Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.



Copyright 2006-2019 by Modern Analyst Media LLC