We know what functional requirements are, which describe what the system should do, whereas non-functional requirements describe how the system should behave.They address various characteristics of the system for overall success but not directly related to any specific functionalities.

As mentioned above NFRs are vital for overall success of the system due to several key reasons such as:

• User Satisfaction
• System Reliability
• Performance and Scalability
• Security and Compliance
• Cost-Effectiveness
• Stakeholder Confidence
• Competitive Advantage
• Risk Mitigation

Overall, addressing NFRs ensures the quality of the system by focusing on the following key aspects. These are the main non-functional requirements to consider when designing a software system.

Performance

Response Time

Specifies the maximum acceptable time for the system to respond to user actions or requests.

Example

The system must ensure that 95% of all transactions are processed and responded to within 500 milliseconds.

Acceptance Criteria

The average response time for processing transactions should not exceed 500 milliseconds, measured over a period of one month.

At least 95% of all transactions should be completed within the specified response time limit.

Response time measurements should be taken under normal operating conditions to accurately represent real-world performance.

Throughput

Defines the number of transactions or operations the system should handle within a given timeframe.

Example

The system must support a minimum throughput of 1000 transactions per second during peak hours.

Acceptance Criteria

The system should sustain a minimum throughput of 1000 transactions per second for at least one hour during peak usage times, measured over a period of one week.
Throughput measurements should be taken under realistic load conditions to accurately represent system performance.

Resource utilisation

This refers to how effectively a system utilises its resources such as CPU, memory, disk space, network bandwidth, etc. Efficient resource utilisation ensures optimal performance without wasting resources.

Example

The system must maintain CPU utilisation below 70% and memory utilisation below 80% under normal operating conditions.

Acceptance Criteria

CPU utilisation should not exceed 70% of total available CPU capacity, as measured by system monitoring tools.

Memory utilisation should remain below 80% of total available memory, as reported by system monitoring tools.

Resource utilisation metrics should be monitored continuously, and any deviations from specified thresholds should trigger alerts for further investigation.

Security

It's crucial to address various aspects to ensure the confidentiality, integrity, and availability of the system and its data. Here are some key considerations for security NFR in a software system:

Authentication

Specifies the methods used to verify the identity of users and ensure that only authorised users can access the system.

Example

The system must implement multi-factor authentication (MFA) for user access, requiring users to provide a combination of a password and a one-time verification code sent to their registered email or mobile device.

Acceptance Criteria

Users should be required to enter their username and password to initiate the authentication process.

Upon successful entry of credentials, users should be prompted to provide a one-time verification code received via email or SMS.

Access to system resources should be granted only after successful completion of both authentication steps.

Authorisation

Defines the rules and policies governing what actions users are allowed to perform within the system.

Example

The system must enforce role-based access control (RBAC) to restrict user access to specific functionalities and data based on their assigned roles.

Acceptance Criteria

Users should be assigned roles or permissions that determine their level of access to system functionalities and data.

Access to sensitive data or privileged operations should be restricted to authorised users with the appropriate role or permission level.

Unauthorised access attempts should be denied, and appropriate error messages or notifications should be generated to alert users and administrators.

Data Encryption

Ensures that sensitive data is encrypted during transmission and storage to prevent unauthorised access or interception.

Example

The system must encrypt sensitive data stored in databases and transmitted over networks using industry-standard encryption algorithms and protocols.

Acceptance Criteria

Sensitive data, including personally identifiable information (PII) and financial data, should be encrypted before being stored in databases or persisted to disk.

Data transmitted over network connections should be encrypted using secure communication protocols such as TLS (Transport Layer Security).

Encryption keys and cryptographic algorithms used for data encryption should comply with industry best practices and regulatory requirements.

Audit-ability

Specifies logging and auditing requirements to track user activities, system events, and security breaches.

Example

The system must maintain comprehensive audit logs to track user activities, system events, and data access for accountability and regulatory compliance purposes.

Acceptance Criteria

The system should generate audit logs for all user authentication and authorisation events, including successful and failed login attempts, password changes, and access control decisions.

Audit logs should capture system events such as configuration changes, software updates, and system restarts to facilitate system monitoring and troubleshooting.

Data access events, including reads, writes, and deletions of sensitive data, should be logged to track changes and detect unauthorised access or data breaches.

Compliance

Ensures that the system complies with relevant security standards, regulations, and industry best practices (e.g., GDPR, HIPAA, PCI DSS).

Example

The system must comply with relevant industry standards, regulations, and legal requirements, including GDPR (General Data Protection Regulation) for European users and HIPAA (Health Insurance Portability and Accountability Act) for healthcare data.

Acceptance Criteria

The system should implement privacy by design principles and data protection measures to comply with GDPR requirements for handling personal data of European users.

Access to sensitive healthcare information should be restricted to authorised personnel and comply with HIPAA requirements for safeguarding protected health information (PHI).

