Non-Functional Requirements Definition | Template Download
10 min read
Non-functional requirements (NFRs) need to capture, in detail, all non-functional behavior of the delivered solution from various perspectives. Additionally, they capture acceptance criteria which should be used to validate each requirement. A significant amount of time can be spent defining them, which may initially not seem like a worthwhile investment. However, given a number of issues which can be avoided by having clear NFRs, it is highly recommended to dedicate and prioritize this activity.
Table of Contents
Assumptions should be documented in each non-functional requirement. They help state the standard around which the non-functional requirement has been defined. They are relevant to express the basis upon which the NFR is to be tested, or to communicate elements that could impact the non-functional behavior of the solution. When creating this section in a NFR, the assumptions can be expressed as a list in a high-level (non-detailed) format.
Consider including information on:
- Assumptions made during the estimation of infrastructure sizing and # CPU's
- Production environment infrastructure
- High-level testing approach, e.g. warm-up periods
- Who provides the initial test data, and who continues to maintain it
Definitions can be used to outline concepts that are referenced in Assumptions and the NFRs document. They can be used to define:
- Scope definition: what is in-scope and out-of-scope for some or all NFRs
- Ways to measure specific NFRs
- Typical datasets, customer sets or user journeys which can be referenced by NFRs
They can be used to include key aspects which impact peak performance of the storefront and back-office:
- Breakdown of page types, order types, and customer types. This can be referenced to a separate performance load model if one is available.
- How the key metrics are measured, e.g. page response time, batch execution time.
- Breakdown of daily backoffice and data load activities which impact batch job execution. Examples include:
- Number of changes through feeds which can impact Solr indexing duration
- Number of cockpit changes which impact the synchronization duration
They can be used to add common concepts which are referenced by NFRs. For example:
- Description of each customer type
- Description of each data model type which has Capacity type NFRs
This is specifically important for new data models or new concepts which are custom created for the customer.
Non-Functional Requirements (NFRs)
Contains the list of NFRs and their related acceptance criteria. It is important to group NFRs in a standard way. The categories from the attached sample and template are based on the ISO 25010 Product Quality Model standard, as this ensures that no aspect of the system is missed.
Define out of scope
It is equally important to specify areas where no requirements have been defined. This avoids scope arguments and discussions whether an issue is a defect or a change.
For example, if there is no maximum limit for CPU utilization during a peak test, document it:
|ISO Characteristic||ISO Subcharacteristic||Non-functional Requirement Description|
|Performance efficiency||Resource utilization||No requirements have been defined for Resoruce utilization|
This suggests the following categorization:
- Functional suitability:
- The degree to which a product or system provides functions that meet stated and implied needs when used under specified conditions
- Sub-characteristics: functional completeness, correctness, and appropriateness
- Not included in NFRs as covered by functional requirements
- Performance efficiency:
- Performance relative to the number of resources used under the stated conditions
- Sub-characteristics: capacity, time behavior, resources utilization
- Define maximum values for the total number of items which will be
stored in the SAP Commerce Cloud database as this impacts database performance. For example, total
number of orders or products. Large data can also slow down storefront or batch performance
depending on the filtering logic used.
- Make a clear difference between the total number of products, which may include old or archived ones, and active products.
- Capture all custom data models which are not OOTB.
- Include the high-level specifications of the system, like number of sites, catalogs, languages.
- Consider that some metrics may require different NFRs for maximum and average. Specifically for items with relationships. For example, order lines in an order.
- Define metrics which capture the data complexity, like product relationships, product attributes, categories and catalog depth.
- Define maximum values of user journey criteria which will be used for
creating performance testing scripts, including:
- Number of order lines in an order.
- Reference definitions for the breakdown of customers, order types, and page types.
- Instead of concurrent users, which can be interpreted by business users differently, define concurrent user sessions as measured by the number of active JSESSIONS in SAP Commerce Cloud. This measurement is much preferred as it can be measured and monitored more easily.
- Define maximum values for incremental changes, like:
- catalog or pricing updates.
- custom data imports and integration points according to specific schedules (daily, hourly, etc).
- Include maximum number of orders and page views in a period of time (second, minute or hour), against a specific load type which should be defined.
- Define maximum values for the total number of items which will be stored in the SAP Commerce Cloud database as this impacts database performance. For example, total number of orders or products. Large data can also slow down storefront or batch performance depending on the filtering logic used.
NFRs in this category should reference a specific load type from Definitions.
Page Response Times:
- Maximum response times should be measured using a specific percentile of users (e.g. 90th percentile), and never for all users.
- Time measurements should exclude:
- Communication between user browser and the first layer of the solution (e.g. Akamai cache server/Varnish cache server/load balancer/web-server).
- Download time for static files if a Content Distribution Network is used in Production.
- Calls to 3rd parties, like payment providers. Mocks can be used during performance tests to exclude these delays.
- Decide if page requests include AJAX requests, static files or are HTML only. Content delivered by the solution should be included in the original page request time.
- Add separate response times and concurrent users for back office applications (e.g. Cockpits).
Typical and/or peak content should be described in Definitions.
Define duration for each synchronization type (e.g. product, price, availability) for a standard mix synchronization job.
Define duration for full synchronization. This should depend on the documented total volumes.
Define duration of full index based on the standard catalog contents.
Define duration of incremental indexing, based on the standard incremental index job contents.
Based on specific client requirements, add performance against specific volumes for integration points, like batch stock updates and batch availability updates.
Define hardware and software resource utilization metrics that should not be exceeded while the system is running at its maximum capacity. For example, CPU or memory.
Assumptions should be clear on the lack of background jobs running during these measurements. For example, Solr indexing or catalog synchronization.
Detail the specific versions of software or applications, including minor versions and processor architecture (32 bit vs 64 bit). Even minor version changes of referenced libraries or external applications (e.g. mySQL, Apache HTTPD) can have major performance impacts. Distinguish between:
- Co-existence: software applications, hardware appliances, operating systems, which may impact the
solution. It is good practice to document:
- Versions of applications delivered with SAP Commerce Cloud: Solr, Tomcat.
- Versions of applications that will support the solution: DB, operating system, Java version.
- Hardware details, if applicable, to distinguish virtualized environments from native ones.
- Interoperability: details on restrictions to integrate with other systems.
- Co-existence: software applications, hardware appliances, operating systems, which may impact the solution. It is good practice to document:
- The 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.
- Sub-characteristics: appropriateness recognizability, learnability, operability, user error protection, user interface aesthetics, accessibility.
- The degree to which a system, product or component performs specified functions under specified conditions for a specified period of time.
- Sub-characteristics: maturity, availability, fault tolerance,
Availability: If defined, this section needs to be clear on any SLAs, and how they are defined and measured.
- Fault tolerance: Consider documenting the solution behavior, if any, in case external systems which provide core functionality are not available.
- Critical section to document. This is where the solution needs to be isolated from risks which are outside the solution. This section documents specific critical data which transit the solution's boundaries, and how it will be handled (e.g. credit card data).
- The degree to which a product or system protects information and data. This is done so that persons, or other products or systems, have the degree of data access appropriate to their types and levels of authorization.
- Sub-characteristics: confidentiality, integrity, non-repudiation, accountability, authenticity.
- The degree of effectiveness and efficiency with which a product or system can be modified by the intended maintainers.
- Sub-characteristics: modularity, reusability, analyzability, modifiability, testability.
- The 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.
- Sub-characteristics: adaptability, installability, replaceability.
Adaptability: Key items to include are the supported:
- browsers, including versions and mobile/tablet support
- window size and color depth
Download the Non-Functional Requirements Template
Non-Functional Requirements are a crucial part of requirements overall, and while they are more technical in nature, they still need to be established and business representatives can often have important inputs specific to their business. Not meeting the NFRs can have legal and warranty implications. Therefore the NFRs need to be complet, detailed and testable, as much as possible.