Requirements for reports

Requirements are not all the same. Functionality can be captured with e.g. user stories or use cases, but these techniques are less suited to some other aspects such as quality and constraints. One area that seems to get little attention is reports. How do you collect report requirements? And what is a good way of specifying them concisely and clearly?

How do I start collecting requirements for a report?
Stakeholders may want lots of different reports, and it seems new report types are needed on demand. Before you know it, you’ll be spending huge amounts of time writing requirements for those reports. That is not neccessary: determine which reports are the most import ones and do those first. After you’ve done those, re-evaluate: how many more reports must be specified, if any?

To figure out which reports are most import, apply DAD. DAD stands for Decision-Actor-Data and is a simple reminder of the logical order to collect relevant information for report requirements.

  1. Decision: The key to good report requirements is to start by figuring out which decision or action the report supports. What needs to happen based on the report? “To be informed” is not a valid answer. Either something tangible or practical happens because of the report, or you don’t need it.
  2. Actor: The next element to pursue is the actor. Who is going to make that decision or take that action? In practice, the decision and the actor are closely related, so they are elicited at almost the same time. Often an actor will be a stakeholder in the project and say ‘I need this information in this format!’ Your job is to focus them on the decision, and then ask who else might make similar or related decisions. You can find other decision-actor pairings by looking at the processes that are triggered by the report, or the processes for which the report is an outcome.
  3. Data: At first you should ignore most data elements and all presentation and formatting. Only after you have determined the decision-actor pairings should you start to figure out the categories of data that the actors need for their decision-making.  Usually it is sufficient to list the categories of data (e.g. ‘customer address data’, ‘monthly invoice totals’ etc.) and leave the details to a later stage (e.g. during design).
Which details must I capture?
When determining what is needed for a particular report, I typically use the following questions:
  1. When (e.g. ‘after process step X’) or how often (e.g. monthly) is the report needed?
  2. Is the information in the report sorted? If so, by what? Ascending or descending?
  3. Is the information in the report filtered or selected? If so, how? Can the user choose the selection?
  4. Does the report have a header? If so, which information should be displayed there?
  5. Does the report have a footer? If so, which information should be displayed there?
  6. Is the information in the report body grouped or aggregated? If so, how? Are any calculations needed?
  7. How much data (e.g. pages, records, rows) does the report typically contain? How quickly must it be produced: within seconds, minutes or hours?
  8. Confidentiality level of the data
Remember, you don’t have to get this information for all of the reports. Do the most import ones, and if you’ve noticed a few unusual actor-decision pairs you may want to spend a bit of time to investigate those reports too. These unusual reports may lead you to different categories of data that the system must process. For the other reports, you can probably get away with a generic statement like “The system shall provide 20 simple reports similar to report A and 5 complex reports similar to report B.” You can then work out these reports at a later date. Another option is to consider a ‘report generator’ functionality.
How do I write the requirements concisely and clearly?
For those reports that you have worked out in detail, you’ll have collected quite a bit of information. It can be tricky to write it all down in an understandable and coherent way. I’ve seen people try to specify a report with lists of “shall-statements”, and it is not pretty! Of course, there is no 1-size-fits-all solution for this. The presentation of requirements depends largely on the audience: the stakeholders and designers or suppliers. They can have very different preferences. An approach which has worked for me is to combine a tabular format for DAD and virtual windows for the layout.
Here is a partial example of the tabular format for a report requirement:
Requirement Id 1234
Why (Decision or action supported) Check which patients may be contaminated by a specific outbreak, for containment purposes.
Used by (Actor) Ward Nurse
When / how often Infrequent. Only if a suspected outbreak of a dangerous contagious disease is being investigated.
User selection Patient Id
Which data
Section 1: List of wards + dates
Section 2: For each ward: list of Patient Name  & Contact details
Sorted by Section 1 sorted by date
Section 2 sorted by date
Grouped by n/a
Filtered by Section 1: Show only data for the selected patient (i.e. the infected patient)
Section 2: Show only data for patients who were in the specified ward at the specified date (i.e. who were in the same ward as the infected patient).
Limits Maximum ward size is 50 patients.
Available within Max. 5 minutes
Note that in the above example I’ve left out most attributes of the requirement itself, such as owner, submitter, status and priority.
And below is a partial example of virtual windows to go with it; it shows the header, section 1 and part of section 2.
Conclusion
When collection requirements for reports, first focus on the decision which the report supports, and the actor(s) that use it. Only after you’ve verified that the report is relevant should you start to collect data requirements for the report. A combination of a tabular format with a virtual window may be a good way of presenting the requirements to stakeholders and designers.
What are your tips for collecting and presenting requirements for reports? I’d love to hear!
Advertisements

Tags: , , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: