The Report Design Process

The following describes the process of report design; although written from a Crystal Reports perspective aspects of it are generic.

1. Begin by defining the purpose of the report. As tempting as it might be to just dive in, writing a one sentence outline of the report will help you maintain focus.
2. Now you know what your report aims to achieve begin the process of requirements gathering. Think about the information you want to see in the report and how this will look on paper (or on screen). For example, which fields are to appear in the report? In which order are they to appear? Put yourself in the end-user's shoes and ask yourself if the information 'flows' – are the fields logically placed to lead the user across the page and to the most pertinent information? It's a good idea to think of a report title and filename at this stage.
3. Now begin the process of locating the data in the database. For each field you've included in the report design determine where or how you'll retrieve that data. A field may link directly to a database field or it may need to be calculated. You may also need to write functions to yield the specific information the report requires. Identify fields that will be used to group the data and begin to think around where the bulk of the data processing is to be done – on the server (using functions, views or stored procedures) or processed locally on the client PC. Decisions you make here aren't set in stone; report design is iterative and what seemed a good approach at the start may need modifying as the report is developed.
4. The building of a prototype can now commence. At this stage focus on the lowest level data and ensure that's correct. Put the main fields in place and test. Making the report pretty at this stage isn't important; ensuring you understood the requirements and have correctly identified each of the fields is.
5. Add successive layers of complexity such as grouping, formulas or calculated fields (subtotals or running totals) and test at each stage. Such incremental development ensures each new addition works. Don't forget to include comments in your functions (or as hidden fields in the report) to assist those whose job it may be to support or build on what you've developed. As the report begins to take shape imagine yourself as the end-user and see what other information would be best included, or if fields would be better swapped round or grouped or sorted differently; where possible involve the end-user in the process – unless you're building to a well thought out specification (which is rare) – in which case build to the specification.
6. Test every aspect of your report. Ensure that figures in your report correspond with those from the application (where possible); managers seem to have an intuitive feeling that a figure is wrong – it may be higher or lower than expected but make sure it's not because your calculation/logic is incorrect. Check totals add up - and for each group. This is especially important if the figures are based on formulas or Running Totals.
7. Tidy up. Now is the time to make your report look good. Ensure all columns line up, all fields are the same height (where appropriate) and the same font is used throughout. Ensure all grand total fields are large enough to accommodate the total value, that there's space for a minus sign, a thousands separator, decimal points and currency symbol (where applicable). Add a logo and page headers and footers as appropriate. Making a report look the part can often take longer than developing it in the first instance. But it is worth making the effort –especially so if it's for a client.
8. Deliver for approval. Aim for sign-off.
9. Beware of the following:
   1. A report generally takes longer to develop than expected.
   2. Reports will typically highlight errors or anomalies in your data.
   3. Changes to the database, such as an upgrade or performance re-engineering, may require changes to dependent reports.
   4. Highly summarised reports are often deceptively complex – and as a consequence take more time to develop.
   5. Report writing can be straight-forward if the data you need is in a form that's ready to be reported on. For highly summarised reports that is not often the case.