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.
Top comments (0)