Specifying Reports and Dashboards · Business Analysis Notes

Key ideas#

A report is requirements plus design#

For a report, what it contains and how it looks are hard to separate, so Wiegers and Beatty specify both together: the content and its organization (requirements) and the layout (design).

Four questions before you start#

Which reports are used today? They are candidates to carry over.
Which existing reports need changing? This is the chance to fix what users dislike.
Which reports are produced but not used? They are candidates to drop.
Which departmental, company or government standards must reports follow?

Questions for each report#

Context and use: the report’s name; its business purpose and the decisions made with it (not only “what to show” but “what will people do with it”); whether it runs on demand or automatically, and what triggers it; typical and maximum size; whether a dashboard should sit on top of it; where output goes (screen, print, export, archive); security and privacy limits.

Content: data sources and selection criteria; parameters the user can set; calculations; sorting, page breaks and totals; what to show when no data matches; whether the underlying data should be available for ad hoc queries; whether this report could be a template for a family of similar ones.

Six habits of good report analysis#

Offer alternatives, such as sorting, column reordering, or a summary view with drill-down to detail, instead of copying the first request literally.
Find the data sources early. A report request often reveals unknown requirements for collecting or accessing data.
Plan for growth. A layout that works for 10 rows may break at 100, forcing a switch from portrait to landscape or a transposed table.
Look for similarities. Several near-identical requests can often be met by one parameterized report.
Distinguish static from dynamic. A snapshot at a point in time is not the same as a live view.
Prototype. Show a mock-up or a similar existing report, filled with realistic test data.

Dashboards#

A dashboard combines several measures in one consolidated view. Wiegers and Beatty compare it to a trader’s screen: chaos to a newcomer, instantly readable to an expert. Their method extends the report method:

Identify the decisions the user makes with the dashboard. They shape the presentation, not the other way round.
Identify the data source for each element and how often it changes.
Choose a visualization for each data set: table, interactive spreadsheet, text, bar chart, pie chart, line chart, or video.
Decide the layout and the relative size of elements.
Specify each element as a small report, using the same template.

Dashboard-specific questions: how and how often dynamic data refreshes (and whether the time window slides); which parameters, such as date range, the user can change; conditional formatting such as traffic-light colours, always with a non-colour alternative for colour-blind users; whether elements can be enlarged, collapsed or closed; whether personal settings persist between sessions; switching between table and chart; and drill-down to detail.

Arranging sticky notes on a whiteboard is a quick way to prototype dashboard layout before any design work.

How to apply it#

Inventory existing reports with the four questions and decide what to keep, change or drop.
For each report, start from the decision it supports. If nobody can name one, challenge the report.
Fill in the specification template below, skipping what does not apply.
Trace each field to a data source and to your data dictionary.
Test the layout with realistic and large data volumes.
For dashboards, list decisions first, then elements, then layout, then a per-element specification.
Prototype with users before committing to design.

Template#

Template

# Report specification: <report name>

- ID — unique report identifier
- Title — text, position, whether run parameters are shown
- Purpose — business purpose and the decisions made with it
- Priority — relative importance
- Users — user classes who receive or run it
- Data sources — systems, tables or feeds
- Use — static or dynamic; frequency; trigger; recipients; delivery method
- Timeliness — acceptable response time; how fresh the data must be
- Layout — orientation, page size, chart settings
- Header and footer — page numbers, run timestamp, data source, date range, notes on exclusions, confidentiality marking, branding
- Body — selection criteria, fields, headings and number formats, overflow handling, calculations, sort, filter, grouping and subtotals, page breaks
- End of report — marker or summary line
- Interactivity — drill-down, links to related reports, saved parameters
- Security — who may run or see it, and any row- or field-level limits

Example#

At The Workshop (a fictional bike-repair chain), the owner asks for “a report of all repairs”. The analyst asks what decision it supports. The answer: each Monday the owner decides where to move mechanics between workshops. That turns the request into a weekly workload report: open repairs per workshop, grouped by status, with average days waiting for parts, run automatically every Monday at 07:00 and emailed to the owner and workshop managers. Workshops with more than a set number of repairs waiting for parts are highlighted, using both colour and a symbol.

Workshop managers then ask for a dashboard. Their decision is daily: which repairs to chase today. The analyst lays out sticky notes for three elements (repairs due today, parts overdue from the supplier, repairs ready but not collected), agrees the arrangement with two managers, and specifies each element as a mini-report.

Sources and further reading#

K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013, ch. 13 (report specifications; dashboards).