We always find having some examples can be helpful when trying to understand something, so as a follow on to our articles on Non-Functional Requirements and Writing Non-Functional Requirements we figured we'd provide some Non-Functional Requirement examples! We will use the framework we recommend, the SQuaRE model. The descriptions for the categories are from that ISO model.
As a reminder, the recommended approach is for the organization to gave a standard set of non-functional requirements. Then on each technology project, the list is refined for the specifics of the project.
The final list would then be added to the project requirements to guide the solution architecture and implementation. The refinement can be done by a project manager, if enough guidance is provided, or by a more technical resource (enterprise architect, solution architect, technical architect, lead developer, etc.).
Since the focus here is "Non-Functional" requirements, we omit the "Functional Suitability" category of the SQuaRE model, although it can be useful to include if being used for product evaluation.
Remember that we adopt a standard pattern for non-functional requirements which is: "The solution" + [priority] + [behavior]. It results in a complete sentence, like "The solution must run in a virtualized environment." When we capture and track, we omit "The solution," because is redundant as it is the same on all requirements and usually track the priority as a separate data element associated with the requirement.
The indicates categories we find most useful when creating standard enterprise non-functional requirements for technology solutions.
Performance relative to the amount of resources used under stated conditions. Resources can include other software products, the software and hardware configuration of the system, and materials (e.g. print paper, storage media).
Degree to which the response and processing times and throughput rates of a product or system, when performing its functions, meet requirements.
Complete batch job processing in under 2 hours
Respond to user action in less than 10ms in web based applications
Degree to which the amounts and types of resources used by a product or system, when performing its functions, meet requirements.
Utilize no more than 8GB of memory
Not exceed an average of 500 iops per volume for storage volumes
Degree to which the maximum limits of a product or system parameter meet requirements. Parameters can include the number of items that can be stored, the number of concurrent users, the communication bandwidth, throughput of transactions, and size of database.
Store up to 5tb of data
Support 1000 simultaneous users
Degree to which a product, system or component can exchange information with other products, systems or components, and/or perform its required functions, while sharing the same hardware or software environment.
Degree to which a product can perform its required functions efficiently while sharing a common environment and resources with other products, without detrimental impact on any other product.
Run all desktop components in a virtualized environment (VDI)
Degree to which two or more systems, products or components can exchange information and use the information that has been exchanged.
Provide a REST API Interface
Degree to which a product or system can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. We typically omit Operability and User Error Protection for Non-Functional Requirements as they lend themselves better to functional requirements.
Degree to which users can recognize whether a product or system is appropriate for their needs from initial impressions of the product or system and/or any associated documentation. The information provided by the product or system can include demonstrations, tutorials, or documentation.
Provide online training for administrators
Degree to which a product or system can be used by specified users to achieve specified goals of learning to use the product or system with effectiveness, efficiency, freedom from risk and satisfaction in a specified context of use.
Provide on screen contextual prompts that guide user on how to operate software
Degree to which a user interface enables pleasing and satisfying interaction for the user.
Be ACME branded (logo, colors, fonts)
Comply with ACME web application user interface standards
Degree to which a product or system can be used by people with the widest range of characteristics and capabilities to achieve a specified goal in a specified context of use.
Comply with WCAG 2.1
Degree to which a system, product or component performs specified functions under specified conditions for a specified period of time. We typically omit Maturity. It is useful for platform comparisons and assessments, but not as a non-functional requirement category.
Degree to which a system, product or component is operational and accessible when required for use.
Be available for end users 99.999% of the time. (aka. 5 nines)
Degree to which a system, product or component operates as intended despite the presence of hardware or software faults.
Automatically fail over to redundant environment in the event of a system failure
Degree to which, in the event of an interruption or a failure, a product or system can recover the data directly affected and re-establish the desired state of the system.
Recover from any operational disruption in less than 4 hours (24x7x365)
Be compliant with standard backup/recovery tools (Veeam, Zerto)
Support a recovery point objective of 3 minutes
Support a recovery time objective of 3 hours
Degree to which a product or system protects information and data so that persons or other products or systems have the degree of data access appropriate to their types and levels of authorization.
Degree to which a product or system ensures that data are accessible only to those authorized to have access.
Encrypt all Personally Identifiable Information (PII) at rest
Support de-identified, masked data for non-production environments
Enforce role-based access control to all screens, functions, and information
Degree to which a system, product or component prevents unauthorized access to, or modification of, computer programs or data.
Comply with the OWASP Application Security Verification Standard
Degree to which actions or events can be proven to have taken place, so that the events or actions cannot be repudiated later.
Retain a log of all security configuration changes
Degree to which the actions of an entity can be traced uniquely to the entity.
Associate all audit log entries to the user performing the activity
Degree to which the identity of a subject or resource can be proved to be the one claimed.
Authenticate all users using biometrics
Degree to which a product or system can be effectively and efficiently modified without introducing defects or degrading existing product quality. Implementation includes coding, designing, documenting and verifying changes.
Degree to which a system or computer program is composed of discrete components such that a change to one component has minimal impact on other components.
Use a micro-services architecture
Degree to which an asset can be used in more than one system, or in building other assets.
Provide a database loader that supports any ODBC database
Degree of effectiveness and efficiency with which it is possible to diagnose a product for deficiencies or causes of failures, or to identify parts to be modified.
Provide a debugging mode that logs the details for all component invocations
Degree to which a product or system can be effectively and efficiently modified without introducing defects or degrading existing product quality.
Be able to develop and deploy in a Azure DevOps environment
Degree of effectiveness and efficiency with which test criteria can be established for a system, product or component and tests can be performed to determine whether those criteria have been met.
Provide a method to track and remove test transactions.
Use persistent HTML Ids on all web interface data entry fields
Degree of effectiveness and efficiency with which a system, product or component can be transferred from one hardware, software or other operational or usage environment to another.
Degree to which a product or system can effectively and efficiently be adapted for different or evolving hardware, software or other operational or usage environments.
Execute on-premises or in a cloud-hosted environment
Provide responsive user interface (from mobile phones to 4K monitors)
Degree of effectiveness and efficiency with which a product or system can be successfully installed and/or uninstalled in a specified environment.
Support automated installation and upgrade process
Degree to which a product can replace another specified software product for the same purpose in the same environment. Replaceability will reduce lock-in risk: so that other software products can be used in place of the present one, for example by the use of standardized file formats.
Provide a method to export all data to machine readable format (XML or JSON)
Having a standard set of non-functional requirements will drive more consistency across projects and improve technology outcomes. Over time this can drive the convergence of all the solution architectures created for each project toward an overarching enterprise architecture or technology strategy. This is a pragmatic way to move the organization toward a target technology architecture incrementally. We hope the examples have been helpful, and if you'd like more assistance, drop us a line!
