Non-functional requirements

Kostiantyn Ivanov
11 min readJul 21, 2023

--

Previous: https://medium.com/@svosh2/functional-requirements-27345ea1fd19

Non-functional requirements specify the attributes and qualities that describe how a system should perform or behave, rather than focusing on its specific functionalities.

To understand which system may have some non-functional requirements — we have to know what non-functional requirements do we have and what they mean.

Performance

Performance refers to how fast and effectively a system can complete its tasks, handle user requests, process data, and deliver results.

Latency and throughput

Latency and throughput are two important concepts related to performance. They represent different aspects of data transfer and processing.

Latency: Latency refers to the amount of time it takes for a data packet or signal to travel from its source to its destination. It is often measured in milliseconds (ms). Latency can be influenced by various factors, including network congestion, distance, processing time, and communication protocols.

Latency may be divided logically into server latency, network latency, and client latency. Each of them may have different reasons, but we will not dive so deep right now.

Throughput: Throughput, on the other hand, refers to the rate at which a system or network can process, handle, or transmit data over a given period of time. Throughput is influenced by factors such as available bandwidth, network capacity, processing power, and data transmission protocols.

Bandwidth refers to the maximum amount of data that can be transmitted over a network. If our Throughput = our Bandwidth — the only way to increase it is to change a network.

Scalability

Scalability is the property of a system to handle a growing amount of work.

For example, the system shall support a minimum of 1000 concurrent users and handle a 20% increase in user load without significant degradation in performance.

To increase the load our system can handle we need to scale it. There are two types of scaling:
Vertical scaling:

The idea of vertical scaling — we just buy a more powerful server (more memory, more disk space, more powerful CPU or network card).

The main advantage of this approach — it’s simple. We don’t need any improvements from the architecture or development side. We just pay money and retrieve faster resources.

But at the same time, it has a lot of disadvantages. First of all — it may be expensive (and the price may grow dramatically while we continue scaling in this way. You can check it just by comparing the prices for cloud compute engines from different tiers). Another disadvantage — it’s limited. Even though nowadays servers are pretty powerful — they still have some limited resources. You are not able to add an infinitive amount of memory or disk space. Your CPU can’t be more powerful than top-level existing solutions. These limitations lead us to the next type of scaling.

Horizontal scaling:

Horizontal scaling is a more flexible approach. We don’t increase the power of each server but just increase the number of servers. This approach gives us the ability to use less expensive solutions and scale them for any load we need (theoretically).

The advantages of this approach are: it can be highly flexible (we are able even to consider auto-scaling mechanism using it), it’s less expensive than vertical scaling (in terms of costs of hardware resources), and theoretically it doesn’t have limits.

But as everything in our world has its disadvantages: it’s more complex. Our solution should be written in a way to support horizontal scaling (stateless application code, scalable storages, load balancers, etc.). It may be too complicated (or even impossible) to scale horizontally some existing legacy system, that wasn’t designed to support it. So, if scalability is one of the properties you want your system should support — design it according to a scalability requirement from the beginning.

Security

A security non-functional requirement refers to the measures and safeguards implemented to protect a system, application, or network from unauthorized access, data breaches, malicious activities, and other security risks. It outlines the security expectations and objectives that the system should meet to ensure the confidentiality, integrity, and availability of sensitive information and resources.

There are three important concepts of a security property we want to cover:

Identity and Permissions Management:

User Provisioning: It encompasses the management of user accounts, including account creation, modification, and deletion.

Authentication: It refers to the process of verifying the identity of users to ensure they are who they claim to be.

Authorization: It involves determining and enforcing the permissions and privileges that users have within the system. Access control ensures that users are granted appropriate access rights based on their roles and responsibilities.

Infrastructure Protection:

Network Security: It involves implementing firewalls, intrusion detection/prevention systems (IDS/IPS), and secure network architectures to protect networks from unauthorized access, attacks, and data breaches.

System Hardening: It refers to securing servers, workstations, and other devices by applying security configurations, patches, and updates, disabling unnecessary services, and enforcing secure configurations.

