Non-Functional Requirements (NFR for SaaS) are those requirements that cut across the application functionality, spanning across all the modules and features. These requirements go deep in to the architecture of an application, which is where they get addressed. Hence, it’s important to understand these NFR for a given application right before the SaaS architecture phase, so that the application design can address these requirements.

The very nature of SaaS model makes certain set of NFR critical for its operation. Let’s see the top 10 critical NFR for SaaS applications and the reasons behind them.

Critical NFR for SaaS Applications

Scalability:

SaaS is being an on-demand business model, it’s extremely difficult to predict the load on the system. At the same time, you cannot plan for a peak load scenario as that will consume high levels of cost and resulting in inefficient use of resources. Therefore, the application should be designed to dynamically scale up and scale down based on the real-time load on the system. This is where SaaS architects will have to leverage the cloud model to take advantage of the on-demand resource consumption model.

Performance:

With the constant increase in internet speed and bandwidth availability customers expect lighting response from internet based applications. SaaS customers are going to expect the same, regardless of the type of application or the volume of processing that happens behind the screens. Therefore, architects will have to consciously take in to considerations the potential performance bottlenecks and implement designs that can help leverage concepts like asynchronous processing, micro services architecture, multi-data availability, etc.

Availability:

Probably the most important of all the NFR. The SaaS application has to be available in the first place for other NFR to come in to play. Availability of the SaaS application is the biggest concern, particularly if the application addresses a business critical solution. Unplanned downtime of SaaS applications can lead to heavy loss for Customers, and consequently can ruin the SaaS provider’s business. Architects will have to understand the SLA that is targeted and design the deployment model in such a way that there is no single point of failure. They should also consider Recovery Time Objective (RTO), Recovery Point Objective (RPO) factors while designing their DR strategy.

Integration:

We are living in a highly connected world today, and this is only going to increase in the coming years. Customers are very particular about choosing a SaaS application that not only addresses the expected features but also its ability to gel well with the existing setup at the customer’s end. This leads to a situation where the SaaS application will have to talk to a disparate set of internal and external systems. Architects will have to design the SaaS application as an open system with sufficient hooks so that integration is not only feasible but also can be completed with minimal effort.

Auditing:

From a SaaS provider perspective, the ownership of the system and its functioning is with the provider. Therefore, it’s the responsibility of the SaaS provider to implement the appropriate measures to track the usage of the system and the events happening within it. This information will be critical for both diagnosis purposes as well as resolving conflicts with customers. Auditing design should ensure that all the user and system actions are thoroughly recorded and stored properly so that it’s to trace and identify the exact sequence of events that happened in the system. It’s also important to store the data change (old data vs. new data) along with the timestamp and user details that induced the change.

We will see the next 5 critical NFR for SaaS applications in my next blog.