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, 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’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.

The post Are you forgetting to include Nonfunctional Requirements (NFRs) in planning? appeared first on Pyramid Solutions.