Regular audits and assessments should be conducted to verify compliance with relevant standards and regulations, with documented evidence of compliance maintained for audit purposes.

Usability

User Interface Design

Specifies requirements for the layout, navigation, and visual design of the user interface to ensure ease of use and accessibility.

Example

The system's user interface (UI) must adhere to modern design principles, including simplicity, consistency, and responsiveness, to enhance user experience and usability.

Acceptance Criteria

The user interface should feature a clean and uncluttered layout with intuitive navigation elements, such as menus, buttons, and links, to guide users through the system's functionalities.

Design elements, such as colour schemes, typography, and visual hierarchy, should be consistent across all screens and components to provide a cohesive and visually appealing user experience.

The user interface should be responsive and adaptable to different screen sizes and devices, including desktop computers, tablets, and mobile phones, to accommodate users' diverse preferences and usage scenarios.

Accessibility

Ensures that the system is usable by people with disabilities and complies with accessibility standards (e.g., WCAG).

Example

The system must comply with WCAG 2.1 (Web Content Accessibility Guidelines) Level AA standards to ensure accessibility for users with disabilities.

Acceptance Criteria

The system's user interface (UI) must be perceivable, operable, understandable, and robust, as defined by WCAG 2.1 Level AA success criteria.
All non-text content, such as images, videos, and multimedia, must include alternative text descriptions to provide equivalent information to users who cannot perceive visual content.

Interactive elements, such as forms, buttons, and navigation menus, must be keyboard accessible and operable using assistive technologies, such as screen readers and voice recognition software.

Internationalisation and Localisation

Specifies requirements for adapting the system to different languages, cultures, and regions.

Example

The system must support internationalisation (i18n) and localisation (l10n) to enable users from different regions and language preferences to access and use the system in their preferred language and cultural conventions.

Acceptance Criteria

The system's user interface (UI) must be designed and implemented using internationalisation best practices to support seamless translation and adaptation to different languages and locales.

Textual content, including user interface labels, messages, and documentation, must be externalised and stored in resource files to facilitate translation and localisation efforts.

The system must provide support for locale-specific formats, such as date, time, currency, and number formatting, to accommodate regional preferences and conventions.

Maintainability

Modularity

Encourages the use of modular, loosely coupled components that can be easily modified, replaced, or extended.

Example

The system must be designed with a modular architecture that allows for the independent development, deployment, and maintenance of discrete components or modules.

Acceptance Criteria

The system architecture should be modular, with clearly defined boundaries between components or modules.

Each module should encapsulate a specific set of functionalities or services, with well-defined interfaces for communication with other modules.

Modules should be loosely coupled, minimising dependencies between them to allow for easier modification or replacement without impacting other parts of the system.

Documentation

Specifies requirements for documenting system architecture, design decisions, codebase, APIs, and user manuals to aid maintenance and support.

Example

The system must be accompanied by comprehensive documentation that provides clear and concise guidance on system architecture, design, configuration, deployment, and usage.

Acceptance Criteria

The system documentation should include architectural diagrams, component descriptions, and system interfaces to provide an overview of system structure and design.

Installation guides, configuration manuals, and deployment instructions should be provided to assist system administrators in setting up and configuring the system in various environments.

User manuals, tutorials, and training materials should be available to guide end-users in using the system's functionalities effectively and efficiently.

Testability

Ensures that the system is designed for ease of testing, with clear test cases, automated testing frameworks, and diagnostic tools.

Example

The system must be designed and implemented to facilitate effective testing, including unit testing, integration testing, and system testing, to ensure software quality and reliability.

Acceptance Criteria

The system should be modular, with well-defined interfaces and clear separation of concerns, to enable unit testing of individual components in isolation.

Integration points and dependencies between system components should be well-documented and designed to facilitate integration testing and validation of system interactions.

Test cases and test data should be provided to cover all functional and non-functional requirements, with automated testing tools and frameworks used to streamline testing processes.

Reliability

Availability

Specifies the percentage of time the system should be operational and accessible to users.

Example

The system must maintain a minimum availability of 99.9% during normal operating hours, excluding scheduled maintenance windows.

Acceptance Criteria

The system should be accessible and operational for at least 99.9% of the time during normal operating hours, as measured over a one-month period.

Downtime for scheduled maintenance activities should be communicated to users in advance, and maintenance windows should be scheduled during off-peak hours to minimise disruption.

Fault Tolerance

Defines the system's ability to continue operating despite hardware or software failures.

Example

The system must demonstrate fault tolerance by ensuring continued operation and minimal disruption in the event of hardware failures, software errors, or network outages.

Acceptance Criteria

The system should be designed with redundancy and failover mechanisms to mitigate the impact of hardware failures, such as disk failures, server crashes, or network outages.

Critical system components should be monitored continuously for errors or failures, with automated detection and recovery mechanisms implemented to restore service quickly and minimise disruption.

