Functional and Non Functional Requirements (UPDATED 2023)
This Tutorial Explains the Types, Features, Comparison of Functional vs Non Functional Requirements and Business vs Functional Requirements With Examples:
Functional requirements define what a software system should do. It defines a function of a software system or its module. Functionality is measured as a set of inputs to the system under test to the output from the system.
Functional requirement implementation in a system is planned in the System Design phase whereas, in case of Non-functional requirements, it is planned in the System Architecture document. The functional requirement supports generating the non-functional requirements.
Functional Vs Non Functional Requirements
Let us have a look at the major differences between functional and non-functional requirements.
Sl. noFunctional Requirements (FR)Non-functional requirements (NFR)
1They say, what a system should do.They say, what a system should be.
2They are detailed in the System Design document.They are detailed in the System architecture document.
3They talk about the behavior of a function or feature.They talk about the working behavior of a whole system or a component of the system and not a particular function.
4The user will pass input and check whether the output is correctly displayed.When the user passes an input, the following questions can be answered by NFRs:
i) How much time does it take to display output?
ii) Is output consistent with time?
iii) Are there other ways to pass the input parameter?
iv) How easy is it to pass the input parameter?
5In a web application, the user should be able to log in via authentication is FRIn a web application, how much time does it take to log in to the website, look and feel of the login page, ease of usage of a web page, etc. are part of NFR
6Functional requirements are derived first from Software requirements.Non-functional requirements are derived from functional requirements.
7Functional requirements form the skeleton of Software system implementationNon-functional requirements completes the SW system by helping the functional requirements stick together, like a muscle.
8Functional requirements can exist without a non-functional requirement.Non-functional requirements cannot exist without functional requirement.
9A functional requirement gives concrete information about a feature, Example, Profile photo on Facebook should be visible on login.A functional requirement can have many non-functional requirements attributes. Example, time to log in (performance), look and feel of the profile page(usability), number of users who can log in at a time (capacity, performance)
10Deriving functional requirements from SW requirements is possible for almost all Business requirementsNFRs are often missed to be documented, as relevant questions are not asked on FRs.
11Implementing a functional requirement is normally done in one software build.NFRs are implemented throughout the lifecycle of the project until the desired behavior is achieved.
12These are mostly visible to the customer.These are mostly not visible to the customer but could be experienced in the long term. Example, Usability, Performance, etc. can be experienced only in the long term but can’t be visible at all.
Functional Requirements
Let us understand the functional requirements with the help of examples:
Example: In an Automotive ADAS project, a surround-view system functional requirement could be “Rear Camera should detect a threat or object”. Non- functional requirements here could be “how quickly the alert to a user should be displayed when a threat is detected by camera sensors”.
Take another example of the Infotainment systems project. The user enables Bluetooth here from HMI and checks whether Bluetooth is enabled or not. Note: Other Bluetooth services get enabled (from gray to bold) when the user enables Bluetooth.
So, functional requirements talk about a particular system outcome when a task is performed on them by the user. On the other hand, the non-functional requirement gives the overall behavior of the system or its component and not on function.
Types of Functional Requirements
Functional requirements could include the following components that can be measured as part of functional testing:
#1) Interoperability: Requirement describes whether a software system is interoperable across different systems.
Example: For Bluetooth functional requirement in the Car infotainment system, when the user pairs a Bluetooth enabled Android-based Smartphone to QNX based infotainment system, we should be able to transfer Phonebook to infotainment system or stream music from our Phone device to infotainment system.
So interoperability checks whether communication between the two different devices is possible or not.
Another example is from email service systems like Gmail. Gmail allows importing emails from other mail exchange servers like Yahoo.com or Rediffmail.com. This is possible due to interoperability between email servers.
#2) Security: The functional requirement describes the security aspect of software requirements.
Example: Cyber Security based services in the ADAS surround-view camera-based system that uses Controller Area Network (CAN) that protects the system from the security threat.
Another example is from the social networking site Facebook. A user’s data should be secure and must not be leaked to an outsider. We hope this example of Facebook gives a wider purview of security to readers due to the recent data breach incidence at Facebook and the consequences faced by Facebook.
#3) Accuracy: Accuracy defines a data entered into the system is correctly calculated and used by the system and that the output is correct.
Example: In the Controller Area Network, when a CAN signal value is transmitted over CAN bus by an ECU (viz. ABS unit, HVAC unit, Instrument cluster unit, etc.) another ECU will be able to identify whether the sent data is correct or not via CRC check.
Another example can be from an online banking solution. When the user receives a fund, the amount received should be correctly credited to the account and no variation in the accuracy is accepted.
#4) Compliance: Compliance functional requirements validate that the developed system is compliant to Industrial standards.
Example: Whether Bluetooth profiles functionalities (viz. audio streaming via A2DP, Phone call via HFP) are compliant to Bluetooth SIG release profile versions.
Another example can be that of Apple Car play in Car infotainment system. The App in the infotainment gets a certificate from Apple if all the preconditions mentioned in the Apple website are fulfilled by third-party Car Play devices (infotainment in this case).
Another example can be from a Web-based application for the railway ticketing system. The website should follow the cybersecurity guidelines and comply with the World Wide Web in terms of accessibility.
Example of Requirement form:
We have learned the functional requirements with some examples. Let us now see what a functional requirement would look like when integrated into requirement management tools like IBM DOORS. There are multiple attributes to be taken into consideration while documenting a functional requirement in the Requirement management tool.
Below are a few attributes to be taken into consideration:
-
Object type:
This attribute explains which section of the requirement document is part of this attribute. They could be Heading, Explanation, Requirements, etc. Mostly “Requirement” section is considered for the implementation and testing while heading and explanation sections are used as supporting descriptions for requirements for better understanding.
-
Responsible person:
An author who has documented the requirement in requirement management tool.
-
Project/System name:
The Project for which the requirement is applicable,
for example,
“Infotainment Systems for XYZ OEM (Original Equipment Manufacturer) an automotive company or Web application for ABC banking limited company”.
-
Requirement version number:
This field/attribute notifies the version number of the requirement if the requirement has undergone multiple modifications due to customer updates or changes in system design.
-
Requirement ID:
This attribute mentions the unique requirement id. Requirement Id is used in tracking the requirements in the database easily and also in mapping the requirements in code efficiently. It can also be used to provide a reference to requirements while logging defects in bug tracking tools.
-
Requirement description:
This attribute is one of the most important attributes that explain the requirement. By reading this attribute, an engineer would be able to understand the requirement.
-
Requirement status:
Requirement status attribute says about the status of a requirement in the requirement management tool i.e. whether it is accepted, on-hold, rejected, or deleted the project.
-
Comments:
This attribute provides the Responsible person or requirement manager an option to document any comment about the requirement.
Example:
a possible comment for a functional requirement could be “dependency on a third-party software package to implement the requirement”.
A snapshot from DOORS
Deriving Functional Requirements from Business Requirements
This is already covered as part of the section “Deriving Functional requirements from Business requirements” under the Requirement Analysis article.
Business Requirements Vs Functional Requirements
This difference is loosely covered in the Requirement analysis article. We will, however, try to highlight a few more points here in the table below:
Sl. No.Business Requirements Functional Requirements
1Business requirements say “what” aspect of Customer requirement. Example, What should be visible to user after the user logs in.Functional requirements say “how” aspect of business requirements. Example, How the webpage should display user login page when the user authenticates.
2Business requirements are identified by Business analysts.Functional requirements are created/derived by Developers/Software architect
3They emphasize on the benefit to the organization and are related to business goals.Their goal is customer requirement fulfillment.
4Business requirements are from Customer.Functional requirements are derived from Software requirements, which is, in turn, is derived from Business requirements.
5Business requirements are not tested by Software Test Engineers directly. They are tested by the customer mostly.Functional requirements are tested by Software Test engineers and generally not tested by Customers.
6The business requirement is a high-level requirement document.A functional requirement is a detailed technical requirement document.
7For example, in the online banking system a business requirement could be “As a user, I should be able to get cash transaction statement”.Functional requirement in this online banking system could be, “When user provide the date range in transaction query, this input is used by Server and the webpage is provided with the necessary cash transaction data”.
Non Functional Requirement
The non-functional requirement says about “what a system should be” rather than “what a system should do” (functional requirement). This is mostly derived from functional requirements based on input from the customer and other stakeholders. Non-functional requirement implementation details are documented in the System Architecture document.
Non-functional requirements explain the quality aspects of the system to be constructed viz. performance, portability, usability, etc. Non-functional requirements, unlike functional requirements, are implemented incrementally in any system.
URPS (Usability, Reliability, Performance, and Supportability) from FURPS (Functionality, Usability, Reliability, Performance, and Supportability) quality attributes that are widely used in the IT industry to measure the quality of a software developer, are all covered in non-functional requirements. Besides, there are other quality attributes also (details in the next section).
Wikipedia calls the non-functional requirement as ‘ilities’ sometimes, due to the presence of various quality attributes like portability and stability.
Types of Non-functional Requirements
Non-functional requirements consist of the below subtypes (non-exhaustive):
#1) Performance:
A performance attribute type of non-functional requirement measures system performance. Example: In the ADAS surround view system, “rear camera view should be displayed within 2 seconds of starting the Car ignition”.
Another example of performance could be from an infotainment systems Navigation system. “When a user goes to Navigation screen and enters the destination, the route should be calculated within “X” seconds”. One more example from the web application login page. “Time it takes for the user profile page to load after login.”
Please remember that system performance measurements are different from load measurements. During load testing, we load the system CPU and RAM and check the system throughput. In the case of performance, we test the system throughput in normal load/stress conditions.
#2) Usability:
Usability measures the usability of the software system being developed.
For example, a mobile web application is developed that gives you information about plumbers and electrician’s availability in your area.
The input to this app is postcode and radius (in kilometers) from your current location. But to enter these data, if the user has to browse through multiple screens and data entry option is displayed in small text boxes that are not readily visible to a user, then this app is not user-friendly and hence usability of the app will be very low.
#3) Maintainability:
Maintainability of a software system is the ease with which the system can be maintained. If the Mean Time Between Failures (MTBF) is low or Mean Time To Repair (MTTR) is high for the system being developed, then the maintainability of the system is considered low.
Maintainability is often measured at code level using Cyclomatic complexity. Cyclomatic complexity says that the lesser complex the code is, the easier it is to maintain the software.
Example: A software system is developed that has the high number of dead codes (codes not used by other functions or modules), highly complex due to excessive use of if/else condition, nested loops, etc. or if the system is huge with codes running into many millions of lines of codes and no proper comments. Such a system is low in maintainability.
Another example could be of online shopping webpage. If there are many external links on the website so that the user can have an overview of the product (this to save on memory), then the maintainability of this website is low. This is because, if external webpage link changes, it has to be updated on the online shopping website also and that too frequently.
#4) Reliability:
Reliability is another aspect of availability. This quality attribute emphasizes the availability of a system under certain conditions. It is measured as MTBF just like maintainability.
Example: Mutually exclusive features like rearview camera and Trailer in ADAS surround-view camera system should reliably work in the system without any interference with each other. When a user calls up the Trailer feature, the rearview should not interfere and vice versa as both features access the rear camera of the car.
Another example from the online insurance claim system. When a user starts claim reporting and then upload relevant expense bills, the system should give enough time for upload to complete and should not cancel the upload process quickly.
#5) Portability:
Portability means the ability of a software system to work in a different environment if the underlying dependent framework stays the same.
Example: Software system/component in an infotainment system developed (viz. Bluetooth service or multi-media service) for an automotive car manufacturer should allow to be used in another infotainment system with little or no change in code, although the two infotainment systems are entirely different.
Let us take another example from WhatsApp. It is possible to install and use the messaging service on IOS, Android, Windows, Tablet, Laptop, and Phone.
#6) Supportability:
Serviceability of a software system is the ability of a service/technical expert to install the software system in a real-time environment, monitor the system while it is running, identify any technical issues in the system and provide a solution to resolve the issue.
Serviceability is possible if the system is developed to facilitate serviceability.
Example: Providing periodical reminder popup to the user for a software update, providing logging/trace mechanism to debug issues, automatic recovery from failure via rollback mechanism (roll back the software system to previous working condition state).
Another example from Rediffmail. When there was an update in the version of the web-based mailing service, the system allowed the user to switch to a newer version of the mailing system keeping the older one intact for few months. This enhances the user experience as well.
#7) Adaptability:
The adaptability of a system is defined as the ability of a software system to adapt to change in an environment without any change in its behavior.
Example: Antilock Braking System in Car should work as per standard in all weather conditions (hot or cold). Another example could be that of an Android operating system. It is used in different types of devices, viz. Smartphones, Tablet computers, and Infotainment systems and are highly adaptable.
In addition to the 7 non-functional requirements listed above, we have many others like:
Accessibility, Backup, Capacity, Compliance, Data integrity, Data retention, Dependency, Deployment, Documentation, Durability, Efficiency, Exploitability, Extensibility, Failure management, Fault tolerance, Interoperability, Modifiability, Operability, Privacy, Readability, Reporting, Resilience, Reusability, Robustness, Scalability, Stability, Testability, Throughput, Transparency, Integrability.
Covering all these non-functional requirements is outside the scope of this article. You can, however, read more about these non-functional requirement types in Wikipedia.
Deriving Non-Functional Requirements From Functional Requirements
Non-functional requirements can be derived in many ways, but the best and most industries tried and tested way is from functional requirements.
Let us take the example from our Infotainment systems that we have already taken in a few places in this article. The user can perform many actions on the Infotainment system, viz. change the song, change song source from USB to FM or Bluetooth audio, set Navigation destination, update infotainment software via a software update, etc.
#1) Non-functional requirements gathering:
We will list the tasks performed by a user, which is a part of functional requirements. Once the user actions are noted in the UML use case diagram (each oval), we will start relevant questions (each rectangle) on every user’s actions. Answers to these questions will give our non-functional requirements.
#2) Non-functional requirements categorization:
The next step is the categorization of non-functional requirements that we have identified via questions. At this stage, we can check the possible answer and categorize the answers to possible non-functional categories or different qualities.
In the image below you can see the possible quality attributes identified from the answers.
Conclusion
Requirements form the basic building block to develop any software system. It is possible to build a system with functional requirements but its abilities cannot be determined nor measured. Having said that, it is very important to have good quality functional requirements derived from a business requirement to have a high quality working software system.
Hence, functional requirements give the direction of implementation of a software system but non-functional requirements determine the quality of implementation that end-users will experience.
