Trade-offs are not easy. Not especially if it is over choosing the optimal features and functions when developing an application. Which often happens because it is unclear for developers what criteria they should use to make design decisions and why.
To build an architecture optimised for achieving the business goals without losing the sight from future, a small criteria should be taken care of, this is where the NFR comes in to picture.
Non-Functional requirements “NFRs” are key ingredients behind the success of a product. They generally specify the quality attribute of a software system. Although super important, they can easily be missed in the trade offs. This article helps you understand what are NFRs, their importance, and at what stage these should be agreed with the client.
Functional requirements capture what the system should or should not do while the NFR captures the “how” part. In case the system does not meet the NFRs expectation it still performs the basic purpose.
Let’s understand this in a very simple way - you click on a search result on Google the functional part is that you should see the page once it's loaded, however, the non-functional part can be how fast it loads.
NFRs are decided and agreed as per the project requirements. There can be a long list that we can discuss, however, in this article we will be talking about few important ones:
Scalability is a measure of a system being able to appropriately handle the increase/decrease in workloads. When a product is built two questions are important from a scalability point of view (a.) How many users will be using my product? (b.) How many concurrent users will I have? Having some indicative figure around the users helps in designing a better system.
Once the initial questions are answered the next question will be to decide on the scaling strategy: horizontal or vertical scaling? Summarising, due thought should be given around scaling as it can lead to a showdown where your site might not be able to handle the workload and crash.
Key Success Metrics: Total Users, Concurrent users, Time taken to scale
Performance
The performance of a software architecture is majorly measured around the response time and throughput. Faster the response time with qualitative and high throughput, better is the performance.
However, there are factors related to acceptable latency that need to be factored in as well. Latency is the acceptable slowness in response time which does not go beyond agreed limits.
The system might run smooth on one set of load, however, on increasing the load the performance parameters might go south.
To ensure high performance of the system clear benchmarks around the performance metrics should be captured during the requirement gathering phase. With the requirement in place the application should be designed keeping scalability options in mind to avoid performance bottlenecks due to any sort of resource constraints.
Key Success Metrics: Response Time, Throughput
High Availability
High Availability means ensuring the availability of your application at all times 365dX24h. It's basically a percentage to reflect the UpTime of an application.
A well thought through architecture is at the core of this non-functional requirement. For example, Amazon provides several built-in capabilities (mentioned below) to achieve high availability. These capabilities can also be viewed in digarm referenced below:
Elastic Load Balancing
Availability Zones
Auto Scaling
Key Success Metrics: UpTime is the only metrics - no compromise here
Consider a case where you have kickstarted a fixed bid project to develop an iOS app for a client. All the bells and whistles had been discussed around the features but what went missing were the NFRs.
The app development ran smooth, however, during the UAT (User Acceptance Testing) phase there was a version upgrade and the mobile app started acting randomly for some features. The client does not like this and wants you to fix (obviously does not want to pay) while you believe this is a Change Request as the case related to version upgrade was neither captured nor estimated in.
So why did such a thing happen in the first place?
Clearly no alignments were made with the client around the version upgrade during the discovery phase of the project. So, now what happens is 9.9/10 times the duration of development exceeds the original estimates leading to a conflict between the client and the delivery team about who should absorb the extra costs
Above is a very simple example which showcases the importance of agreeing upon the NFRs.These requirements when handled well avoids any loss to business, users interest and credibility.
Capturing NFRs should be religiously followed during the discovery stage of the project. The business analyst on the project should ask all the relevant questions which might otherwise be missed because the client isn’t aware or thinks that these are obvious things which will get captured and delivered.
The collated NFRs should be shared with all the stakeholders from the client’s end. These could be stakeholders responsible for design, performance, security, accessibility to mention a few. However, the business analyst should ensure that a due agreement on NFRs is reached before the kick-start of the development phase.
Strategizing the involvement and management of NFRs right ahead of the projects brings clarity for both the parties. The timely estimates and consideration enable timely and successful delivery of your projects without the additional overdue costs. Overall, NFRs contribute to the strengthening the pillars of successful project delivery.