Why Your Software Works but Your Users Hate It: The Missing NFR Guide

Picture this: You’re starting a brand new project, only to realise halfway through there’s been severe miscommunication between different teams, and the rest is history. Knowing the challenges you might face, you know that clear requirements help you manage expectations and ensure your project meets its objectives. And that is exactly what the Non-functional Requirements SRS Template is for.

Functional requirements define what the software does, and non-functional requirements (NFRs) define how the system should do it. Failing to define NFRs leads to software that works but frustrates users due to being slow, unstable, etc. Oftentimes, it’s hard to document NFR’s because the qualities like reliability are harder to measure. 

To ensure that your requirements will be defined clearly, this guide will walk you through the key differences between functional and non-functional requirements, what software requirements specification document is, a detailed breakdown for an SRS for NFRs, best practices for NFR’s, and a SRS templated optimized for non-functional needs. 

What are Non-Functional Requirements (NFRs)?

In software engineering, non-functional requirements (NFRs), also known as quality attributes, describe the system’s operational capabilities. Essentially, the requirements of how the system operates, which includes speed, data integrity, security, and more.  

For example, an NFR could be defining that a website should load within less than 5 seconds (speed), users must change their initial password after logging in for the first time (security), or be able to handle more than a thousand users without having any issues with performance. 

Let’s look at some of the types of non-functional requirements:

• Performance: Related to speed and responsiveness. How fast does the system return results?
• Security: Deals with safety. Is the system protected against attacks?
• Usability: Is it easy to use the product?
• Availability: The system’s ability to perform its function. How long is the system downtime?
• Reliability: Stability of the system. Does the system frequently experience critical failures? 
• Scalability: The system’s ability to handle growth. Will the performance change as the workload increases?
• Maintainability: Deals with the ease of updates and fixes. How much time is spent fixing an issue when it pops up?
• Compatibility: Is the system compatible with other processes?
• Portability: The ability to run in different environments. What hardware, browsers, and operating systems (with their respective versions) does the software run on?

Functional vs Non-Functional Requirements 

Although both non-functional and functional requirements have specific characteristics that the software needs to meet, there are differences. 

Functional requirements, on the other hand, focus on what the software should do, i.e., the features and functions. For instance, when certain conditions are met, a new user will be automatically sent an email by the system, or only certain employees above a certain level can see the salary data. Some other examples are login authentication, business rules, external interfaces, transaction processing, and so on. 

Aspect	Functional Requirements	Non-Functional Requirements
Objective	Outlines what the product should do, like exact tasks or operations	How the product should perform, the attributes like speed or usability
Measurement	Easily measured by verifying outputs	Harder to measure, need to validate against metrics
User Perspective	Tied to user requirements	Shapes the user expectations
Essentially	Mandatory	Not mandatory but desirable
Origin type	Usually defined by the user	Defined by developers or other tech experts
Evaluation	Functional testing like unit or integration tests. Done before nonfunctional testing	Verified by performance, usability or security testing. Tested after functional testing
Types	Authentication, authorization levels, data processing, reporting, etc.	Usability, reliability, scalability, performance, etc.
End result	Focus on product behavior and features	Focus on product properties

What is an SRS Document?

A Software Requirements Specification (SRS) document is where how the system should perform and interact is listed. It acts like a guide of sorts for a development team as it outlines the purpose and functionality of a software. From business owners to clients and developers, each member plays a role in producing and using the SRS.

A well-constructed SRS document provides a clear direction to everyone involved in the development process. Though it is time-consuming, the effort pays off. The more your team understands the product and its requirements, the faster your product will be completed. 

Some of the benefits of using an SRS document are: 

• Sets clear well-defined expectations 
• Increases clarity by using controlled language 
• Ensures that all features are tested 
• Reduces scope creep by addressing problems from the get-go
• Traceable requirements help to meet compliance standards 

Template Structure 

The structure provided aligns with the IEEE 830 and ISO/IEC/IEEE 29148:2011/2017 standard with some minor changes. Though the outline of the SRS varies, the structure will typically look something like this:

1. Introduction

1.1 Purpose 

1.2 Document Conventions

1.3 Project Scope 

1.4 References

1. Overall Description

2.1 Product Context

2.2 Product Functions 

2.3 Product Constraints

2.4 User Characteristics

2.5 Assumptions and Dependencies 

1. Functional Requirements

3.1 “System Feature 1”

Description and Priority	Response Sequence	Functional Requirement

3.2 “System Feature 2” (and so on)

1. Non-Functional Requirements 

4.1 Performance 

4.2 Security 

4.3 Usability (and so on)

1. External Interface Requirements 

5.1 Software Interfaces

5.2 Hardware Interfaces

5.3 Communications Interfaces

5.4 User Interfaces

1. Quality of Service

6.1 Reliability

6.2 Usability 

6.3 Availability (and so on)

1. Verification

Requirement ID	Verification Method	Test Link	Status	Evidence

1. Appendixes

Appendix A: Glossary

Appendix B: Other Materials

The Non-Functional Requirement SRS Template Structure – Section by Section 

As seen in the general SRS template, there will be dedicated sections for every major quality attribute. Before starting to write the NFRs, make sure you have already defined the product scope and user characteristics. 

Performance Requirements 

Performance focuses on the speed and efficiency of the product – how quickly can the system (or components) process the user’s request and respond accordingly. Users tend to feel frustrated with low response rates, which then leads to a high bounce rate. 

Examples: 

• The system must respond to the user’s queries within 1.3 seconds 
• When typing the query in the input box, the latency should not be more than 500 ms.
• The landing page supporting 7,000 users per hour must provide 5-seconds or less response time on a desktop browser 

Security Requirements 

Security focuses on how the system should protect sensitive data from security threats, breaches or from unauthorized access. Includes using authentication and encryption mechanisms to protect the data.

Example: Users must use two-factor authentication (2FA) to log in.

Usability Requirements 

Usability is about the ease at which users can interact with the product. A high usability implies that users can use the product with minimal training which improves user experience. 

Example: For a food delivery app, all major actions like add to cart, reorder, etc) need to be accessible in 2 taps or less on mobile. 

Availability Requirements 

This describes the time the product should be accessible by users. The higher the better, as it reduces downtime and improves trust. For some companies even a few minutes of downtime can result in significant loss of money, reputation and end users. 

Example: The online payment portal should be available 99.9%, and could have a downtime of 30-40 minutes between 1-2AM for maintenance.  

Reliability Requirements 

Reliability assesses how often the system can run without failing for a given period of time under predefined conditions. Especially critical for everyday applications like banking and healthcare systems.

Examples: If system crashes, it should roll back the latest deployment for recovery.

Scalability Requirements 

This aspect refers to the system’s capacity to perform well as growth increases in terms of data volume or user load. When there is a rise in users or processing requests, the system should be able to scale and meet the demands without needing a system rebuild. This is important because during peak traffic, you risk your product crashing if it cannot handle the load.

Examples: 

• During a seasonal event sale, an e-commerce store must handle 7-8x normal traffic while maintaining optimal performance.
• The real-time locating system should scale from managing 5,000 to 100,000 IoT devices without data loss or monitoring.
• The ERP system should be able to scale data processing as the business grows to handle over 1 million active users.

Maintainability Requirements 

Defines how quickly the system can be updated/fixed – also covers the time and resources required to maintain the system. Important in large scale projects or projects with constant improvement.

Example: The new version should be deployed without affecting active user sessions.

Compatibility Requirements 

This aspect describes how well a system can exist and work with other systems, software, or hardware. This is crucial in environments where the system has to connect with third-party services, browsers, APIs, and databases. A lack of compatibility can result in broken features, integration issues, data loss, and performance errors. 

Examples:

• A project management tool should integrate with platforms like Google Calendar, Slack etc without any manual input from users. 
• Banking software should be compatible with financial data formats like CSV and QIF to import/export data. 
• A video conference application should be compatible with most webcams, speakers, and microphones. 

Portability Requirements 

This is about how easily the system can work with different environments, including browsers, devices, or operating systems. Basically, how well actions carried out on one platform are run on another. A portable system can save time and effort when you’re shifting from development to production or expanding to new platforms. 

Examples: 

• An app should be able to run on both Android and IOS while having the same core features.
• A program must be able to run on various operating systems like Windows, Linux, and macOS.
• The software should be container-ready (Exp: Docker) to support quick deployment on cloud environments like Azure or AWS. 

Best Practices of Documenting Non-Functional Requirements 

• • Be Specific: Make sure to avoid ambiguity by ensuring each NFR is specific. The requirement should be quantitative, measurable, and testable – instead of saying the “the system needs to respond fast”, specify “the system must respond to input within 3 seconds for 90% of users”. 
  • Relate requirements with Business Objectives: Break down business objectives and try to understand the real impact of the system’s behavior in terms of speed, uptime, etc. For instance saying “99.99% speed is needed to process payments” instead of just “high speed” – helps the team to really understand. 
  • Break Down to System Components: Try to specify requirements at the component level instead of the whole product, as it’ll be a waste of time setting requirements for specific parts if your users don’t interact with them.
  • Collaborate With All Stakeholders: When you’re writing NFRs, engage with clients and stakeholders to get their vision, carry out market research to understand user expectations, ask your team members for technical opinions, including developers, QA testers, and even end users when needed. This is necessary as everyone has different ways to help make NFRs stronger. 

• Existing Standards and Guides: Check existing iOS or Android app guidelines for your app, as many system requirements have already been made before.

• Consider Architecture Limitations: Quality can be affected due to legacy systems, and sometimes a total rework is needed instead of refactoring in order to meet requirements. 

• Review: Consistently review your requirement list with all stakeholders to ensure that they still align with business goals and adjust it as needed with new insights or advances in technology. 

Conclusion 

Documenting non-functional requirements is important to ensure each team member and stakeholder has a shared understanding of the project goals. With clear documentation, teams can minimize the risk of miscommunication, which can lead to costly rework.

Frequently Asked Questions (FAQ)

1.What is the difference between functional and non-functional requirements?

Functional requirements describe the features of the software and how it behaves (what the system does). Involves what users are allowed to do, which actions trigger certain responses and more.

Non-functional requirements, however, describe quality attributes such as performance, reliability, maintainability, and other qualities. They define how a system should perform rather than what it should do.

2.What do the non-functional requirements SRS template offer?

Non-functional requirement (NFR) SRS template offers a predefined structure to define NFRs. Not only does an SRS ensure consistency across all NFRs, but it also reduces system failures, increases user experience, and aligns with business goals.

3. How does an SRS document help with software development?

A software requirement specification document aids software development by keeping teams grounded. Essentially, the SRS helps to maintain shared understanding, even as teams grow or product direction shifts. That consistency is crucial to reduce any miscommunication and minimize any rework. 

4. Where do non-functional requirements go inside an SRS document?

NFRs typically emerge in a dedicated section of the SRS titled “Non-Functional Requirements” or “System Attributes” (could vary). They are usually organized by types such as performance, security, reliability, usability, scalability, compliance, and so on.

5. How often should a Non functional requirements SRS be updated?

You should be updating and reviewing your NFRs regularly as new features or scope shifts impact what the software does. Assume that with each cycle the SRS documents will go though some changes, so it’s best to update frequently otherwise you may face misalignment later on.