Just a Recommendation…how we Organize our Information Requirements

 

Information is required by business users throughout the industry. However, as part of our consulting engagements, we also encounter a lack of proper description as to what the business user actually needs. 

So, we want to use this article to present the way we structure our information requirements internally at Scalefree as well as the way we do so for many of our customers.

What about User Stories?

We all know user stories from Scrum and many business intelligence projects.
Their structure is typically something that looks like:

As a <type of user>, I want <some goal> so that <some reason>.

The following example represents a typical user story we would receive in a project:

As a <marketing user>, I want <to have an overview report with the number of leads from a marketing channel> so that <I can adjust the marketing budget accordingly>.

Now, what should we do with this user story?
Many details are missing, and yes, we all know about product backlog refinement. The problem is that the user story is just not sufficient enough within business intelligence efforts and some structure might be of help.

Information Requirements

Developers in enterprise data warehousing and business intelligence need much more detail than just the user story. On the other hand, the user story is a good starting point for the information requirement. So, it can be treated as a typical introduction. The overall structure looks like this:

1. User story (introduction)
2. Graphical mockup
3. Detailed explanation
4. List of KPIs
5. List of data sources
6. Test cases

Let’s discuss these sections in more detail below.

Introduction

As already mentioned, this is the user story and a good starting point to introduce the information requirement by the business user. For efficiency’s sake, ensure to state the business value so it is clear to the development team.

Graphical Mockup

Graphical concepts support the clarity of the information requirement. As such, it’s a helpful tool to add another angle to the same requirement. The graphical mockup could be anything such as: 

• a screenshot or printout of the legacy report that needs to be rebuilt
• a spreadsheet mockup that looks like the final report or dashboard
• A drawing in a tool like Microsoft Visio, Lucidchart and the like
• A scribbling on paper

All options have in common that they are as close as possible to the final end product and should include as many details as possible, including graphical aspects, chart options, example values, highlighting, etc.

Detailed Explanation

The next section essentially explains the mockup from the previous section in all relevant details. Refer to the diagram and explain everything that should be included in the final outcome required by the developer to understand the need, the work to be done and the business expectation. Please note that adding references to the mockup diagram might be helpful to better reference details on the diagram.

List of KPIs

Measures and other calculations should be explained in more detail here. Internally, we use a data store where we keep the structures of the KPIs, how they reference each other and all the required details to calculate the measures as well as all the details to understand them: e.g. what is a good trend (upwards, downwards, steady)? Any defined thresholds? Who is the owner of the measure, etc.

In simple cases, a Wiki page per KPI is sufficient. In other cases, you might add them to MDM or any other KPI system.
Know of another method? Leave a comment if you want to point us towards commercial and open source systems to define KPIs.

List of Data Sources

Once the details are established, the important question is: where is the data coming from? To that end, list it in this section. Internally, we have a namespace in our Wiki, where we describe and define our data sources in all relevant details.
If you are interested in this structure, just leave a comment!

If there is any interest, it might be another good blog article. But we are also happy to learn from you, so drop links to interesting examples.

Test Cases

Another important section includes manual test cases for the user acceptance test (UAT). Note, they shouldn’t be hidden except if you want to waste your time in the sprint review meeting. Make them transparent so every team member can test this by themselves.

Maximizing the Value of Information Requirements

This completes the structure of the information requirement, but now, what about maximising the value of it? It’s already great for documenting the requirements of the business user, but we typically go even further. Once the requirements have been completed and the dashboard or report put into production, we also need some user documentation. What we typically do is to turn the information requirement into the user documentation by replacing the graphical mockup by an actual screenshot of the produced artifact and polishing the text.

That maximizes the value from the effort, reduces the overall costs and keeps the document in the most up-to-date fashion in the long term. In case of change requests, we typically create a ticket and update both the dashboard or report and the documentation as part of the “definition of done”.

We hope that helps to clarify a bit of how we like to have information requirements documented. Feel free to share this document with your business users and make sure to leave a comment with your feedback!