What all Business Analysts ought to know about documenting reporting requirements

See large version of this image

Earlier this week I was asked by a junior Business Analyst, “How do I capture and document reporting requirements?”

As I started to explain the process I realised that it was a skill I had learned on the job. In fact, a quick online search revealed there is no category in the Business Analysis Body of Knowledge (BABOK) or specific business course that teaches the process. It’s little wonder that the documenting of reporting requirements is not well understood and not well executed, especially by inexperienced business analysts.

In this post, I share my ideas and experience to help you take an effective, consistent, and repeatable approach to documenting reporting requirements.

Choose your approach

In my experience, there are three formal approaches to documenting reporting requirements:

1. the structured top-down approach (where everything is completed in sequence, one phase at a time);
 
2. the agile approach (a more flexible approach, where parts of the project are completed organically and concurrently); and
 
3. the use cases approach (which focuses the content on how it is used by different users). 

All have their merits, and for the most part a client will dictate the approach they would like to take; but there are consistent steps across all these approaches that are required to get the information you need.

The 10 essential steps for documenting reporting requirements

1. Identify the stakeholder’s main requirement for the report

I’ve put together a sample project to help illustrate the different parts of what we do: the ‘Portfolio Holdings Report Package’ (refer to image at top). In this example, the Portfolio Advisor wants a report that provides a view of portfolio holdings for one of their customers so they can provide better wealth management advice. This is the ‘stakeholder requirement’ of the report.

2. Research “the art of the possible”

There will no doubt be other reports on record that have similar functional requirements or constraints that may be incorporated in the development side. I always find it best to do some background research before you start the brainstorm process to look at “what is possible”. This way you’re in a better space to advise the client on the best approach to deliver their stakeholder requirement.

3. Brainstorm detailed requirements with business stakeholders

I like to meet with all the stakeholders who will have input or will be affected by the report and brainstorm their requirements, either on a whiteboard or a piece of paper. Brainstorming is a very useful tool as it allows you to gather a lot of information quickly and then prioritise the core components required in the report. There are software programmes that allow you to visually model requirements, such as Enterprise Architect and Visual Paradigm, but I find the manual whiteboard brainstorm is just as effective.

4. Elicit and group the functional reporting requirements from the brainstorm

If we go back to the example diagram at the top of this post, by brainstorming with this client, I’ve been able to determine the functional requirements (what the report must be able to do or provide) of the report are:

• It shall display results in both trade and portfolio currency
• The information must be grouped by asset in alphabetical order
• It must be able to be printed.
• It shall provide a total for each set of grouped assets

5. Determine the non-functional report requirements from the brainstorm

At the same time you’ll be looking for the non-functional requirements (how the report needs to behave, the design constraints etc.)

The non-functional requirements of the report are:

• It must not scroll horizontally when viewed onscreen but can scroll vertically
• It will adhere to corporate branding
• It will take no longer than two seconds to open and view electronically.

When documenting non-functional requirements I tend to follow the acronym ‘URPS’, which stands for usability, reliability, performance and supportability. While this does not cover all the areas of non-functional requirements, it helps ensure you consider some of the core business needs for inclusion in your report.

If you are taking the agile approach ‘user stories’ represent the functional reporting requirements and non-functionals can be represented by acceptance tests on the specific user stories.

6. Identify opportunities for re-use from other reports

At well as preparing the list of functional and non-functional requirements you should also be thinking about candidates for re-use (what can be re-used for future reports).

7. Trace your detailed reporting requirements back to the main stakeholder requirement

In my example, all functional and non-functional requirements trace back to the main stakeholder requirement (this is crucial to be able to justify the detailed requirements by tracing back to the stakeholder requirement).

8. Provide the required detail for the report to be developed

At this point it is a good idea to delve further and think about what additional information you will need before you hand it over to a developer to build. Each of the suggestions listed below has a ‘container’ that can trace back to the Report package.

• In my example one of the functional requirements is to provide a total for each set of grouped assets. It is up to the Business Analyst to define and communicate the best approach to calculate these totals (Flow Logic). This could be calculation instructions that can be captured in text or as a flow diagram.
 
• Data requirements for reports often need to be captured in an Entity Relationship Diagram or Class Model with Attributes (or a good old fashioned list of grouped items, typically called a data dictionary).
 
• You might also need a mapping table to map the captions and labels on the report.
 
• There will also be rules or constraints that need to be applied. The report may provide information that is specific to different audiences. Your stakeholder may not want high-level information accessible by some audiences (e.g. media, public, junior staff) but accessible easily by others (e.g. managers, shareholders).

Note: if you are taking the agile approach you will be completing parts of all of these steps at the same time so that the report can be iteratively pulled together.

View larger version of this image

9. Provide mock-ups to facilitate clear communication

I would usually produce a prototype or mock up either in Microsoft Excel or PowerPoint, Balsamiq or similar wireframing tool and then go through this with the stakeholder. Together you can see if it’s in the format they’re after and if anything is missing.

10. Gain business signoff and hand over to the development team

From this point you should have a robust package to provide to a developer or development team to produce the report.

Get started and add value to your organisation!

Here in New Zealand, and internationally, organisations are collecting more and more digital information. The ability to report that information in ways that add value to the organisation is increasingly important.

Follow these 10 steps to documenting reporting requirements and you should find you achieve this goal effectively and consistently.

Keep in touch and let us know if you would like us to elaborate on how to apply the steps across the different approaches in a future post.

Nick Foard is a Principal Consultant based in Equinox IT's Auckland Office.