Skip to main content

Coding a feature without considering nonfunctional requirements is like writing lyrics without considering rhythm.

A product must be built with both functional and nonfunctional requirements, however, nonfunctional requirements (NFRs) are often blindsided while functional requirements get the most focus. It’s because NFRs are usually dealt with an ad-hoc strategy. This may not lead to problems in small projects if there’s clarity over the whole system. But in the case of large projects, ignoring of NFRs can bring unwelcomed problems.

“Because we are not putting the investment up front into gathering business requirements and building strong product backlogs, we are running into ‘gotcha’ moments that delay the product.”

- 2018 Global Developer Report (GitLab)

Capturing NFRs is one of the biggest challenges. You can address it by dedicating more time to analyze all the environments in which a user interacts with the product. It usually helps in gathering meaningful and objective insights to improve the product and achieve business goals.

Facebook has set an example in improving the product with NFRs drawn from user insights. The developers were given tools and devices to analyze their app using 2G cellular networks. Testing their app for a range of mobile internet bandwidth has helped deliver performance in countries where internet connection varies widely. This effort was crucial for Facebook's ambition to expand all over the world.

If gathering insights for product improvements is difficult for you, user feedback is an option. Microsoft came to know that a lot of user feedback came in to implement new features that were already present in their applications. They made such features more visible to the user thereby increasing product usage.

Another underlying issue is the lack of consensus on how NFRs should be outlined, integrated, and tested in the software development process. Even when after gathering the right NFRs, they are not elicited properly. It has become common to write NFRs that reflect the industry standards; however, it may not be good enough for user experience.

Take the example of e-commerce websites. Due to high competition and user expectations, e-commerce websites are advised to have the lowest possible page load times. So, a typical NFR for an e-commerce website written using the industry standards can be:

 The homepage must load under 3 secs. 

 Though it is a valid requirement, it doesn’t address all the requirements such as:

  • Is 3 secs load time acceptable for 10 users or 1000 users?
  • Where should it be measured? At the web server or at the client browser?
  • What should be the Time To Interact (TTI)?

We can write a better NFR after analyzing such questions:

The homepage must load under 3 secs 95% of the time, with a maximum rendering time of 5 seconds measured at the client browser when 10,000  users access the homepage over a 1-hour period.

Though there may not be a foolproof NFR, it’s better to write the requirements detailed enough to remove any ambiguity as much as you can.

NFR isn’t ‘Done’ until it’s tested and NFR testing should be a continuous process built with automation. Monitoring the system will allow you to know how to be more productive in delivering quality. Industry leaders are highly process-oriented who collect tons of data to analyze the time to fix bugs. It helps them to reduce the testing time in less than 8 hours.

However, having sound quality assurance with NFRs can be challenging. A root cause is the scope of requirement specifications itself. There can be subjective biases and misunderstanding while interpreting the requirements for nonfunctional testing.

Another issue is when QA consists of a narrow scope of testing nonfunctional requirements. Say, in the name of performance testing, only load testing metrics of individual web pages and components are analyzed or when fault tolerance of a system is related only to high availability and scalability.

NFRs are systemwide attributes and thus apply to many or all of the functional requirements. The user insights drive the identification of requirements and are not limited by industry standards. Capturing NFRs is only a part of the overall process; they should be outlined with clarity and objectivity; then tested and monitored continuously for optimization of delivery.

At Pyramid Consulting, we ensure software goes through exhaustive quality checks. This is possible due to our expert team, collaboration and by following best practices for QA. Pyramid Consulting’s testing solutions help in optimizing your projects to deliver a quality user experience at speed. Contact us to see how we can help you.

Vikas Shukla

About the author

Vikas Shukla

An agile and customer focused professional, Vikas has been Pyramid Consulting's Director of Quality Assurance since 2009. Vikas manages a team of 90+ QA professionals and leads our QA Center of Excellence.

Cookie Notice

This site uses cookies to provide you with a more responsive and personalized service. By using this site you agree to our privacy policy & the use of cookies. Please read our privacy policy for more information on the cookies we use and how to delete or block them. More info

Back to top