Non-Functional Requirements

Like the Functional Requirements, the Non-Functional Requirements (NFRs) - how Power BI operates - are of critical importance. This article covers:

1. Why you need to understand Functional and Non-Functional Requirements from the outset

2. Generic modelling rules

3. NFRs: Performance, Scalability, Security, Maintainability, Reliability, Extendibility and Recovery

---

Why you need to understand Functional and Non-Functional Requirements from the outset

Understanding Functional and Non-Functional Requirements from the offset helps to:

1) Inform architectural decisions

What the BI has to do and how it has to perform fundamentally influences the architecture chosen. For instance, if near real-time reporting is required that is a different modelling architecture than reporting on the last completed day.

2) Set performance benchmarks

It is essential to have an understanding at the beginning and clear measurable goals. Without this you run the risk of reaching the end of a project and users saying it doesn't perform as expected.

3) Provides a basis for estimating effort and cost

If real-time reporting is required for 100,000 users, that's a very different cost structure from daily reports for 1,000 users.

4) Assess the viability of the project

Sub 1 second query time responses over a 50 billion row dataset is going to be very hard to achieve, even with extreme optimisation.

5) Avoid Technical Debt

All BI projects are likely to face some kind of pressure on timelines. As such their is temptation to take shortcuts (particularly with data modelling). But shortcuts lead to technical debt:

Technical debt is where an option is chosen to deliver a more limited (easy) BI solution to meet project timeliness rather than a more complete solution

If you clearly define FR & NFR from the outset, when pressure to do things quicker by taking shortcuts is applied you have an agreed upon minimum standards to refer back to. If it is decided to override these standards, this is done so with the knowledge that a quicker solution will be provided in the short-term, but the likelihood is in the long-term it will cost more in terms of time and resources.

---

---

The Non-Functional Requirements

1) Performance

When we import data into Power BI, we need to concern ourselves with 2 types of performance: Query time & Load time

1a) Query Time

Query time is the time it takes for a visual (or a set of visuals on a page) to load. We can measure this directly through Power BI desktop and run performance checks via DAX studio. Because we can measure precisely how long DAX takes, we can set clear expectations. For instance, calculations explained by less than three factors (such as number of in patients by date, hospital and department) to return in sub 3 seconds.

1b) Load Time

In most cases we import data into Power BI to make use of the engine optimised for query evaluation. This load time is taking the data from source (i.e. SQL, API, Data Lake) into Power BI. It is good to set an expectation for this upfront. For instance, if your SQL is complete at 6am and your users need the data at 8am then NFR for load time is 2 hours. Document carefully when working across time zones or in those where time zones change through the year to Dailylight Savings Time.

Note: Load time and query time are partially correlated and you can trade one off for the other; for instance, certain more complex calculations can be pre-calculated as columns in our data which costs at load time, but is quicker to access at query time.

Scalability

Whilst the model performance may be acceptable today, will it be acceptable tomorrow or the next day? If you're working with data and the organisations is due to grow by 20% in the next 3 months, you need to consider if your model can cope with that increased volume and still meet performance expectations.

Security

Power BI can control security in a number of ways. From a modelling point of view, the key consideration is whether you require Row Level Security (RLS) and/or Object Level Security (OLS) in your model. Both RLS and OLS limit what certain users can see. For instance, you may want to limit the dataset so that when each individual logs in they can only see numbers relating to themselves (such as their sales) and anybody reporting into them (see blog post).

Maintainability

A model which is hard to maintain has high technical debt. If the organisation has someone's role to maintain more complex models, this is acceptable. However, if the model is expected to run without interference for a number of years or months, then that needs to be factored in.

Reliability

The ability to produce reliable results each time the data is queried.

Extendibility

Extendibility largely comes down to the understandability of your model; if you built an overly complex model for the scenario, then extendibility is reduced.

Recoverability

The Power BI model is held in a Model.Bim file (or TMSL script) having a process for backing this up, or storing versions is advisable. Especially as you make changes to the model, you may want to revert back to an earlier version or compare changes between versions using the ALM Toolkit.

---

Conclusion

Before going into modelling, it's good practice to understand both what is required and how Power BI is to operate.