Recovery procedures should be documented and tested regularly to ensure that they can be executed effectively in the event of failures or disasters.

Recoverability

Describes how quickly and effectively the system can recover from failures and restore normal operations.

Example

The system must support efficient and reliable recovery processes to restore service and data integrity in the event of system failures, errors, or disasters.

Acceptance Criteria

The system should implement backup and restore procedures to enable regular and automated backups of critical data and system configurations.

Recovery time objectives (RTOs) and recovery point objectives (RPOs) should be defined and documented for different system components and data sets, specifying the maximum allowable downtime and data loss tolerances.

Disaster recovery plans and procedures should be documented, tested, and regularly updated to ensure readiness and effectiveness in responding to catastrophic events or system failures.

Data Integrity

Ensures the accuracy, consistency, and reliability of data stored and processed by the system.

Example

The system must ensure the accuracy, consistency, and reliability of data stored and processed within the system, maintaining data integrity throughout its lifecycle.

Acceptance Criteria

The system should implement data validation mechanisms to ensure that incoming data meets predefined integrity constraints, such as data type, format, and range checks.

Data integrity checks should be performed regularly to detect and prevent data corruption or unauthorised modifications, with mechanisms in place to log and alert on integrity violations.

Backup and recovery procedures should be implemented to protect against data loss and corruption, with regular backups performed to facilitate data restoration in the event of failures or disasters.

Backup and Disaster Recovery

Specifies procedures and mechanisms for backing up data and restoring the system in case of catastrophic events.

Example

The system must implement robust backup and disaster recovery mechanisms to ensure data protection, minimise downtime, and facilitate rapid recovery in the event of system failures, data corruption, or disasters.

Acceptance Criteria

The system should implement automated backup procedures to regularly and securely back up critical data, configurations, and system state to redundant storage locations.

Backup data should be encrypted and stored offsite in geographically diverse locations to protect against localised disasters, such as fires, floods, or earthquakes.

Disaster recovery plans and procedures should be documented, tested, and regularly updated to ensure readiness and effectiveness in responding to catastrophic events or system failures.

Scalability

Vertical scalability

The system should be able to handle a growing number of users or transactions by adding more resources such as CPU, memory, or storage.

Example

The system must support vertical scalability to accommodate increases in workload and resource demands by scaling up individual hardware components, such as CPU, memory, and storage, as needed.

Acceptance Criteria

The system architecture should be designed to support vertical scalability, with components and services designed to utilise available hardware resources efficiently and effectively.

Vertical scaling mechanisms, such as dynamic resource allocation, load balancing, and auto-scaling, should be implemented to manage resource utilisation and ensure optimal performance under varying workload conditions.

Performance testing and benchmarking should be conducted to validate the system's vertical scalability and identify scalability limits and bottlenecks.

Horizontal scalability

The system should support adding more instances or nodes to distribute the load and accommodate increased demand.

Example

The system must support horizontal scalability to accommodate increases in workload and resource demands by adding or removing additional instances of software components or nodes in a distributed architecture.

Acceptance Criteria

The system architecture should be designed to support horizontal scalability, with components and services designed to be stateless and horizontally scalable.

Horizontal scaling mechanisms, such as load balancing, sharding, and partitioning, should be implemented to distribute workload evenly across multiple instances or nodes and avoid single points of failure.

Performance testing and benchmarking should be conducted to validate the system's horizontal scalability and identify scalability limits and bottlenecks.

Interoperability

Integration with external systems

The system should be able to communicate and exchange data with other systems using standardised protocols or APIs.

Example

The system must support seamless integration with external systems, including third-party applications, databases, APIs, and services, to facilitate data exchange, interoperability, and collaboration.

Acceptance Criteria

The system should provide standardised interfaces, protocols, and APIs to enable interoperability and communication with external systems using industry-standard integration patterns and technologies.

Integration points and data exchange formats should be well-documented and defined to facilitate integration efforts and ensure compatibility with external systems.

Performance and scalability considerations should be taken into account when designing integration mechanisms to ensure efficient and reliable data exchange under varying workload conditions.

Compatibility

The system should be compatible with different operating systems, browsers, and devices to ensure seamless interoperability.

Example

The system must be compatible with a range of hardware, software, and operating system configurations to ensure interoperability and seamless deployment across diverse environments.

Acceptance Criteria

The system should be compatible with commonly used web browsers, including Google Chrome, Mozilla Firefox, Microsoft Edge, and Safari, across multiple versions and platforms.

Compatibility with popular operating systems, such as Windows, macOS, Linux, and mobile operating systems (e.g., iOS, Android), should be verified and documented.

The system should support integration with standard protocols, APIs, and communication mechanisms to enable interoperability with third-party applications, services, and platforms.

Summary

By addressing these non-functional requirements effectively, system designers and developers can ensure that the system meets the desired quality attributes and performs reliably and efficiently in its operational context.