Use Cases and Reports

Author: Geri Schneider Winters

I get my best ideas for these tips from you, my readers. This tip is a response to a question from Pete McNally on how to document requirements for reports and whether or not those requirements should be use cases.

Use cases are really meant for describing a process or task. If you are going to use a use case to describe a report, what you really want to describe is what job or task a person is doing when he or she creates and views a report. Why is the person reading the report? What will the person do with the information?

For example, assume someone wants to look at an application for insurance. The person wants to create and view a report of all the applications waiting for approval. Why? Because the person is reviewing applications to decide if they should be approved or not. So creating and viewing the report is one part of a larger use case – Determine Insurance Eligibility. A step of that use case would be to get a report of all applications waiting for approval. Another step would be to select an application for review (with any rules you have for which one to select, such as pick the application with the oldest filing date).

Here is a bit of an example to illustrate this concept:

Determine Insurance Eligibility

1. The use case begins when the Evaluator asks the system for a list of all insurance applications waiting for approval.

2. The Evaluator selects the application that has the oldest filing date.

3. The system displays the details of that application.

4. The Evaluator enters the applicant’s age and medical information into the Health Calculator.

5. The Health Calculator determines the health index for the applicant and displays the health index to the Evaluator.

6. The Evaluator enters the applicant’s age, city and state of residence, number and age of dependents, and the health index into the Rate Calculator.

7. The Rate Calculator calculates the rate to be charged for the insurance.

…. There would probably be other steps here.

Application is denied

Now, what about step 1? What does that list of applications (report) look like? For that, you would use a report specification.

A report specification is a document that describes a report. In this document, you will describe the information that the user will enter into the system, how the report information is obtained or calculated, and what information is displayed to the user. You might also include a page with the design of the report, showing the various fields and the layout of the report. You can include any rules or algorithms that are used to create the report. You can include restrictions on who is allowed to generate or view the report, or indications as to when the report is run (for example, whenever needed, every night, once a week, once a month, once a quarter).

If there is no process that you can describe that includes creating a report, or viewing a report, then you do not need a use case at all. Just use the report specification to describe the contents of the report. It does not make sense to me to write a use case like this:

Create Quarterly Sales Report

1. The use case begins when the Accountant selects Generate Quarterly Sales Report.

2. The system calculates and displays the report.

3. The Accountant selects Save Report.

4. The system saves the report.

This use case provides me almost no useful information, and the little information it does provide can be put into the report specification with the other information about the report. There is no point to this use case, so why bother writing it?

Alerts and notifications may similarly fit better into another format.

Remember that not all requirements are use cases. Use Cases are great at describing tasks or processes – but not everything is a task or process. Reports are better described with a report specification document.


How do you describe reports, alerts, and notifications? Do you have a template for those types of requirements?

Do you see the usefulness of describing a task or process that includes creating and viewing a report?


4 thoughts on “Use Cases and Reports

  1. Andrew

    I tell my analysts that for every report you have to know a few things.
    1. Who needs the report
    2. Why do they need it (how do they use it)
    3. Who generates it
    4. How is it generated.
    5. What needs to be in the report.

    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. 🙂

  2. Willem Van Galen

    Hello Geri:

    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.



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

  3. Ganesh

    how can i document the requirements like,for example, after we generate a report, it can be exported into various reports format like , excel, pdf, xml,etc?

    Should we require to write this along with the report specification or as alternative flow options?

  4. Steve

    Sorry … but executing reports is a trivial use case and really adds little value to the description of requirements. Most reports are variations of:
    – got to tool/interface
    – enter parameters
    – execute
    – review results: order, collapse, expand etc

    The features, details & capabilities a report must deliver require a spec that doesn’t readily fit the framework of a use case: aggregation, summary, constraints, parameters, grouping, ordering etc all need proper & complete exploration before a report spec is complete, on top of Andrew’s list of why the report is needed (nice to ownership & audience there – ultra critical and often overlooked). Whilst each of these is unique per report, the basic use case is identical, and writing a use case per report (eg Generate Quarterly Sales Report), for a system that may have 100’s, seems wasteful. You may use a use case to define the global patterns & behaviours, but this seems more about making sure the use case modelling is comprehensive, rather than adding real value to the (delivery) process.

    Your post opens with “Use cases are really meant for describing a process or task” – sorry, they describe a contract between participants. This is a subtle difference, but very important as it influences how you describe the participants behaviours and expectations in steps.

Comments are closed.