This is in response to expressing report requirements as use cases, or not. I agree with Andrew, based on his response of July 20th, 2007 at 10:15 am. The view I’m promoting in our organization is aimed at crispness, which is achieved by realizing that:
(a) There is a difference between business use cases (manual processes that use system processes at certain points) and system use cases (the actual system processes themselves).
(b) For business use cases the ‘system under consideration’ is a business organization; for system use cases it is an automated system.
(c) If nothing else, as Systems Analysts we need to define system use cases (in our organization, business processes are designed and documented by the business); I prefer to call this ‘system modeling’ rather than the vaguer ‘use case modeling’, because in the end we end up modeling systems and the way they’re being used by people (human actors) and other systems (non-human actors).
(d) The rationale for the existence of any system use case is that it has to enable its human actor to fulfill a goal within some business use case (traceability of system use cases back to business use cases) or enable its non-human actor to fulfill a goal within some other system use case (traceability of system use cases back to system use cases).
(e) Each system use case ends up defining a distinct ‘round trip’ interaction between an actor and the system under consideration, whereby the actor satisfies a specific, single and measurable goal (at the use case definition stage, there is no assumption on how multiple ‘round trip’ use cases might conceivably be combined into a single application).
(f) The functionality of any system is therefore described as a set of system use cases for that system (or, to put it in OO terms, the system use cases constitute the operations of the system under consideration).
(g) That being so, I expect to see a system use case for ANY use ANY actor makes of the system, which includes asking the system for reports, whether directly (on-line / on demand) of indirectly (batch / scheduled).
(h) This provides a uniform (ease of understanding), all-inclusive (one-stop shopping), technology-neutral (logical) inventory of a system’s functionality.

I’m advocating these and many other points in a two-day internal use case modeling course I recently designed, have delivered once late last year, and am planning to deliver throughout the rest of our organization this year. Initially feedback has been favourable.

Regards,

Willem

Willem Van Galen | Senior Systems Analyst |
Information Services | London Life Insurance Co. | London, ON | 519-435-4087 |

With this information, you have all the information you need for report requirements. Now, where do these requirement go? You’ll need a use case that describes the functional aspects of a report (generation, storage, formatting, reading) You’ll also need a report specification that describes the contents of the report, who needs it and why, especially if that information describes something outside your system, and perhaps even the layout of the report.

Most of my systems merely generate reports. The use of them happens somewhere else. When this is the case, I create a use case for the generation and put the report specifications in the Supplemental Spec, since it a non-functional requirement.

You also want to make sure you understand how the report will be created. Is it a set report, or is it an ad-hoc report? Do you need functionality in your system to create a new report template, or will this happen so rarely that it can be part of a project and the template is just hard-coded? If an ad-hoc report, then you need to describe the functionality of setting up the report to generate it.

It’s my opnion that even in the case of Geri’s very simple generate report, there is value in capturing a use case for a report’s generation because it shows that our system needs to have the ability to generate a report. Granted, it’s not too interesting of a use case, but the fact of the use case means that there is a functional requirement for report generation. But that’s just one person’s opinion.