Physical Security: It encompasses physical measures such as access controls, surveillance systems, and environmental controls to protect physical infrastructure, server rooms, data centers, and other sensitive locations.

Data protection:

Secure Data Transmission: It involves implementing secure protocols (e.g., SSL/TLS) and encryption during data transmission over networks, protecting data from interception or unauthorized access during transit.

Encryption: It involves the use of encryption algorithms to transform data into an unreadable format, ensuring that even if unauthorized individuals gain access to the data, they cannot decipher its content.

Data Loss Prevention (DLP): It includes measures to prevent the accidental or intentional leakage of sensitive data. DLP solutions monitor and control data flows, enforce policies, and detect and prevent data breaches.

Data Retention: It involves defining policies and procedures for retaining data for the required duration and securely disposing of data when it is no longer needed, reducing the risk of unauthorized access or data exposure.

Data Classification: It involves categorizing data based on its sensitivity and criticality.

NOTE: You may say, that we are already so far from a solution architecture. But we believe that important to understand your infrastructure deciding the right architecture for your system.

Usability

A usability non-functional requirement refers to the ease of use, learnability, and overall user experience provided by a system, application, or product. Here are key aspects of a usability non-functional requirement:

Durability

Once data was submitted to a system, it’s not lost.

This system properties says, that we pay attention to don’t lose our data.
There are a few common practices to achieve it:

Backups: Backups involve creating copies of critical data and storing them in a separate location or medium to protect against data loss. Backup strategies may include full backups (copying all data), incremental backups (copying only changed data since the last backup), or differential backups (copying changed data since the last full backup).

RAID (Redundant Array of Independent Disks): RAID is a technique that involves combining multiple physical disks into a logical unit to improve performance, reliability, and fault tolerance.

Replications: Replication involves creating and maintaining copies of data in real-time or near real-time on separate storage systems or locations. Replications can be synchronous (where data is written to both primary and replica simultaneously) or asynchronous (where data is written to the primary system first and then replicated to the replica).

Availability

The system should respond properly 24/7…

Availability is a critical aspect of system reliability and is typically measured as a percentage of uptime over a specific time period. Here are key aspects related to system availability:

Uptime and Downtime:

Uptime refers to the period during which a system is operational and available to users. It represents the time when the system is fully functioning and providing its intended services.

Downtime refers to the period during which a system is unavailable or not functioning properly. It can be due to planned maintenance, system failures, network issues, or other factors that disrupt the system’s operation.

Service Level Agreements (SLAs):

Service Level Agreements define the expected level of system availability. It usually can be described in target percentages and there are also can be some penalties defined if the expected level of availability was not provided (for example, you will be providing some discount or even compensate all the customer losses).

Ok, let’s say we provided some numbers in our SLA. But what can we do with a system to achieve these target numbers (read as to improve our availability)

Fault Tolerance:

Fault tolerance refers to a system’s ability to continue functioning and providing services even in the presence of hardware or software failures.

Fault-tolerant systems use redundancy, error detection (monitoring and alerts) and correction mechanisms, and failover techniques to recover from failures and maintain availability.

Load Balancing:

Load balancing distributes incoming requests or workloads across multiple resources, such as servers or data centers, to optimize resource utilization and prevent overloading. Load balancing helps ensure that the system can handle high traffic or usage demands without becoming overwhelmed, improving availability and responsiveness.

So, when the number we should choose in terms of availability? Let’s ask John:

There are a few other system properties we want to describe:

Compliance:

Compliance, as a system property, refers to the adherence of a system or organization to relevant laws, regulations, industry standards, and internal policies. Here are key aspects related to the compliance system property:

Legal and Regulatory Compliance:

Organizations must comply with laws and regulations applicable to their industry, such as data protection laws, privacy regulations, financial regulations, healthcare regulations, or industry-specific standards.

Compliance involves understanding and adhering to legal requirements, such as data protection, consumer protection, intellectual property rights, anti-money laundering (AML), anti-corruption, or cybersecurity laws.

