8.5 Reporting Infrastructure


8.5 Reporting Infrastructure

Purpose

A reporting infrastructure produces reports for us and usually lets us design new reports. You might decide to broaden this scope in various ways-such as to include matters relating to the database(s) on which the reports are produced, to add access control requirements not accommodated by off-the-shelf products, and to distribute and store reports after they have been produced.

The core of a reporting infrastructure is invariably a mainstream product built for the purpose. However, this might need to be augmented by extra capabilities we must build for ourselves, particularly if our infrastructure's scope goes beyond simply producing reports. Conceivably, our reporting requirements might be too onerous for a single reporting product to satisfy, and we might have to employ two or more products (for example, one for producing reports and one for designing them). If you specify requirements that cannot be satisfied by the known capabilities of commercial reporting products, be prepared for your reporting infrastructure to become a major undertaking.

Occasionally, organizations expect their reporting infrastructure to compensate for deficiencies in their database design, and therefore ask too much of it-especially its ability to cope with grotesquely complicated queries and joins. Be alert to this possibility. The result can be reports that are fragile and inefficient.

This section uses the term report to mean the definition of one type of report, and report instance to mean the results obtained by running a report at a particular time.

Invocation Requirements

A database usually acts as the primary interface between a system and the reporting infrastructure that produces its reports: the system places data in the database, and reports then read it. The first invocation requirements we must consider are those that give us all the database access capabilities we need. For example, if we have multiple databases, we might need to let our users choose which database to run a report on, or to run reports across more than one database. We might want to introduce a new database solely to run reports on, so they have no performance impact on the rest of the system. Requirements of this sort can become extensive and complex-and could justify turning them into a separate infrastructure in its own right. Strictly speaking, the types of requirements cited for database access could be considered implementation requirements, since they are features internal to the reporting infrastructure. But databases certainly act as an interface, and if we regard any interface as invocation-related, it is correct to class these as invocation requirements.

Other types of invocation requirements to consider are as follows:

  1. It shall be possible for other software to invoke a report.

  2. It shall be possible to display to a user a list of all the reports they are authorized to run.

  3. It shall be possible for a request to run a report to invoke special software to generate data before running the report itself.

  4. Are there other sources of data (that is, other than databases-such as XML documents, flat files, or the contents of LDAP directories) from which we want to produce reports?

Implementation Requirements

The major areas to consider in the implementation requirements of a reporting infrastructure are:

  1. A report design tool-it is easy to define requirements that no commercial design tool satisfies, so take particular care here. You might have to lower your (or your customer's) expectations.

  2. Delivery mechanisms for the ways in which a report can be delivered to a recipient. This includes onscreen display, printing, and ability to save in various output formats (of which HTML, CSV, plain text, XML, and PDF are common these days). For printing, consider how the printer to use is chosen and what our reporting infrastructure needs to know about available printers to achieve that. Possibly, we would like a report recipient to be able to forward that report instance to someone else.

  3. Chronicle entries (audit trails) that record when a report is run or is delivered to a recipient.

  4. Access control, which we might want to apply to all reporting functions (running, viewing, designing, and so on). Do we need to worry about restricting access to selected data, too? The impact of access control requirements can be severe, because commercial reporting products are usually poor at supporting them-and your chances of finding one that fits with your access control infrastructure are slim at best.

  5. Ways to notify recipients when a report has been produced for them.

  6. Report content and formatting, which might include the extent of graphics capabilities, totaling, charting, and anything else we want to be able to include in our reports. Such requirements are most useful when deciding which reporting product is most suitable or to alert us that our chosen product does not provide all the capabilities that we would ideally include.

  7. The scheduling of reports. Is it sufficient to be able to run a report on request, or do we need to be able to have certain reports run automatically at a specified frequency? If so, how fancy does the scheduling mechanism have to be, and what frequency options do we need?

  8. Reports on the usage of the reporting infrastructure, such as a summary report of the number of reports produced in a given time period.

  9. Backing up report definitions and report instances.

  10. Housekeeping, to purge report instances no longer needed.




Microsoft Press - Software Requirement Patterns
Software Requirement Patterns (Best Practices)
ISBN: 0735623988
EAN: 2147483647
Year: 2007
Pages: 110

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net