What are Report Requirements?

What is...R Nov 17, 2018 4 mins 62588 Views 0 Comments 9 Likes

A user of almost any given software system or business application will require precise analytics in order to objectively measure its effectiveness, or the effectiveness of an associated product. These analytics –or reports—therefore, must measure the right criteria at the right time(s) in the right way in order to be useful to the user. For that reason, any newly proposed reporting function requires careful, measured, thoughtful and thoroughly vetted requirements in order to ensure its efficacy.

Wikipedia notes that report specifications “define the purpose of a report, its justification, attributes and columns, owners and runtime parameters.”¹ That is certainly true, but in fact, report specifications must do a lot more than that. In the course of creating strong general reporting requirements for any given system, an analyst must consider the following:

The report’s purpose. What is the purpose of this report? How do we expect the end user to use it? (An analyst will naturally want to verify these assumptions with a sampling of end users themselves.)

Industry standards. Any industry standards (according to ANSI or IEEE, for example) that are relevant to your field or the business application must be considered in conjunction with the business owner for their appropriateness of inclusion in the report. In most industries, a report is useless if it compares apples to oranges across applications or vendors. The purpose of an industry standard is to ensure that any report within a given profession always compares apples to apples, and therefore the information will remain relevant (and coherent) to the user.

User expectations. This is a broad area of consideration, encompassing a lot of potential costs and risks. Because of the vast difference in time and budget concerns that including some of these options may present, it may be most useful to get the business owners, developers, and database engineers in one meeting (or multiple meetings!) to explore what is most time-consuming, what is most feasible, and what is simply out of reach.

Will different types of users have different sets of expectations about how to use this report, or what it should contain? If so, do we need more than one report, or is a highly customizable report more feasible?
What types of rows and fields will the user expect to be included in this report? Are there industry standards that designate what rows and fields must be included? How will we determine if these are also relevant to our users? (Note that you may require a separate meeting just for field considerations. Some fields that users or business owners want may be readily available for inclusion, while others may require complex calculations to generate, thus slowing down the report creation time [and development time] of the report. In these cases, the business benefit must be weighed against the risk of the inclusion of complex fields.)
Can the user choose to exclude select rows and fields from the report? (And if they do so, will all of their data for those rows and fields be stored in the database in case they want to return to the default settings?) Also, can the customized versions of the report be saved? If so, does the user have a limit on how many?
What types of sorting and filtering capabilities will the user expect?
Will the standard report data need to have drill-down capabilities to reveal more granular data? If so, what should that drill-down data look like?
How often will the user want to run this report?
What are the user’s expectations regarding how long this report takes to run?
Should the report have the ability to be customized to run automatically at set intervals (i.e., the user automatically gets the report delivered to their inbox every Tuesday, or every April 15, etc).
What formats should the report be available in (Excel, XML, etc.)? Should the report data be available for display in pie charts, graphs, and so on, or is the data too intricate or the development time-prohibitive?
What are the expected delivery methods for the report (pre-generated and sent via email, displaying on the fly in a real-time web page, etc)?
Should the report be customizable (i.e., can the user remove fields, or create their own custom fields? Note that custom fields are not quantifiable by a system, but the inclusion of a custom field, such as a note field, is useful for many users in a report.)
What are the user’s expectations regarding the currency of the data? Will they expect it to be data that has been refreshed in the same day? The same week? That very second? This option may determine the difference between “canned” or cached data (relatively easy for engineers to implement) and data that is calculated on the fly (which may require much more complex calculations to implement).
What are the user’s expectations regarding the branding and appearance of the report? How polished should it look? Is a basic Excel spreadsheet acceptable to all, or is something more elaborate the expectation, such as a real-time graphical web page complete with colors, graphics, and company logo?

This is only a fraction of the options that the user may need or want. (For example, a user in Finland might appreciate having the report data translated into his native language. Every option is virtually impossible to anticipate without vetting users.) However, the above options cover many of the basics an analyst will want to consider. If any of the above options are deemed inappropriate for inclusion in your project, it may be prudent to put them in an Exclusions section of your requirements document, thus creating a record that notes that the option was considered and the reason for leaving it on the table.

Unique Identifiers. Within a report, each field (or data element) must be assigned a unique identifier in order for calculations to occur in the background. With fields that the user can edit, it is particularly important that any identifier assigned to the data element remain static in the background. (For example, if a field is given the default name “Cost” and the user changes it to “Expense”, the system must know that the field A1 is really pulling the cost from the database, no matter what the user names it.) Most engineers will likely appreciate the inclusion of an appendix of unique identifiers (alphanumeric or otherwise) assigned to each data element within your requirements. Before beginning your appendix, consult with the engineers to see if they have any ideas regarding what types of identifiers would make the most sense or be easiest to program.

The design of the report function.Too often, the following critical elements of the report design are overlooked during the requirements gathering phase. So be sure to consider:

Report title. The title should give a pithy and accurate picture of the report’s purpose and goal; i.e., “Widget System User Log-ins for September,” so that any viewers of the report will understand its objective at a glance.

Report header. Consider including relevant primary metadata such as a timestamp for the report’s generation and the user who generated it.

Report footer. Consider including relevant secondary metadata such as the report’s version number and page number count (i.e., page 3 of 12).=

Report filter criteria. Whatever filter criteria the report offers, the options that the user has selected should be readily apparent to the viewer. Date ranges, data ranges—are the filters clear? In other words, if the data range is specified to only show user log-ins that lasted an hour or greater, is that quickly clear in the report filter criteria so that the user isn’t confused into thinking that all user log-ins lasted an hour or greater?

Formatting. Consider whether certain data (such as accounts past due, data that is missing, balances below zero, and so on) should always be highlighted or stand out with bold, italic, or a color to draw the user’s attention.

The design of the report look. It is helpful to most stakeholders (especially software engineers and the database engineers) to include in your requirements an appendix of a template or templates of what the finished report might look like (even if the data included is not realistic). Of course you will want to run the report template by the business owners, and use appropriate vetting tools from the analyst’s arsenal such as surveys and focus groups to ensure that what the report developers build will be useful to the end user.

As you consider the report look, consider its primary users. If its main audience will be executives, marketing staff, or customers, then charts, graphs, and other user-friendly options could be an appropriate look. If its primary users will be accounting or engineers, more granular data will be needed.

Regardless of what features and fields are included or are not included, what makes a report successful is its precision and relevance. Do the research to be sure that the report provides those qualities for users, and your project will be a success.

¹ http://en.wikipedia.org/wiki/Business_analyst