%20(1).png?width=300&name=minimalist%20technology%20background%2c%20as%20a%20concept%20of%20non%20functional%20requirements%20in%20IT%20(3)%20(1).png)
Non-functional requirements (NFRs) in software engineering specify the quality attributes of a software system. In this article, we'll explore examples of non-functional requirements and how they work in an application.
There’s more to building great software than delivering the right functionality. Users also expect the software product to be convenient to use, blazingly fast, and to hardly ever fail. While these expectations seem obvious, they are often missing from product planning discussions. A good business analyst or requirements engineer will uncover and define these and many less obvious expectations in conversations with the stakeholders. If you are a stakeholder, this article can help prepare for this conversation by detailing which non-functional requirements matter for your product.
What Are Non-Functional Requirements?
Requirements to an IT product should explain why to build a product (business requirements), what the product will do (functional requirements - features), and how the product will work (non-functional requirements). Non-Functional Requirements (NFRs) are the properties of a software system that define under which conditions a system is expected to remain functional, the constraints imposed upon the system, and the system’s quality attributes.
Imagine you built an e-commerce store but didn’t account for traffic spikes around the holidays. Or you expanded to the Arabic market where the reading pattern starts at the top right corner and progresses to the left, but you didn’t mirror the layout on the localized website accordingly. These are examples of non-functional requirements to reliability and localization not being taken into account, and that will leave users unhappy.
Insufficiently addressing Non-Functional Requirements (NFRs) can lead to the following outcomes:
1. Dissatisfied users, clients, and developers.2. Inconsistent software performance.
3. Delays and increased costs associated with rectifying software that was developed without considering NFRs.
Functional vs. Non-Functional Requirements in Software Engineering
.png?width=879&name=vectorial%20image%20of%20development%20team%2c%20as%20a%20concept%20of%20non-functional%20requirements%20(1).png)
In software engineering, functional requirements specify the behaviors of the system. They describe what the developers must implement to enable users to accomplish their tasks (user requirements), thereby satisfying the business requirements. (Software Requirements by Karl Wiegers, Joy Beatty)
NFRs (often called quality requirements) augment the functional requirements by identifying their constraints and qualities.
For example, when Golden Globes came to us to prepare their website for the annual awards broadcast, one of their functional requirements was to allow website users to watch the ceremony online. One of the non-functional requirements specified that the system had to be able to support thousands of concurrent users. Defining these expectations was crucial for making the right architectural decisions for the new website and resulted in stelar performance of the website during the 2021 Golden Globes event (see more details in the case study).
Check Out This Comparison Table on Functional vs. Non Functional Requirements in Software Engineering
.png?width=574&height=574&name=Functional%20vs%20non%20functional%20requirements%20in%20software%20engineering%20comparison%20table%20(1).png)
Types of Non-Functional Requirements (Questions to ask + Examples)
A Guide to the Business Analysis Body of Knowledge (BABOK), the industry standard for the practice of business analysis, lists 15 types of non-functional requirements (NFRs) in software engineering. Many of them are interrelated, so we find it is helpful to collect them in blocks.
1. Availability, Reliability, Maintainability, & SLA block
2. Performance & Scalability Block
3. Portability & Compatibility & Localization block
4. Certification & Compliance Block
5. Functionability & Extensibility Block
Availability, Reliability, Maintainability, and SLA block - How often do we expect things to go wrong? Who and when will fix them?
- Availability describes the degree to which the solution is operable and accessible when required for use. It is often expressed as a percent of time the solution is available. A disclaimer: 100% availability is not achievable. A system might be not available because of bugs or updates. Completely eliminating bugs is unrealistic. Avoiding updates is not a solution.
What questions to prepare for:
1) Where are our users going to be geographically located? At what time of the day are they more likely to be using the product?
2) When can we allow a risk of temporary unavailability of our platform to fix bugs and make updates?
3) What portions of the system are most critical for being available?
An example:
The solution is to be available not less than 97% of the time in a year. The 4th Friday of every quarter is dedicated to updating the system during which the system might be not available. This gives us 98,9% uptime/availability.
- Reliability describes the ability of a solution or component to perform its required functions under stated conditions for a specified period of time. For example, you conduct a major revamp of your website every 3 years. The new website is, therefore, expected to work reliably under the expected traffic load for the following 3 years.
What questions to prepare for:
1) How many simultaneous users do you expect on average / maximum?
2) What parts of the system are used more than others and experience heavier traffic? (Logging in, registration, newsfeed)
3) If the system goes down, how long could it stay offline before it significantly affects your business operations?
An example:
The website must perform without failure in 95 % of use cases during a month given the traffic doesn’t exceed 200 concurrent users.
Get a Free Copy Of 'How To Tackle A Website Redesign'
%20(1).png?width=578&name=website%20redesign%20resource%20image%20(2)%20(1).png)
- Maintainability describes ease with which a solution or component can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment. Maintainability is often measured with a metric like MTTRS — the mean time to restore the system.
What questions to prepare for:
1) What is the chain reaction in response to a new bug detection?
2) What is the longest turnaround time that is acceptable?
An example:
The mean time to restore the system (MTTRS) following a system failure must not be greater than 60 minutes. MTTRS includes all corrective maintenance time and delay time.- Service Level Agreement describes constraints of the organization being served by the solution that are formally agreed to by both the provider and the user of the solution. This document can stipulate some or all non-functional requirements in software engineering. Service providers might have to pay a penalty if they do not satisfy such agreements. This agreement is created by layers and tech specialists and usually accompanies development and maintenance of life-critical applications.
Performance & Scalability block - How fast does the system return results and how are we going to support this performance as we grow?
- Performance Efficiency describes how quickly and predictably the system responds to user inputs or other events. In other words, this is about ensuring that your website is not slow.
What questions to prepare for:
1) What are the requirements in terms of speed of response?
2) What integrations and APIs can slow the speed of response down?
3) What would users consider an unacceptable response time for a typical query?
An example:
The ecommerce website should take less than 2 seconds to load.
- Scalability describes how easily the system can grow to handle more users, data, transactions, servers, or other extensions without compromising performance or correctness. (Software Requirements by Karl Wiegers). This is, for example, the difference between the minimum and the maximum traffic load a website is supposed to handle.
What questions to prepare for:
1) Do we expect high traffic most of the time?
2) What are the volumes of customers, transactions, accounts expected from the systems to handle within the first year of functioning of the platform?
3) What is the annual growth in volume (customers, transactions, etc.) expected in the next three to five years?
An example:
The website should be able to handle a website traffic growth of 10 % per quarter for at least three years without user-perceptible performance degradation.
Get a Free Copy of Our Latest eBook and Learn How to Make Better Products with Responsible Generative AI
Portability & compatibility & localization block - Which hardware, operating systems, browsers, and their versions, as well as languages does the software run on?
- Portability describes how easy a solution or component can be transferred from one environment to another.
What questions to prepare for:
1) On what devices should the platform be accessible?
2) What browsers do your users use?
3) What are the data portability expectations?
An example:
The user should be able to use the web app on Firefox, Opera, Chrome, and Safari.
- Compatibility describes the degree to which the solution operates effectively with other components in the same environment. For example, software installed on an operating system must be compatible with its firewall or antivirus protection.
What questions to prepare for:
1) What versions of mobile operating systems are going to support this app?
2) What browsers and their versions are going to support this web app?
3) What different platforms will this software need to run on, both now and in the future?
An example:
The iOS application must support iPhone devices running on OS versions 10.0 and higher.
- Localization describes requirements regarding local languages, laws, currencies, cultures, spellings, and other characteristics of users, which requires attention to the context.
What questions to prepare for:
1) What languages will the product support?
2) What currencies will the e-commerce store support?
3) (for trading platforms) If we plan to also cater to the Muslim market, what restrictions/adaptations to the functionality should we consider to respect Islam’s view on betting, gambling, and interest rates?
An example:
The layout is to be mirrored for RTL languages (Arabic).
Get a Free Copy of 'A Project Manager's Guide to Writing a Great RFP'
Certification & Compliance block - What laws and standards should we follow while creating and running this software?
- Certification requirement describes constraints on the solution that are necessary to meet certain standards or industry conventions. For a solution to be certified, an independent third party has to physically evaluate, test, and certify the product to be in conformance with all the requirements of the standard. This requirement can significantly impact the scope of work, so it is very important that you inform your development team about certification requirements at the planning stage.
What questions to prepare for:
1) Do we need to obtain any certificates before the launch of the product?
An example:
The solution has to be ISO XXXX.XX certified.
- Compliance requirement describes regulatory, financial, or legal constraints which can vary based on the context or jurisdiction.
What questions to prepare for:
1) Do we need to meet GDPR compliance rules?
2) With which financial services and consumer protection laws do we need to comply in which countries?
An example:
The app has to be HIPAA compliant.
Working on a new project?
Functionality & Extensibility block - What functionality are we adding to the product now and how do we ensure we enable adding more of it in the future?
- Functionality describes the degree to which the solution’s functions meet user needs. You might think “Wait, how come that functionality ended up in the non-functional requirements?” Remember we talked about NFRs often representing constraints to the desired behaviors of the system? This NFR describes the decisions about what of the listed requirements is going to be implemented in this version of the product and what is to be left for future iterations.
What questions to prepare for:
1) Which features are we covering in this version of the platform and which not?
An example:
If you are building a centralized crypto exchange platform, your MVP will likely include wallet generation, but stacking or earning crypto by fulfilling tasks might be saved for when you’ve found your product market fit and continue building out your product.
Watch this stop motion lego dramatization of a company that invests months, heck years into the development process without employing Rapid Prototyping to first research and determine the strengths and weaknesses of different platforms.
- Extensibility describes the ability of a solution to incorporate new functionality.
3) What integrations could we potentially need to add in the next 3 years?
An example: The website is to be integrated with Stripe and PayPal payment getaways in this version (V1). The integration with Amazon Pay should be possible in V2.
Get a Free Copy of 'Optimizing Your Website Performance To Improve Your Business'
Security & Usability block - How do we ensure the balance between what is convenient and what is safe?
The default “123456” password for all accounts is undeniably convenient but a terrible idea as far as security is concerned. Many platforms will warn you if you try using this password. Making the most secure way to use your product also the easiest one is something to strive for, because the security problems can be solved only by addressing issues of usability.
- Security describes the aspects of a solution that protect solution content or solution components from accidental or malicious access, use, modification, destruction, or disclosure.
What questions to prepare for:
1) What security requirements for the system do we have?
2) What kinds of malware attacks do you want to fend off?
3) What is our protocol in case a user's credentials are lost/forgotten or stolen?
An example: The solution must support Two Factor Authentication.
- Usability describes ease with which a user can learn to use the solution. According to Nielsen Norman Group, the world Leaders in research-based user experience, usability depends on five components: Learnability, Efficiency, Memorability, Errors, and Satisfaction.
What questions to prepare for:
1) What is our goal regarding how fast users complete the main actions once they see the interface? (at the stage of account creation, transaction initiation to transaction completion, etc.)
2) Do we have results of usability testing on competitor products?
An example:
The crypto exchange is to offer a transaction “Undo” button for 2 minutes after the transaction is confirmed by the user.
The Main Types Of Non-Functional Requirements in Software Engineering + Examples · Infographic
Non Functional Requirements in Software Engineering · Conclusion
Quality requirements such as “The app should be easy to use” and “The website should be fast” are not useful. They are far too vague and not measurable. Quality requirements need to be measurable to establish a precise agreement on expectations between the customers and the development team. What is measurable is also testable. Well-written functional and non-functional agreements are the perfect basis for writing and running tests, and assuring your product meets the highest quality standards.
Requirements lie at the heart of every well-run software project. Discovering, analyzing, and prioritizing them is truly a team sport. As a customer of either your internal IT team or a software development agency, knowing what non-functional requirements exist and which of them are critical for your product will contribute to much more productive conversations with your partners in tech.
COMMENTS