A use case is defined as how an actor interacts with the system. An actor is usually the user but could also be another system or piece of hardware. The system could be a business process but is usually a computer system. The bulk of a use case consists of sets of step-by-step actions involved in the interaction. Each separate way the use case can be carried out is called a path or scenario. The main path (or "happy path") describes the normal or most common success scenario. Alternative paths describe other ways to succeed. Exception paths describe ways that the use case fails to meet its goal.
Interpretation 1: The use case describes how to produce the report.
In general, use cases are good for describing externally observable actions involved in carrying out some task or process, but use cases are not intended or well-suited for describing business rules, quality factors, database manipulations or computer program logic design. Thus, my initial reaction is that I find it hard to think of producing a report in terms of a use case, and I have no idea how a template would fit in. To me, producing reports mainly involves programming logic to access databases, manipulate data formats and apply business rules. Yes, a program carries out these actions step by step, but I believe I'm safe in saying that most use case authorities would not consider description of program logic to be a use case.
Interpretation 2: The use case describes how to identify what the report's contents and format should be.
A Google search revealed two relevant articles on use cases to design a report or template. Geri Schneider Winters says, "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" (in "Tips for Business Analysts: Use Cases and Reports").
The Sakai Project, discussing documentation requirements for the OSP Report tool, refers to "use cases to determine report parameters, fields and layouts and allow developers to easily create report templates."
Interpretation 3: The use case describes the process to write requirements for a report.
In this instance, the use case would describe steps such as:
- Meet with users to ascertain what needs the report should meet.
- Identify sources of relevant data.
- Define data manipulation and business rules.
- Design the report layout.
- Review the report layout with the users.
- Create a template for producing the report.
- Prototype the report preparation using the template.
- Adjust the template as necessary.
Dig Deeper on Gathering Software Requirements Use Cases
Related Q&A from Robin F. Goldsmith
Using a WBS can help make a big task like requirements easier. Expert Robin Goldsmith explains how developers and testers can make the most of this ... Continue Reading
How do you engage high-level business executives in the process of writing business requirements? Continue Reading
Why don't users seem to appreciate typical software QA testing status reports? Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.