NFRs, or Non-Functional Requirements, refer to how something works, rather than its actual functionality. Typically NFRs relate to the performance, reliability, and security requirements of a design. For example, an NFR might state must processes 2 million transactions in less than 30 seconds.

The MHHS (Market-wide Half-Hourly Settlement) Programme specifies lots of NFRs that solution designers like Flui pay very close attention to as part of our internal technical design work. As standard, NFRs are approached with as much importance as main functional requirements, because it doesn’t matter how perfectly something works – if it can’t perform required tasks in a secure manner in a timescale that our clients need, then we aren’t meeting all requirements.

You can try retrofit performance and reliability to a solution, but that will usually lead to compromise and limitations which doesn’t fit in with our criteria for a flexible and agile solution. A deep understanding of the NFRs of the overall solution, and of each individual component, is critical for the correct architecture design and the optimal program performance. By flowing (and testing) these requirements down to a low granular level, performance is built-in from the ground-up in each and every line of code, component, assembly, function and solution.

A bit like catching bugs at the earliest stage possible will minimise the rework, engineering NFRs at the earliest stage possible will deliver an optimally performing solution. This eliminates the need for retrofitting changes or incurring the cost and inefficiency of additional compute capacity.

We know this to be true because we have been building secure, high-performance solutions to handle half-hourly data for more than 10 years now. Paying attention to NFRs for time-series data with complex processing requirements is critical for the success of any solution in the MHHS world, particularly any solutions that operate as a gateway to the industry, which is our core market here at Flui.