 |
| Search |
|
|
|
|
|
|
|
| |
| |
| |
|
Planning Your Report Design
(Part 1)
One of the most crucial first steps when designing reports is the creation of a "Report Requirements" document. A Report Requirements document will outline what information needs to appear in the report, how the report is used (is it interactive or run in a batch), and the general look and feel of the report.
You may also create a mock-up of the report or a rough sketch of what it will look like. With your report requirements in hand, the next step in our method is to perform a technical review of the report's definition.
A good place to start with a technical review is to determine the data source for this report. Most likely the data source will be a relational database, but the data could also reside in spreadsheets, text files, OLAP (OnLine Analytical Processing) data structures, and even non-relational data sources (like Exchange or Outlook folders).
Once you have found the data source, you will need to dig a little deeper to determine the exact tables and views that can provide the data required. You may need to develop additional views or stored procedures to consolidate the data prior to developing a report (for speed and ease of use and reuse) and these will need to be documented as well. Again, all of this information is added to your Report Requirements document.
For the next step of the technical review, you will need to investigate whether or not the design of the report is feasible. The user may request twenty columns (when the page will only fit seven landscape) or may have based the design on an existing report or spreadsheet created by hand.
As you grow to become more experienced working with Crystal Reports, you will begin to understand how the tool works and the kind of output that can be achieved. In the meantime, browse through some of the sample reports that ship with the product to get a feel for the types of reports Crystal can produce.
Once you have completed the technical review and you understand where the data for the report resides and you are comfortable that Crystal Reports.NET can deliver the required format, it is then time to create a report prototype from your notes and preliminary sketches. This prototype can be created using Word, Excel, Visio, and so on, but should closely match the report's final layout and design. Again, another important check is to make sure that the layout and design you create can be created with the features and functionality that Crystal Reports.NET has available.
A good way to determine if Crystal Reports.NET can deliver a particular format for data is to find a sample report that shows the data presented in the method you want to use or you could create a small proof-of-concept report with sample data to test the design.
The prototype, combined with a formal Report Requirements document will clearly communicate what the report should look like when it is finished. It also helps gain user acceptance for the design, as they can see what the finished product will look like (even before you have opened the Report Designer). If you are working in a large team, this documentation will communicate the requirements to other report developers, so you don't actually have to brief them on every single report that needs to be developed.
If you are working as a business analyst, application developer, and report developer all-in-one, it can also help you keep on track with the user's requirements and make gaining user acceptance that much easier. Once signed-off by the client, the Report Requirements is a contract, so should it turn out that the report designed isn't what the client wanted, you can point to this document and their signature on it!
Finally, with the documentation and prototype in hand, it is time to actually sit down, open the Report Designer and design your report.
Part 2>
Applies
to: Crystal Reports for Visual Studio.NET
©
Copyright 2006 by Crystal Developers Journal
Top of Page
|
|
|
|
