Skip to main content - The eBook-Shop with Checklists and Templates for Professionals
logo ITCL
Skip main navigation
Template Systems Operations ManualTemplate Data Centre Operations ManualData Migration ChecklistNonfunctional RequirementsApplication Interface (EAI) Checklist Server Upgrade / Migration ChecklistApplication Upgrade / Migration ChecklistApplication & Server Inventory TemplateRelease ChecklistOutage PlanningApplication RetirementApplication Health checkArchiving RequirementsDisaster Recovery (DR) Technology SelectionBackup OLA / SLADatabase OLA / SLADBA Job DescriptionDatabase Health CheckStandby Database
The author of this template bears following credentials:
OCP 9i Logo
OCP 10g Logo
Logo ITIL green
Application SupportData MigrationOLA / SLA Operations Level AgreementSystem DocumentationProject ManagementDeploymentQuality AssuranceCompliance and StandardsDatabase AdministrationStart-up PhaseAchieving Operational ReadinessStabilized Operations

This free info-page provides 10 Examples of Non-Functional Requirements (NFR's).

10 Examples for Non-Functional Requirements

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
  • 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
Back to top

[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.

[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
  • 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:
  • 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.
Design Pattern: Resilience
  • 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
  • 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
but users observe service interruption because the application needs to be restarted, because the application (or the applications configuration and deployment) does not utilize transparent fail-over features offered by database systems.
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: