Non-Functional Requirements (NFR) are those requirements that cut across the software functionality, spanning across all the modules and features. These requirements go deep in to the architecture of an software, which is where they get addressed. Hence, it’s important to understand these NFR for a given software right before the architecture phase, so that the design can address these requirements.
Let’s see the top 10 critical NFR for SaaS applications and the reasons behind them.
In 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 software should be designed to dynamically scale up and scale down based on the real-time load on the system. This is where software architects will have to leverage the cloud model to take advantage of the on-demand resource consumption model.
With the constant increase in internet speed and bandwidth availability there is a general tendency to expect speedy response from internet based applications. Software users 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.
Probably the most important of all the NFR. The software has to be available (online) in the first place for other NFR to come in to play. Availability of the software is the biggest concern, particularly if the software addresses a business critical solution. Unplanned downtime of software can lead to heavy loss for Customers, and consequently can ruin the software 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.
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 software 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 software will have to talk to a disparate set of internal and external systems. Architects will have to design the software as an open system with sufficient hooks so that integration is not only feasible but also can be completed with minimal effort.
From a Software provider perspective, the ownership of the system and its functioning is with the provider. Therefore, it’s the responsibility of the software 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 easy 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 in Software Architecture in my next blog.
Latest posts by Janakiraman Jayachandran (see all)
- Top 10 Critical NFR for SaaS Applications – Part 2 - May 26, 2016
- Top 10 NFR in Software Architecture – Part 1 - April 29, 2016
- Mobiles Devices on the cloud - August 7, 2015