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.
Alternatives
============
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.
(No Ratings Yet)