In the last article, we discussed Abstraction and Remote Procedures calls and their working. In this article, we will see what are the different types of Non-functional requirements for a robust system. As we know, Non-functional + functional = complete requirements. Functions requirements are about what the system should do. Here we are discussing Non-functional.
Non-functional System Characteristics describe how the system should perform, rather than what it should do.
Below are the types of Non-functional requirements:
Performance and scalability.
How fast does the system return results? How much will this performance change with higher workloads?
Performance defines how fast a software system or a particular piece of it responds to certain users’ actions under a certain workload. In most cases, this metric explains how long a user must wait before the target operation happens (the page renders, a transaction is processed, etc.) given the overall number of users at the moment. But it’s not always like that. Performance requirements may describe background processes invisible to users, e.g. backup. But let’s focus on user-centric performance.
Scalability assesses the highest workloads under which the system will still meet the performance requirements. There are two ways to enable your system to scale as the workloads get higher: horizontal and vertical scaling.
Horizontal scaling is provided by adding more machines to the pool of servers.
Vertical scaling is achieved by adding more CPU and RAM to the existing machines.
Portability and compatibility.
Which hardware, operating systems, and browsers, along with their versions does the software run on? Does it conflict with other applications and processes within these environments?
Portability determines how a system or its element can be launched within one environment or another. It usually includes hardware, software, or other usage platform specifications. Put simply, it establishes how well actions performed via one platform are run on another. Also, it prescribes how well system elements may be accessed and may interact from two different environments.
Example of portability requirements:
A program running on Windows 10 must be able to run on Windows 11 without any change in its behavior and performance.
Compatibility, as an additional aspect of portability, defines how a system can coexist with another system in the same environment. For instance, software installed on an operating system must be compatible with its firewall or antivirus protection.
Reliability, maintainability, availability.
How often does the system experience critical failures? How much time does it take to fix the issue when it arises? And how is user availability time compared to downtime?
Reliability specifies how likely the system or its element would run without a failure for a given period of time under predefined conditions. Traditionally, this probability is expressed in percentages. For instance, if the system has 85 percent reliability for a month, this means that during this month, under normal usage conditions, there’s an 85 percent chance that the system won’t experience critical failure.
Maintainability defines the time required for a solution or its component to be fixed, changed to increase performance or other qualities, or adapted to a changing environment. Like reliability, it can be expressed as a probability of repair during some time. For example, if you have 75 percent maintainability for 24 hours, this means that there’s a 75 percent chance the component can be fixed in 24 hours. Maintainability is often measured with a metric like MTTRS — the mean time to restore the system.
Example of maintainability requirements:
The mean time to restore the system (MTTRS) following a system failure must not be greater than 10 minutes. MTTRS includes all corrective maintenance time and delays time.
Availability describes how likely the system is accessible to a user at a given point in time. While it can be expressed as an expected percentage of successful requests, you may also define it as a percentage of time the system is accessible for operation during some time period. For instance, the system may be available 98 percent of the time during a month. Availability is perhaps the most business-critical requirement, but to define it, you also must have estimations for reliability and maintainability.
Example of availability requirements:
The web dashboard must be available to US users 99.98 percent of the time every month during business hours EST.
Security. How well are the system and its data protected against attacks?
Localization. Is the system compatible with local specifics?
Usability. How easy is it for a customer to use the system?
Thank you for reading. We hope this gives you a good understanding. Explore our Technology News blogs for more news related to the Technology front. AdvanceDataScience.Com has the latest in what matters in technology daily.
