Non-Functional Requirements for Commerce: The ISO 25010 Catalog That Prevents Scope Fights

Functional requirements say what the system does; non-functional requirements say whether it is fit to run in production, and they are where commerce projects quietly go wrong. Nobody argues about whether checkout should work; everyone argues, at the worst possible time, about whether a 3-second page load under peak is a defect or acceptable, because nobody wrote it down. A good NFR catalog turns those arguments into references, and the trick the CX Works template teaches is to structure it against the ISO 25010 product-quality model so that no quality dimension is silently forgotten. This guide is that catalog for a commerce context, plus the two disciplines (testable definitions and explicit out-of-scope) that make NFRs worth writing at all.

Why NFRs Prevent Fights#

An NFR is a quality requirement with an acceptance criterion: not "the site should be fast" but "product page 95th-percentile response time under 800ms at peak load defined in the load model." The value is not the aspiration; it is the measurable line that settles the future dispute. NFRs are agreed and signed off during the Explore phase (the delivery framework guide) and amended only through change control, precisely because they are the contract against which UAT and go/no-go are judged. Vague NFRs are worse than none, because they create the illusion of agreement while leaving the real number to be fought over during launch week.

The Foundations: Assumptions and Definitions#

Before the requirements themselves, two sections make them testable:

Assumptions capture the conditions under which the NFRs hold or are tested, kept high-level:

• Sizing and CPU-count assumptions behind the infrastructure estimate.
• The production environment shape the numbers assume.
• The testing approach (warm-up periods, load model).
• Who provides the initial test data, and who maintains it. (This one is quietly load-bearing: an NFR you cannot test because nobody owns the test data is an NFR in name only.)

Definitions outline the concepts the NFRs reference, so the requirements can be terse and precise:

• Scope definitions (what is in and out of scope for specific NFRs).
• How each NFR is measured (page response time, batch execution time).
• The typical datasets, customer types, and user journeys the NFRs reference. This is where you break down page types, order types, and customer types, ideally tied to a performance load model, and where you document the daily back-office and data-load activities that affect batch windows (feed volumes driving Solr indexing duration, cockpit change counts driving synchronization duration).

Defining customer types, data-model types, and journeys once, up front, is what lets an NFR say "under Customer Type B on the Peak Journey" without re-explaining itself. This matters most for the new, custom concepts a specific customer introduces, which have no shared definition to fall back on.

The Catalog, by ISO 25010 Characteristic#

Structuring by ISO 25010 ensures completeness. The characteristics and how they land for commerce:

• Functional suitability (completeness, correctness, appropriateness): covered by functional requirements, so noted as out-of-scope for the NFR document rather than duplicated.
• Performance efficiency (capacity, time behavior, resource utilization): the heart of a commerce NFR catalog.
  • Capacity: maximum item counts the database will hold, because volume drives database and storefront and batch performance. Define maximum total products and distinguish active from archived, because filtering logic behaves differently on each; likewise maximum orders, customers, price rows. These numbers size the database tier and the retention strategy (the data maintenance guide).
  • Time behavior: response-time targets per page type per load level, batch-window durations (import, sync, indexing must complete inside their windows), and integration latencies. Tied to the load model, with percentiles not averages (the performance engineering guide's discipline).
  • Resource utilization: CPU and memory ceilings under peak, if you set them.
• Compatibility (co-existence, interoperability): the integration contracts and the environments the solution must run alongside.
• Usability: accessibility standards (WCAG level), browser and device support matrix, the interaction requirements that are quality lines rather than features.
• Reliability (maturity, availability, fault tolerance, recoverability): the availability target (and thus the DR and backup expectations, the Cloud Portal ops guide), the recovery-time and recovery-point objectives, graceful-degradation requirements (the storefront must render when the recommendation service is down, the recommendations guide).
• Security: the hardening and compliance requirements as testable criteria (the security hardening and data protection guides), authentication strength, penetration-test pass criteria.
• Maintainability (modularity, reusability, analyzability, modifiability, testability): code quality gates (the coding standards guide), test coverage minimums, the observability that makes the system analyzable (the logging and Dynatrace guides).
• Portability (adaptability, installability, replaceability): usually light on CCv2 (the platform owns much of it), but the deployment and environment-parity requirements live here.

Not every project needs every subcharacteristic, but walking the whole model forces the explicit decision "we have no requirement here" rather than the silent omission that becomes a defect argument.

The Underrated Discipline: Document Out-of-Scope#

The template's sharpest advice, and the one teams skip: explicitly document where no requirement is defined. If there is no maximum CPU-utilization target during peak testing, write a row that says so:

This one row prevents a launch-week argument about whether 95% CPU under peak is a defect. The absence of a requirement, stated explicitly, is itself a decision, and stating it is what stops "is this a defect or a change request?" from becoming a contractual dispute. An NFR document that only lists requirements leaves every unlisted dimension as ammunition for a future fight; one that also lists the deliberate non-requirements closes those fights before they start.

Checklist#

• NFRs written as measurable acceptance criteria, agreed and signed off in Explore
• Assumptions section: sizing basis, production shape, test approach, test-data ownership
• Definitions section: measurement methods, customer/data/journey types, load model reference
• Catalog walked against all ISO 25010 characteristics; every one decided (requirement or explicit none)
• Capacity NFRs distinguish total from active data; batch windows have duration targets
• Time-behavior in percentiles tied to the load model, not averages
• Out-of-scope dimensions documented explicitly to prevent defect-versus-change disputes
• NFRs feed the performance, security, and go/no-go testing as their pass criteria

Non-functional requirements are the least glamorous document in the project and the one that decides whether the go/no-go meeting is a formality or a brawl. Write them against the full quality model, make each one testable, and document what you deliberately left out, and the arguments that would have happened during launch week happen instead in a calm Explore-phase workshop, which is exactly where you want them.