Industry Standards and Best Practices:

Compliance may also involve adherence to industry-specific standards, frameworks, or best practices that provide guidance for ensuring security, privacy, quality, or ethical considerations.

Examples include ISO standards (e.g., ISO 27001 for information security, ISO 9001 for quality management), Payment Card Industry Data Security Standard (PCI DSS), or Health Insurance Portability and Accountability Act (HIPAA) in the healthcare industry.

Data Protection and Privacy:

Compliance with data protection and privacy regulations is a significant aspect, of ensuring the lawful and ethical handling of personal or sensitive data.

Compliance measures may include implementing appropriate security controls, obtaining user consent, providing data subject rights, conducting privacy impact assessments (PIAs), and complying with data breach notification requirements.

Internal Policies and Governance:

Compliance extends to an organization’s own internal policies, standards, and procedures, ensuring that employees and stakeholders follow established guidelines and codes of conduct.

Internal policies cover areas such as information security, acceptable use of technology, data retention, employee conduct, and conflict of interest.

Third-Party Compliance:

Compliance may extend to third-party relationships, such as vendors, suppliers, or business partners. Organizations must ensure that their third parties also adhere to applicable regulations and industry standards

Maintainability:

Maintainability is a system property that refers to the ease and effectiveness with which a system can be maintained, repaired, modified, or enhanced over its lifecycle. Here are key aspects related to the maintainability system property:

Modularity and Componentization:

Maintainable systems are designed with a modular and component-based approach, where functionality is divided into self-contained units that can be easily understood, modified, or replaced.

Clear and Readable Code:

Maintainable systems have code that is well-organized, properly documented, and written in a clear and readable manner.

Documentation:

Maintainable systems have comprehensive and up-to-date documentation, including system architecture, design decisions, APIs, interfaces, and dependencies.

Documentation helps developers and maintainers understand the system’s structure, behavior, and dependencies, facilitating efficient maintenance, bug fixing, and updates.

Low Coupling and High Cohesion:

Maintainable systems minimize interdependencies between components and modules, promoting low coupling and high cohesion.

Loose coupling reduces the ripple effects of changes, allowing modifications in one component without impacting others.

High cohesion ensures that each component has a single, well-defined responsibility, making it easier to understand and modify.

Standardization and Consistency:

Maintainable systems adhere to coding standards, best practices, and design principles, promoting consistency in coding style, naming conventions, and architectural patterns.

Testability:

Maintainable systems are designed with testability in mind, enabling the efficient creation and execution of tests to validate system behavior and detect issues.

Testable systems have well-defined interfaces, clear separation of concerns, and support for automated testing frameworks.

Version Control and Configuration Management:

Maintainable systems utilize version control systems and configuration management practices to track and manage changes to the codebase, configurations, and dependencies.

Version control allows developers to roll back changes, compare versions, and collaborate effectively, while configuration management ensures consistency and traceability of system configurations.

Portability:

Portability is a system property that refers to the ease with which a software system can be transferred or adapted to different environments, platforms, or operating systems. It ensures that the system can be deployed and run effectively across diverse computing environments without significant modifications or dependencies on specific hardware or software configurations. Here are key aspects related to the portability system property:

Platform Independence:

Portable systems are designed to be platform-independent, meaning they can run on multiple operating systems or hardware architectures without requiring extensive modifications.

They minimize dependencies on specific operating system features, hardware components, or proprietary technologies that could limit their portability.

Adaptability to Different Environments:

Portable systems are adaptable to various computing environments, including on-premises infrastructure, cloud platforms, or hybrid setups.

They consider the differences in resource availability, network configurations, security policies, and scalability requirements when running in different environments.

So, we understand what our system should do (we got the functional requirements), and how the system should do it (we gathered the non-functional requirements as well). We can generate some idea of the solution, but how to present this idea to our stakeholders? Will be one common description useful for all of them? Let’s discuss it in the next article.

Next: https://medium.com/@svosh2/ad20cdc6ecd3

--

--