This free info-page provides 10 Examples of Non-Functional Requirements (NFR's).
10 Examples for Non-Functional Requirements
- Time of servers and other devices shall be synchronized to a reliable reference time.
- Scalability: Processing throughput of batch jobs shall increase when adding CPU's
- Parameters and reference data can be changed online
- Log files shall be rotated (e.g. weekly, daily or hourly)
- The application shall include archiving and purging.
- Terminated jobs can be resumed close to point of termination
- Monitoring License Limits and Alerting
- The Application shall support Online-Backup
- The Application shall support Transparent Fail-over
- "Carry Forward" of Customizations & Extensions
Background Information about Non-Functional Requirements (NFR's) is provided in Non-Functional Requirements.
[NFR.1] Time of servers and other devices shall be synchronized to a reliable reference time.
NFR-Group: Environment
Threat:
- Time differences between servers may cause wrong results, especially when computing durations based on time stamps of servers with time differences.
- Reconciliation may show differences even if processing was correct and complete.
Design Pattern: Time synchronization, ntp, xntp
Testing this requirement:
- Check the log files of the time synchronization utilities.
- Check the time differences
[NFR.2] Scalability: Processing throughput of batch jobs shall increase when adding CPU's
NFR-Group: Performance, Scalability
Threat: The batch job is executed by a one single-threaded process only and cannot utilize more than one CPU. Once your batch job
reaches the maximum allowed duration, you are in troubles because adding more CPU's will not help.
Design Pattern: Work load partitioning, multi-process and/or multi-threaded architecture within application components.
Testing: Scalability testing as part of performance testing.
Comment: Details about vertical and horizontal scalability in Scalability Requirements
[NFR.3] Changes of frequent changed parameters and reference data shall be possible online, not requiring application restart.
NFR-Group: Operability, Continuous Availability, High Availability (HA)
Threat:Not meeting availability - SLA due to required planned outages.
Design Patterns:
- Signal handling to enable processes to re-read (cached) parameters.
- Cache Purging
Testing:Change a parameter that supports online-change, and check if the new value is being used.
Comment:This requirement is valid for operating systems, infrastructure software like RDBMS and applications.
It is unlikely that all parameters can support this requirement; on operating systems (kernel parameters) and database parameters the need for online-change is rather seldom.
It is important to understand which types of reference data and application parameters are expected to change frequently, e.g. adding / changing promotion codes, tariffs, currencies, tax rates, extending a country-list.
It is unlikely that all parameters can support this requirement; on operating systems (kernel parameters) and database parameters the need for online-change is rather seldom.
It is important to understand which types of reference data and application parameters are expected to change frequently, e.g. adding / changing promotion codes, tariffs, currencies, tax rates, extending a country-list.
[NFR.4] Log files shall be rotated (e.g. weekly, daily or hourly)
NFR-Group: Operability - Log file management
Threat: Logfiles growing indefinitely;
- No cut-off point for archiving after defined time.
- Huge log files are difficult to view / analyse.
- Huge log files might be difficult to submit to vendor in case of an incident to be investigated.
Design Pattern: File processing
Testing:
- A new log file with different name is being created
- The new log file is being used; no records added to old log file.
Monitoring: The daily / weekly job to rotate log files shall be monitored for
- Errors and terminations
- Not started
Comments: Compression of log files (e.g. a few days later) and archiving of log files are additional, separate requirements. The "rotation" of log-files is a pre-requisite for both.
[NFR.5] The application shall include archiving and purging.
NFR-Group: Operability
Threat: Your data are growing and the performance degrades but the application does not provide a tool to archive and remove old data.
Design Pattern:
Monitoring:
- Errors and terminations
- Not started
- Not exceeding defined job duration
[NFR.6] After termination long-running jobs can be resumed.
NFR-Group: Operability, Resilience
Threat: A 6-hour batch job terminates after 5 hours. It can't continue at (or near) point of termination and must be started again at zero.
Impact: The SLA for nightly batch processing will be missed.
Impact: The SLA for nightly batch processing will be missed.
Design Pattern: Resilience
Testing:
- Review operations manual for clear description how to resume a terminated batch process. Are manual back-out steps required? - Or just start it again? - Does a protection against double-processing of same transaction exist?
- Are manual back-out (revoke) steps required? - Or just start it again?
- Does a protection against double-processing of same transaction exist? (Duplicate-Prevention)
- Kill a running batch job and test resuming the batch job.
Monitoring: Monitoring batch jobs and alerting will trigger manual activity (restarting).
[NFR.7] Monitoring License Limits and Alerting
NFR-Group: Monitoring, Licensing
Threat:Your application stops working because reaching a license limit
Design Pattern: Operations Design: Capacity / License Monitoring and Management
Monitoring: Capacity- and License Reporting, and Monitoring of those reports
Testing:
- Test Cases: Identify License Limits (Transactions/second, GB/TB Data- or Backup volume, Number of Users, ...)
- Test Execution: Check if monitor reports approaching the License limit, and if Alerts are sent.
Comment: Some applications write warnings into the logfile, but without logfile monitoring you won't detect it.
[NFR.8] The Application shall support Online-Backup
NFR-Group: Availability
Threat:You need a daily shut-down of application for backup, because the application stores data outside of database (e.g. in normal files) or uses a database system not supporting online backup.
Design Pattern: Design for Availability
Testing: Backup and Recovery Testing
[NFR.9] The Application shall support Transparent Fail-over.
NFR-Group: High Availability (HA), Continuous Availability
Threat: You paid for
- two or more servers, for
- additional database software option to support active/active cluster
You paid a lot, but did not get what you expected.
Design Pattern: High Availability - Transparent Application Fail-over.
Monitoring: Monitoring should be able to differentiate between a limited number of errors during a limited period and a complete application crash.
Testing: HA-Testing
[NFR.10] "Carry Forward" of Customizations & Extensions
NFR-Group: Maintainability
Threat: Customizations & Extensions are wiped out at next upgrade.
Design Pattern: Release Management, Extensibility
Monitoring: N/A
Testing: Implement and deploy a customization, conduct a version upgrade and check if the customization is still available.
More than 270 Non-Functional Requirements
are provided in our template dedicated to this important topic:
Non-Functional Requirements