Andy,

I think they should go in the non functional category and Use Cases can decribe most type of Reporting Requirements. Normally there are two main types of reports; ‘Pre-canned’ reports and ‘ad-hoc reports’. Pre-canned reports are those that are specified up-front by the stakeholders, with the input parameters that are available for that report defined along with the expected output of the report. The normal interaction between the Actor and the system to generate a pre-canned report is to select the report they want to run, enter/alter the parameters of the report, select the output format and select the date/time at which the report should be produced. The provision of Ad-hoc reports is usually handled by an MI tool that pulls data from one or more data sources or a data warehouse.

Use Cases do not lend themselves well to describing the functionality needed to provide ad-hoc reporting capabilities. Use Cases should be used however to describe the requirements of pre-canned reports. Pre-canned reports can be run on-demand or in batch mode i.e. generated at a particular date/time as set up in some kind of scheduler, or as a result of a particular condition. A separate Use Case should be used to describe the flow of events of a report generated on-demand, and a report generated as part of a batch run. In this case the initiating Actor is different and therefore the flow of events of the Use Case differ, hence the need for two separate Use Cases. A separate artefact should be used should be used to provide the following information for each Report that can be generated as a result of performing the Use Case.

Reports may be produced as part of the flow of events of a Use Case. Again, a Report Specification should be produced corresponding to that Use Case to describe all reports that are produced as a result of execution of that Use Case.

 K