Want to know what non-functional requirements exactly or how to write or document them properly? Look no further, as this guide explains this using a helpful example.
So, you’ve been asked to prepare a list of non-functional requirements for a system you’re developing, but have no idea what they are from a software engineering standpoint. This guide aims to detail to you what exactly are non-functional requirements along with an easy-to-understand example on how to write them for a drone system.
Enough said, let’s get right into it!
What are Non-Functional Requirements?
Non-functional requirements are seen as properties or constraints that the system should fulfil. These are requirements of the quality attribute of the website, how it should behave and appear to users. Therefore, as opposed to functional requirements, these forms of requirements entail the behaviour and properties the system should possess as well as constraints the system should comply with.
Another differing factor is that the document or plan for non-functional requirements is outlined in the system architecture, whereas functional requirements are detailed in the system design. Typically, both are included in a document known as the software requirement specification (SRS).
So, often these non-functional requirements have a more crucial need to be fulfilled as they dictate how the entire system functions instead of singular components as seen with functional requirements. Therefore, if not fulfilled it could render the system unusable or unable to meet the end-users’ and stakeholders’ expectations. They can even act as restrictions to the system design through different backlogs. If these aren’t fulfilled, this could render the system unusable as it can affect the entire system architecture instead of minute singular components.
Overall, it’s not a website feature that visitors directly use but the users’ expectation of the website, such as its reliability, intuitiveness and ease of use. Thus, by ensuring non-functional requirements of the website are met, the user experience and ease-of-use of the website are improved.
In short, functional requirements describe what a system shall do whereas non-functional requirements outline how a system is supposed to be.
Common Types of Non-Functional Requirements
Now, that we fundamentally know what non-functional requirements, to paint a clearer picture, let’s look into some common non-functional requirements that are often associated with the development of a new software:
Performance: Detail the speed at which the system responds to user input or completes a certain task or operation. For example, a web-based application should have moderate to high page loading speed and moderate to low page size. For a system that’s being deployed as a web platform, it’s crucial that users shall be able to load and access the platform in a lesser amount of time.
Specifically, we can measure this web platform speed using reputable online performance tools, such as GTMetrix and Google PageSpeed Insights. For this, the typical metrics used for measuring site speed are First Contentful Paint (FCP), Time to Interactive, and Fully Load Time.
Overall page loading speed is very essential to a web system as it’s more efficient and provides a much better on-page user experience. Thus, this can reflect on the website’s overall reputability, brand and reliability, leading to lower abandonment and bounce rate as well. Optimising site speed is also essential for the web platform’s search engine optimisation (SEO) performance to ensure high search rankings, allowing it to compete with the other competitor sites and garner a consistent flow of users.
Security: Does the software comply with any security standards? Does the software collect, store, or send any sensitive user data and how does it protect against any threats?
This is one of the most crucial non-functional requirements for a system as it ensures that the data the system holds is protected against external threats or attacks, unauthorized access or manipulation, leaks and any other form of breaches. So, you can describe the protection mechanisms your system employs, however this may be leading more towards the functional side.
A primary example of such sensitive data includes the user’s contact information, such as their phone numbers, email, and address. One form of a protection mechanism that ensures the security of users’ privacy and data on a platform is through limiting access to this information.
Ease of Use/Usability: The degree of how easy or intuitive the system should be to be learned or utilized. It illustrates the user experience of the system. Hence, it’s crucial that the system has a lower learning curve so that users almost instantly understand where all the buttons and required information is available on the web platform. So, this ensures the platform is easy to use and provides an optimal user experience.
By making the platform easy to use, the number of errors or failures encountered by the user on the system can be significantly reduced as well, since there are appropriate and indicative error messages. Thus, we can measure the system’s ease of use during the User Acceptance Testing (UAT) or Beta Testing, where real users can test out various functionalities within the system. During this, the developers have to calculate the rate of failure occurrence.
Plus, another way the system’s ease of use can be improved, is the system shall provide help frames or simple tutorials guiding users through performing certain functionality.
Reliability/Availability: Explain what’s the failure time limit or how long the system shall be accessible to the end-user (all hours of every day or a specific time). To ensure the platform is always functional and accessible the system shall experience little to no downtime. So, this is a measurable non-functional requirement, which we can test in terms of time or seconds the platform is inaccessible.
Thus in the event, downtime does occur it shall not exceed, for example, 5 seconds in any one day. This ensures the unexpected downtime is not noticeable and users can resume their tasks on the system almost instantly. The system should overall be able to handle numerous concurrent users and activities/interactions while being less prone to crashes and backend errors.
This is to preserve the reputation and reliability of the system. Besides that, it’s to ensure that the user’s activities or tasks aren’t halted midway. Overall, keeping platform crashes and downtime to a minimum can ensure the user experience is conserved.
Responsiveness: This especially applies to web applications, where you’ll need to outline the different devices or aspect ratios that the system should support. So, the system should have a consistent, smooth and flawless layout regardless of whichever device you’re using the website from. Therefore, the website is responsive or appears well-designed and the content is correct on both large screens (laptops, PC) and small screens (smartphones, tablets) alike.
Compatibility: Describe the minimum hardware and operating system version requirements to support your system/software.
Capacity: What is the storage specification of your system? How and can your system be scaled upwards to fulfil an increase in demands or user count?
Scalability: Often related with performance to measure the capacity of a system to determine the highest possible workload the system can manage.
Maintainability: Generally describes the amount of time required to resolve or fix certain key components, changes to be implemented to boost performance.
Regulatory: Does the system have to fulfil or comply with any standards or requirements?
Environmental: Describe the environment in which the system will operate and any environmental considerations the system will have to comply with.
Know of any other type of non-functional requirement we might’ve missed out on? Feel free to share with us in the comments below.
Example of How to Write Non-Functional Requirements for a Drone System
For the case of a drone system, each system type plays a different role, so its requirements can also differ. Generally, it’s crucial that it fulfils safety and response requirements. So, the following are some non-functional requirements of such a drone system:
1. The drone shall prioritise its safety by being able to steer clear from and deal with small obstacles, hindrances or hurdles that it encounters in its flight path.
It’s crucial for the drones to have a sophisticated avoidance mechanism to prevent collisions with sizeable objects. If it doesn’t have an avoidance mechanism when it encounters large immovable obstacles it can cause the drone to crash and experience malfunctions and destruction.
Therefore, the drone should have a mechanism where its able to arrive back at the launch site in the event it comes across unfavorable circumstances during its flight. Additionally, the drone will maintain a maximum flight height of 350 feet above the ground to avoid collisions with FAA regulated aircraft in the public and common airspace.
Also, flying over a certain maximum height can cause the drones to lose connection from the operator due to excessive communication wave interference. Thus, in the event of a drone losing connection, it may no longer receive instructions and can halt its flight and cause damages from a potential crash.
2. The drones shall not fly over the pre-specified travel range.
Additionally, travel range is another crucial non-functional requirement for a drone system. When the drones exceed a pre-specified travel range, the system shall prompt a cautionary or warning message to the operator for them to make the appropriate controls. Plus, as mentioned before the drone system shall not fly over the predetermined maximum limit of flight height, which is 350 feet, to prevent collisions with other aircraft and objects in the sky and connection loss.
3. The system shall have a low recovery time.
At the same time, another safety factor non-functional requirement the drone system should fulfil is that the system shall have a low recovery time. After experiencing any minor system failure or downtime, the drone system shall possess a low recovery time and not exceed the pre-determined time limit.
For this, in the event of a system failure, it’s expected that the maximum recovery time is 0.4 seconds. Therefore, if a loss of connection occurs temporarily, the drones can re-establish the connection and continue their regular safe flight path and avoid any further damaging collisions that could compromise or jeopardise the drone’s safety.
4. The system shall be reliable in terms of network connectivity.
The drone system highly depends on the durability, robustness and strength of its physical user interface, which is the network connection in the area the drone is flying or being operated in. Thus, it’s crucial that the drones have a steady, consistent and strong network connection to avoid connection loss. As mentioned before a connection loss can be potentially damaging to the drones as they can no longer receive instructions from the operator and even cause the drones to halt their flight and crash.
5. The drone system should have a quick response time.
When turning on the drones, the display and system should be updated, turned on or fully booted within 10 seconds. Also, this can be achieved through prompt and rapid responses, reactions and feedback from the drone system after each operator action. This includes changes in-flight movement, prompting errors, etc.
When encountering certain potentially time-consuming activities like battery charging, establishing a connection, booting up, the system shall indicate the activity is still in progress and show the progress of completion. So, this can indicate to the customer the activity is still taking place and the system has not simply failed or experienced an error.
6. The drone system should return any feedback to the operator rapidly and quickly.
Therefore, moving on, feedback is another crucial non-functional requirement of the drone system in that any form of feedback should be prompted to the operator rapidly and quickly. So, the feedback is prompted to the user in a reasonable time span that’s prespecified. This includes the time taken for the system to give feedback messages and warning or error messages to the user.
Also, the system shall prompt a Low Battery warning when the drone needs to be charged so that the operator knows when to do so and avoid flight. At the same time, the system should clearly display the drone’s battery level, so the operator can always monitor it and determine the drone’s flight plan accordingly or make sure to charge the drones.
Conclusion
To recap, non-functional requirements essentially describe how a system should behave, its quality attributes or properties, as well as the constraints it should comply with.
After exploring non-functional requirements from a theoretical aspect of software and requirements engineering, this guide further illustrates several common types of non-functional requirements as well as an example of how non-functional requirements can be listed for a drone system.
Before we end, we hope that you found this guide to be helpful and feel free to let us know in the comments:
- Have any questions lingering in your mind about this topic of non-functional requirements?
- Let us know if you have any extra information or another example of non-functional requirements.
- What other topics would you like to hear from us?
Feel free to share this post with your fellow software engineering enthusiasts or anybody you know that needs help with understanding or documenting non-functional requirements.
