Non-Functional Requirements - The secret sauce of a successful project delivery

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. 

Difference between Functional and Non-Functional Requirements

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.

Different Types of Non-Functional Requirements

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

  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

• Security
  This NFR deals with the security of the user data captured by the applications against any breach. The hackers exploit the vulnerabilities in the system leading to data theft.
  
  Following the Top 10 commandments of OWASP foundation could be the basic foundation of security first culture for your application and organisation.
  
  Thorough security testing is a strong deterrent against any open vulnerabilities. Various tools like Burpsuite, Qualys etc. can be used for covering on this front.
  
  Key Success Metrics: A GREEN Security Scan Report
• Localization
  This NFR deals with how the application aligns itself with the local language, laws and other aspects. Some examples that fall under this category are like the Right to left screen display for Arabic language, Date formats in specific geography etc.
  
  It’s an often overlooked requirement, however, adhering to can have lasting effects on the way users perceive the product. Data Sovereignty is a key consideration in modern applications.
  
  Key Success Metrics: Adhering to all identified parameters captured via thorough market research
• Accessibility
  This NFR makes sure that the Web Content Accessibility Guidelines (WCAG) are duly followed so as to make the web content accessible to people with disabilities. Accessibility involves a wide range of disabilities, including visual, auditory, physical, speech, cognitive etc.
  
  Key Success Metrics: GREEN Signal post testing ensuring the application is Operable, Perceivable, Robust, Understandable. More details can be found on ADA.Gov

Avoid any loss to business and users interest

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.

The right stage to capture NFRs

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.

Who should the NFRs be agreed upon with?

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.