Information Technology Reference
In-Depth Information
the reader should pay attention. For example, in a trend report, shown
as a graph or in a tabular form, red or green arrows pointing upward or
downward can show gradients along with the numbers.
Reports, for the most part, should be
. There should
not be confusion about the usage of terms in it. For example, if a report
lists “the number of employees,” it should be clear whether this number
also includes part-time employees or contractors. Footnotes come in handy
when such clarity is needed.
One of the design decisions that should be taken is the split between
reports and queries — which of the information requirements of the user
should be formalized as reports and which should be left to queries? Note
that reports can be run on-demand; that does not make them queries. By
the same token, queries can be scheduled; that does not make them
reports. There is a section on queries later in this chapter. One of the key
factors in helping to decide is based on what we have already said —
that reports must be problem-solving tools. They are not data retrieval
mechanisms. Retrieved data dumped on the screen or paper does not
constitute a report. If one knows the problem that the user is tackling,
knows how the system can generate information to help solve it, and
knows how to represent and organize that information in a way that
supports that problem-solving process, then one has a report.
self-explanatory
Quality
It is important to proofread reports. Developers tend to submit code for
creating a report without a full check of the output to confirm that it is
doing what it is intended to do.
Apply the following report proofreading checklist:
Does the report match the original intent for which it was created?
Is it comprehensive enough for its audience?
Is all the included information relevant? Remember that less is
more as long as the data is the same.
Is the style clear and concise, and is the layout quickly readable?
Are the conclusions based on a true interpretation, and are the
analyses of the data presented later on in the same report?
Are your recommendations reasonable?
Very important: have the spelling and grammar been checked?
Doing QA (quality assurance) on reports presents its own set of
challenges, which differ from those for testing the main body of the
application. Most of the problems deal with data. The hurdles include:
