What are non-functional and functional requirements?
Non-functional and functional requirements are part of documentation and specifications that developers use when developing software. Functional requirements describe what an application needs to do, while non-functional requirements specify how it must be designed.
More precisely – functional requirements define what your system should do or allow users to do. We can often treat them as a product feature that the user can detect. The feature can be obvious, such as the “Login” button. Or it might be more subtle – such as how a system sends a confirmation email to the user after a successful purchase.
If these needs are not met, the system can’t possibly meet the user’s requirements.
Non-functional requirements, often referred to as NFRs, describe the quality of the application and the behavior desired from it. In short, they are being used to describe the quality criteria for your product’s function, such as the application’s speed, security, performance, availability, and usability (we’ll get to them later).
What are the types of non-functional requirements?
Quite often, the NFRs are called “Ity”. You may wonder the name comes from? Take a look: Security, Scalability, Reliability… And all is clear.
Here’s a list of the main types of non-functional requirements used in software product development.
Security
Securing your application is one of the most important elements related to its development. This requirement focuses on how to secure all the data and actions in the system against possible malware attacks or unauthorized access, and what measures will keep that data safe.
Example: All system endpoints are secured with a certificate with a specific encryption strength.
Helpful questions:
- How to envisage the impact of security mechanisms on the end user?
- Does your product process (use or store) any sensitive data (e.g., GDPR-related)?
- Do you know what security standards are set in your industry?
- What types of threats might your app face?
Performance
Performance assesses how quickly or smoothly the system reacts to user interaction under a specific workload. It measures how long it takes for a given operation to happen (and be seen by users) but also represents processes running in the background (invisible to users).
Example: It takes no more than 1 second for the page to reload after performing an action.
Helpful questions:
- What is the maximum number of users using it at the same time?
- Are we aware of the worldwide regions from which potential traffic may take place?
- What is the maximum response time of the application to the user’s query?
- What are the expected highest loads at which the system will continue to fulfill its intended purpose?
Scalability
Scalability stands for the system’s elasticity. It is the degree to which the system can expand its processing capacities upward and outward to meet performance requirements and support business growth.
No system can do without scalability. It prevents the software from future downtime and provides the quality of your service.
Grzegorz Izydorczyk
Tech Lead
Nowadays, it is not necessary anymore to double or triple the cost of the whole technical infrastructure to ensure scalability. Still, it is essential to understand the potential system usage to design the architecture more accurately, preventing the overengineering of the complete solution.
Example: The platform must be scalable enough to support 2000 visits simultaneously while maintaining optimal performance.
Helpful questions:
- How easy is it to expand or upgrade the system’s capabilities?
- Can the system cope with increasing processing load or expanding business locations?
Throughput
Throughput focuses on how many messages or transactions can be processed simultaneously by the system. Think about it like this: Capacity is how much will fit in. Throughput is how much will flow.
Example: It takes no more than a second to deliver to a receiver, even if 100 000 clients are communicating simultaneously.
Helpful questions:
- How many users/processes can access your application simultaneously?
- How long does it take to handle the process within your application within peak hours?
- How long does it take for your app to recover to normal operation after acting under heavy load?
Reliability
Reliability defines the probability that the system will not fail for a specific time interval or the number of uses. It is also information that, e.g., a system will have 99% up-time on a monthly basis. A reliable application performs equally at times of regular and heavy use.
Grzegorz Izydorczyk
Tech Lead
Most of all, the time in case of reliability means defining specific periods of the day when the system must be stable to secure business needs. For instance, the system will be used sporadically at night between 10 pm and 4 am. Thanks to this, it will be possible to use this time for complex and time-consuming data analysis without the need to scale up the infrastructure.
When implementing the system, it is crucial to understand the business context well enough to know how meticulous you should be when handling different cases. Sometimes it may be ok for the customer not to receive the transactional email, but otherwise, it will be unacceptable.
Example: The system must perform without failure in 99.7% of use cases.
Helpful questions:
- Are there any critical times of the day when the system needs to be stable to ensure business stability?
- Is a new functionality crucial for the business, or it just provides an improvement that can be skipped under certain conditions?
- What is the probability that the system will fail when a service is requested?
Availability
Availability approaches the same notion as reliability, but from a different angle. It describes the time frame in which the system is accessible for a user.
Grzegorz Izydorczyk
Tech Lead
Availability also means regionalization – the possibility to access from different places on Earth and the localization, i.e. availability in other languages. Further requirements may be associated with this, such as locating the data in a given country’s data center and meeting any related restrictions or regulations.
Example: Users can access the system throughout the week at any time during the day.
Helpful questions:
- Does a user need access to the app all hours of every day?
- What is an average uptime for your service?
- What’s the duration and frequency of downtime?
- Are there any policies that must be met to store data in a given country’s data center?
Compatibility and Portability
These two “Ity’s” represent software’s ability to interact with other systems.
Compatibility enables users to use your application on different hardware, browsers or operating systems. It also defines how a system can function with another system in the same environment.
Example: Software must be able to run on different operating systems like Windows, Unix, macOS, or Web browser extension must be compatible with Google Chrome environment.
Helpful questions:
- Which operating systems and versions should be supported?
- Is a program compatible with the system’s firewall or antivirus protection?
- What are the minimum hardware/software requirements for installing the application?
Portability, on the other hand, measures the readiness of your app to operate in different environments. The less effort is needed to transfer your system from its current hardware or software environment to another, the higher its portability.
Example: A program running on macOS Monterey must be able to run on macOS Ventura.
Helpful questions:
- Is it possible to launch a system within another environment?
- Does an app use many native controls that can be relatively easy to port?
Maintainability
Maintainability is the time, ease, and flexibility with which software or its component can be modified, both for bug fixes and functionality updates. Maintenance is a natural part of the software development life cycle and takes up a large part of the IT budget. The more maintainable a system will be, the lower the cost of ownership.
Example: The mean preventative maintenance time of the platform must be less than 1 hour every 2 weeks.
Helpful questions:
- How will we monitor the application’s performance and stability?
- How can users report feedback?
- What is our crisis management process?
Usability and Accessibility
Usability, in its essence, is concerned with user experience and how the user perceives a system’s functionality. It assesses the ease with which the intended user can learn and operate the software. For instance, an application can be functional but utterly unusable if it has a confusing interface and controls.
Example: The system provides on-screen contextual prompts that guide users on how to operate the software.
Helpful questions:
- How hard is it to use the system?
- Can the application lead users through steps and notify them of upcoming events
- How closely should the new system resemble existing applications?
- How quickly can users reach their goals?
Accessibility focuses on adapting a system or product to the special needs of specific groups with the broadest range of capabilities, such as persons with disabilities. It is the ease with which such users can operate software and achieve their goals in a specified context.
Example: All audio content in the system will be provided with a text alternative.
Helpful questions:
- How easy is the system to use by people with varying capabilities?
- Does your application meet legislation regulations and standards?
- Does the system meet specific visual, hearing, cognitive, and mobility needs?
What else to keep in mind when dealing with non-functional requirements
Well-defined non-functional requirements are crucial for an application to function properly. Here are some fundamental things to remember when forming and documenting NFRs.
NFRs must be measurable and testable
Let’s say you want your system to be fast and responsive. Such a vague definition is not helpful in the case of non-functional requirements. To assess whether the software meets quality constraints, you need to specify the exact measurements and numbers that will determine how well your product works and the methods you will use to test it.
The more specified standards, such as the exact response time of the website, the better the chances will be to overcome obstacles during the development and implementation of the project.
Defining non-functional requirements is a process
Like anything in Agile development, NFRs are not set in stone. Their definition, verification, and reiteration happen regularly in sprints, so they can follow the changing needs and priorities of the project.
To define non-functional requirements, it’s necessary to analyze the product in detail and understand how it works. Clarifying your expectations indeed affects the efficiency of the development process and allows developers to understand your goals and vision.
A well-conducted product discovery phase – both before the start of the project and before the start of work on a given functionality – will ensure the correct series of actions, including selecting the appropriate system architecture. It will enable the vendor to propose solutions that will be relevant and optimal (also in terms of costs) at various stages of system development.
NFRs should primarily work with your business goals
NFRs are based on what you want to create – what kind of target audience you have in mind and how much money is available for development – as well as on the overall purpose within your company or organization. In this case, discussing the business objectives between stakeholders and the project architect may be necessary.
Several aspects should be considered, such as analyzing the current market situation, possible competition, and the user’s perception and habits.
It is worth considering launching a product early to see real user interactions, but only if you are sure that what you are shipping helps you learn while providing value to the user. Giving users access to your product will validate your idea, help you gather feedback, and iterate on the product.