COMMENTS
Hi,
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).
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!
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.
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.
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
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
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.