# NFR Catalogue: [Solution or product name]

> Register of the non-functional requirements (NFRs) of one solution:
> every quality, operational, compliance and cost requirement written as a
> measurable statement with a target, a minimum acceptable value, a
> priority, a source, an owner and a verification method. Categories
> follow the product quality model of ISO/IEC 25010:2023 (nine
> characteristics), extended with operability, compliance and cost; the
> requirement attributes and verification methods follow
> ISO/IEC/IEEE 29148:2018. Replace every `[bracketed]` value and every row
> marked *Example*.

<!--
Guidance: How to use this template
- Use this catalogue as the single list of NFR IDs for the solution. The
  High-Level Design (`architecture/high-level-design`) allocates these
  IDs to components, Low-Level Designs (`architecture/low-level-design`)
  implement them and the test plans verify them.
- For the few qualities that drive the architecture, also write
  six-part scenarios and a utility tree in Quality Attributes
  (`requirements/quality-attributes`), and link the scenario ID in the
  register. This catalogue is the complete register; that template is
  the deep analysis of the top items.
- Write each NFR so that a tester could fail it. "Fast", "secure",
  "scalable" and "user friendly" are not requirements until they have a
  metric, a condition and a number.
- Fill sections 2 and 3 first (conventions and categories), then
  section 5 (register summary), then one category section at a time with
  the stakeholder who owns it. Keep section 16 (measurement definitions)
  in step: two teams measuring latency differently is a common source of
  disputes at acceptance.
- For legal and regulatory items in section 14, this is a documentation
  format, not legal advice.
-->

## Document control

<!-- Guidance: Identify the solution and the baseline. Once the catalogue is baselined, every change goes through section 19 and bumps the version. -->

| Field | Value |
|---|---|
| Document ID | [NFR-CAT-001] |
| Solution | [Solution or product name] |
| Version | [0.1] |
| Status | [Draft / In review / Baselined / Superseded] |
| Owner | [@solution-architect] |
| Approvers/reviewers | [@product-owner], [@security-architect], [@service-owner], [@qa-lead], [@data-protection-officer] |
| Baseline date | YYYY-MM-DD |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential] |
| Related documents | [SAD ID], [HLD ID], [Quality attribute scenarios ID], [Test strategy ID] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Product owner | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Solution architect | [@name] | [Decision] | YYYY-MM-DD |
| Security architect | [@name] | [Decision] | YYYY-MM-DD |
| Service owner (operations) | [@name] | [Decision] | YYYY-MM-DD |
| Quality lead | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft from discovery workshops |
| 0.9 | YYYY-MM-DD | [@name] | *Example:* Targets agreed with service owner and security |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Baselined for release 1 |

## Contents

<!-- Guidance: Keep this list aligned with the headings. Delete a category section only when you record in section 3 why it is not significant. -->

1. [Introduction](#1-introduction)
2. [Conventions](#2-conventions)
3. [Categories and relevance](#3-categories-and-relevance)
4. [Sources and stakeholders](#4-sources-and-stakeholders)
5. [Register summary](#5-register-summary)
6. [Performance efficiency](#6-performance-efficiency)
7. [Reliability, availability and recovery](#7-reliability-availability-and-recovery)
8. [Security and privacy](#8-security-and-privacy)
9. [Interaction capability and accessibility](#9-interaction-capability-and-accessibility)
10. [Compatibility and integration](#10-compatibility-and-integration)
11. [Maintainability and flexibility](#11-maintainability-and-flexibility)
12. [Functional suitability and safety](#12-functional-suitability-and-safety)
13. [Operability, observability and support](#13-operability-observability-and-support)
14. [Compliance, data and legal](#14-compliance-data-and-legal)
15. [Cost and sustainability](#15-cost-and-sustainability)
16. [Measurement definitions](#16-measurement-definitions)
17. [Verification plan](#17-verification-plan)
18. [Traceability matrix](#18-traceability-matrix)
19. [Change control and change log](#19-change-control-and-change-log)
20. [Glossary and references](#20-glossary-and-references)

## 1. Introduction

<!-- Guidance: State the scope, the release the targets apply to and the business drivers that justify the hardest targets. Pitfall: copying targets from another system, which either over-engineers or under-protects this one. -->

### 1.1 Purpose and scope

This catalogue lists the non-functional requirements that [Solution name]
must meet for [release or date]. It covers [the systems and channels in
scope] and excludes [items out of scope, for example the shared identity
platform, whose NFRs are owned by the identity team].

### 1.2 Business drivers for the targets

| Driver | Consequence for NFRs |
|---|---|
| *Example:* Peak trading on [two sale events] per year with 10x normal order volume | Capacity and elasticity targets in section 6 are sized for event peak, not average |
| *Example:* Order capture outage costs about [amount] per hour | Availability and recovery targets in section 7 |
| *Example:* Personal data of customers in [jurisdictions] | Privacy, retention and residency rows in sections 8 and 14 |
| *Example:* Public-facing service subject to accessibility law | Accessibility rows in section 9 |
| [Driver] | [Consequence] |

## 2. Conventions

<!-- Guidance: Fix the ID format, the attributes every NFR carries, the priority scheme and the verification methods once, so every row reads the same way. -->

### 2.1 Identifiers

`NFR-<category code>-<NNN>`, for example `NFR-PE-001`. Codes are listed
in section 3. IDs are never reused; a withdrawn NFR keeps its ID with the
status Withdrawn.

### 2.2 Attributes of each NFR

| Attribute | Content |
|---|---|
| ID and title | Stable identifier and a short name |
| Statement | One requirement per row, written with "shall", naming the condition and the measurable response |
| Metric | What is measured, defined in section 16 |
| Target | Value the design aims for |
| Minimum | Value below which the release is not accepted (may equal the target) |
| Priority | Must, Should, Could (for this release); Won't items are kept as Deferred |
| Source | Stakeholder, regulation, contract, policy or scenario that gives rise to it |
| Rationale | Why this number, in one line |
| Verification | Inspection, analysis, demonstration or test, with the stage |
| Owner | Person accountable for agreeing and accepting it |
| Status | Proposed, Agreed, Baselined, Verified, Deferred, Withdrawn |

### 2.3 Quality checks for each statement

Before an NFR is agreed, confirm that it: is needed by a named source; is
a single requirement rather than several joined by "and"; has one
meaning for every reader; states the conditions (load, environment,
period) under which it applies; can be met with the technology and budget
available; can be verified by one of the four methods; does not
contradict another NFR; and says what is required rather than how to
build it, unless a constraint fixes the how.

### 2.4 Verification methods

| Method | Use when | Typical evidence |
|---|---|---|
| Inspection | The property is visible in documents, configuration or code | Review record, configuration scan |
| Analysis | The property follows from models or calculation | Capacity model, threat model, cost model |
| Demonstration | The property is shown by operating the system without measurement | Witnessed walkthrough, recorded session |
| Test | The property is measured under controlled conditions | Load test report, failover test report, scan results |

## 3. Categories and relevance

<!-- Guidance: Walk through every category and decide whether it is significant for this solution. Descriptions are plain-language summaries; consult the standard for its definitions and sub-characteristics. -->

| Code | Category | Basis | Summary | Relevance | Section |
|---|---|---|---|---|---|
| PE | Performance efficiency | ISO/IEC 25010:2023 | Response time, throughput, resource use, capacity | *Example:* High | 6 |
| RE | Reliability | ISO/IEC 25010:2023 | Faultlessness, availability, fault tolerance, recoverability | *Example:* High | 7 |
| SE | Security | ISO/IEC 25010:2023 | Confidentiality, integrity, non-repudiation, accountability, authenticity, resistance | *Example:* High | 8 |
| IC | Interaction capability | ISO/IEC 25010:2023 | Learnability, operability by users, error protection, inclusivity and accessibility | *Example:* High | 9 |
| CO | Compatibility | ISO/IEC 25010:2023 | Coexistence and information exchange with other systems | *Example:* Medium | 10 |
| MA | Maintainability | ISO/IEC 25010:2023 | Modularity, reusability, analysability, modifiability, testability | *Example:* Medium | 11 |
| FL | Flexibility | ISO/IEC 25010:2023 | Adaptability, scalability, installability, replaceability (replaces portability of the 2011 edition) | *Example:* Medium | 11 |
| FS | Functional suitability | ISO/IEC 25010:2023 | Completeness, correctness and appropriateness of functions | *Example:* Medium | 12 |
| SA | Safety | ISO/IEC 25010:2023 | Avoiding harm to people, property or the environment | *Example:* Not significant: no physical actuation | 12 |
| OP | Operability and support | Extension | Monitoring, deployment, support hours, runbooks | *Example:* High | 13 |
| CP | Compliance and data | Extension | Laws, regulations, contracts, retention, residency | *Example:* High | 14 |
| CT | Cost and sustainability | Extension | Run cost, unit cost, energy and carbon | *Example:* Medium | 15 |

Quality in use (beneficialness, freedom from risk and acceptability in a
context of use) is modelled separately in ISO/IEC 25019:2023, which
replaces the quality-in-use model of ISO/IEC 25010:2011; record any
quality-in-use targets under IC or FS with the context of use stated.

## 4. Sources and stakeholders

<!-- Guidance: Every NFR needs a source. List where requirements came from so that an NFR without a source can be challenged or removed. -->

| Source ID | Source | Type | Contact | NFR categories |
|---|---|---|---|---|
| SRC-01 *(Example)* | Service owner interview, YYYY-MM-DD | Stakeholder | @service-owner | RE, OP |
| SRC-02 *(Example)* | Information security policy v[x] | Policy | @ciso-office | SE |
| SRC-03 *(Example)* | Data protection impact assessment, DPIA (`compliance/dpia`) | Assessment | @dpo | SE, CP |
| SRC-04 *(Example)* | Partner contract schedule [x], response times | Contract | @partner-manager | PE, CO |
| SRC-05 *(Example)* | Quality attribute workshop scenarios | Workshop | @solution-architect | PE, RE, MA |
| SRC-06 *(Example)* | Accessibility law applicable to [jurisdiction] | Law | @legal | IC, CP |
| [SRC-NN] | [Source] | [Type] | [@contact] | [Codes] |

## 5. Register summary

<!-- Guidance: One line per NFR so the whole catalogue fits on one screen. Details sit in the category sections. Sort by ID. -->

| ID | Title | Priority | Status | Owner | Verification | Scenario |
|---|---|---|---|---|---|---|
| NFR-PE-001 *(Example)* | Order submission latency | Must | Baselined | @product-owner | Test | QAS-PE-01 |
| NFR-PE-002 *(Example)* | Peak throughput | Must | Baselined | @service-owner | Test | QAS-PE-02 |
| NFR-PE-003 *(Example)* | Order history page load on mobile | Should | Agreed | @product-owner | Test | Not applicable |
| NFR-PE-004 *(Example)* | Daily price file import duration | Must | Baselined | @service-owner | Test | Not applicable |
| NFR-PE-005 *(Example)* | Automatic scale to event peak | Should | Agreed | @service-owner | Test | Not applicable |
| NFR-RE-001 *(Example)* | Order capture availability | Must | Baselined | @service-owner | Test and analysis | QAS-RE-01 |
| NFR-RE-002 *(Example)* | Order data recovery objectives | Must | Baselined | @service-owner | Test | QAS-RE-02 |
| NFR-RE-003 *(Example)* | Ordering survives notification provider failure | Must | Baselined | @service-owner | Test | Not applicable |
| NFR-RE-004 *(Example)* | No lost or duplicated orders | Must | Baselined | @service-owner | Test | Not applicable |
| NFR-SE-001 *(Example)* | Input validation | Must | Baselined | @security-architect | Test | Not applicable |
| NFR-SE-002 *(Example)* | Order-level authorisation | Must | Baselined | @security-architect | Test | Not applicable |
| NFR-SE-003 *(Example)* | Encryption of personal data | Must | Baselined | @security-architect | Inspection | Not applicable |
| NFR-SE-004 *(Example)* | No secrets in code, images or logs | Must | Baselined | @security-architect | Inspection | Not applicable |
| NFR-SE-005 *(Example)* | Application security verification level | Must | Baselined | @security-architect | Test and inspection | Not applicable |
| NFR-SE-006 *(Example)* | Attributable staff changes | Must | Baselined | @security-architect | Test | Not applicable |
| NFR-SE-007 *(Example)* | Purpose limitation of personal data | Must | Agreed | @data-protection-officer | Inspection | Not applicable |
| NFR-IC-001 *(Example)* | Web accessibility conformance | Must | Agreed | @product-owner | Test | QAS-IC-02 |
| NFR-IC-002 *(Example)* | EN 301 549 conformance where EU rules apply | Must | Agreed | @product-owner | Test | Not applicable |
| NFR-IC-003 *(Example)* | Unassisted first checkout | Should | Agreed | @product-owner | Test | QAS-IC-01 |
| NFR-IC-004 *(Example)* | Interface languages | Must | Agreed | @product-owner | Inspection | Not applicable |
| NFR-CO-001 *(Example)* | Browser support matrix | Must | Baselined | @qa-lead | Test | Not applicable |
| NFR-CO-002 *(Example)* | API backward compatibility | Must | Baselined | @solution-architect | Test | Not applicable |
| NFR-CO-003 *(Example)* | Warehouse event schema conformance | Must | Baselined | @integration-lead | Test | Not applicable |
| NFR-MA-001 *(Example)* | Independent component deployment | Should | Agreed | @solution-architect | Analysis | Not applicable |
| NFR-MA-002 *(Example)* | New channel without core change | Should | Agreed | @solution-architect | Analysis | QAS-MA-01 |
| NFR-MA-003 *(Example)* | Component test suite duration | Could | Proposed | @engineering-lead | Test | Not applicable |
| NFR-FL-001 *(Example)* | No provider-specific code in services | Should | Agreed | @solution-architect | Inspection | Not applicable |
| NFR-FL-002 *(Example)* | Environment from code | Should | Agreed | @platform-lead | Demonstration | Not applicable |
| NFR-FS-001 *(Example)* | Monetary precision | Must | Baselined | @finance-lead | Test | Not applicable |
| NFR-SA-001 *(Example)* | Safety not significant | Not applicable | Baselined | @solution-architect | Inspection | Not applicable |
| NFR-OP-001 *(Example)* | Journey failure detection | Must | Baselined | @service-owner | Test | Not applicable |
| NFR-OP-002 *(Example)* | Zero-downtime deployment | Must | Baselined | @service-owner | Test | Not applicable |
| NFR-OP-003 *(Example)* | Runbook per alert | Must | Baselined | @service-owner | Inspection | Not applicable |
| NFR-OP-004 *(Example)* | Around-the-clock priority 1 support | Must | Baselined | @service-owner | Inspection | Not applicable |
| NFR-OP-005 *(Example)* | End-to-end correlation ID | Should | Agreed | @sre-lead | Test | Not applicable |
| NFR-CP-001 *(Example)* | Data residency | Must | Baselined | @data-protection-officer | Inspection | Not applicable |
| NFR-CP-002 *(Example)* | Order record retention and anonymisation | Must | Baselined | @data-protection-officer | Test | Not applicable |
| NFR-CP-003 *(Example)* | Data subject requests on time | Must | Baselined | @data-protection-officer | Demonstration | Not applicable |
| NFR-CP-004 *(Example)* | No card data in scope | Must | Baselined | @security-architect | Inspection | Not applicable |
| NFR-CT-001 *(Example)* | Run cost per thousand orders | Should | Proposed | @finops-lead | Analysis | Not applicable |
| NFR-CT-002 *(Example)* | Non-production scale to zero | Could | Proposed | @finops-lead | Inspection | Not applicable |
| NFR-CT-003 *(Example)* | Quarterly emissions report | Could | Proposed | @sustainability-lead | Inspection | Not applicable |
| [NFR-XX-NNN] | [Title] | [Priority] | [Status] | [@owner] | [Method] | [QAS ID] |

## 6. Performance efficiency

<!-- Guidance: State latency as a percentile over a defined window and load, throughput at a defined mix, and resource limits where they matter. Pitfall: an average latency target, which hides the slow tail that users notice. -->

| ID | Statement | Metric | Target | Minimum | Priority | Source | Verification |
|---|---|---|---|---|---|---|---|
| NFR-PE-001 *(Example)* | Order submission shall complete within the target at peak load | p95 server-side latency of POST /orders, M-01 | 600 ms | 800 ms | Must | SRC-05 | Load test in pre-production at peak mix |
| NFR-PE-002 *(Example)* | The solution shall sustain event peak throughput without breaching NFR-PE-001 | Orders per second sustained for 60 min | 60 | 50 | Must | SRC-01 | Load test |
| NFR-PE-003 *(Example)* | Order history pages shall render within the target on a mid-range mobile device | Largest Contentful Paint at p75 of field data, M-03 | 2.0 s | 2.5 s | Should | SRC-05 | Field monitoring after launch, lab test before |
| NFR-PE-004 *(Example)* | Daily price file import shall finish before the trading day starts | Elapsed time of the batch job | 20 min | 45 min | Must | SRC-04 | Test with full-size file |
| NFR-PE-005 *(Example)* | Capacity shall scale from normal to event peak without manual intervention | Time to reach peak capacity from baseline | 10 min | 15 min | Should | SRC-01 | Test |
| [NFR-PE-NNN] | [Statement] | [Metric] | [Target] | [Minimum] | [Priority] | [Source] | [Method] |

## 7. Reliability, availability and recovery

<!-- Guidance: Give availability per user journey, not per server, with the measurement window and exclusions. Pair every recovery objective with the data that must be recovered. Pitfall: promising more availability than the dependencies offer. -->

| ID | Statement | Metric | Target | Minimum | Priority | Source | Verification |
|---|---|---|---|---|---|---|---|
| NFR-RE-001 *(Example)* | Order capture shall be available to customers within the target each calendar month, excluding announced maintenance | Successful synthetic and real order requests over valid requests, M-02 | 99.95 % | 99.9 % | Must | SRC-01 | SLO reporting, analysis of dependency availability |
| NFR-RE-002 *(Example)* | After loss of the primary region, order data shall be recovered within the objectives | RPO and RTO measured in a failover test | RPO 1 min, RTO 30 min | RPO 5 min, RTO 1 h | Must | SRC-01 | Failover test every six months |
| NFR-RE-003 *(Example)* | Failure of the notification provider shall not prevent orders from being placed | Order success rate during injected provider failure | No change | No change | Must | SRC-05 | Fault injection test |
| NFR-RE-004 *(Example)* | No accepted order shall be lost or duplicated through retries or failover | Reconciliation of orders accepted against orders stored | 0 differences | 0 differences | Must | SRC-01 | Test and daily reconciliation |
| [NFR-RE-NNN] | [Statement] | [Metric] | [Target] | [Minimum] | [Priority] | [Source] | [Method] |

For scale: 99.9 % over a 30-day month allows about 43 minutes of
unavailability; 99.95 % allows about 22 minutes. Check that the product of
the availability of all serial dependencies supports the minimum before
agreeing it, including external providers on the request path.
*Example:* for order capture the High-Level Design
(`architecture/high-level-design`) lists five serial dependencies
(gateway 99.99 %, Order service 99.98 %, Payment orchestrator 99.98 %,
database 99.99 %, payment provider 99.97 %); the product is about
99.91 %, which supports the 99.9 % minimum but not the 99.95 % target,
so the gap is recorded as an open issue rather than hidden. Design response: Resilience Tiering and HA/DR Design
(`architecture/resilience-tiering-ha-dr-design`).

## 8. Security and privacy

<!-- Guidance: State security outcomes and the verification standard, not product choices. Link the threat model and the DPIA as sources. Pitfall: "the system shall be secure", or a list of tools instead of requirements. -->

| ID | Statement | Metric | Target | Minimum | Priority | Source | Verification |
|---|---|---|---|---|---|---|---|
| NFR-SE-001 *(Example)* | All external input shall be validated against a published schema and size limit before processing | Share of operations with schema validation | 100 % | 100 % | Must | SRC-02 | Inspection of contracts, security test |
| NFR-SE-002 *(Example)* | A user shall only read or change orders they own or are authorised for by role | Cross-account access attempts that succeed in test | 0 | 0 | Must | SRC-02 | Authorisation test suite |
| NFR-SE-003 *(Example)* | Personal data shall be encrypted at rest and in transit | Stores and interfaces without encryption | 0 | 0 | Must | SRC-03 | Configuration inspection |
| NFR-SE-004 *(Example)* | No secret shall be stored in source code, images or logs | Secrets found by scanning | 0 | 0 | Must | SRC-02 | Pipeline secret scan |
| NFR-SE-005 *(Example)* | The application shall meet the organisation's application security verification level | Open findings at or above the level | 0 high, 0 critical | 0 critical | Must | SRC-02 | Verification against OWASP ASVS 5.0.0 level [2] and penetration test |
| NFR-SE-006 *(Example)* | Every change made by staff to customer orders shall be attributable to a named person and reason | Audited changes over total staff changes | 100 % | 100 % | Must | SRC-02 | Test and log review |
| NFR-SE-007 *(Example)* | Personal data shall be collected only for the purposes in the privacy notice | Fields without a documented purpose | 0 | 0 | Must | SRC-03 | Inspection against the DPIA |
| [NFR-SE-NNN] | [Statement] | [Metric] | [Target] | [Minimum] | [Priority] | [Source] | [Method] |

Threat analysis: Threat Model (`security/threat-model`); privacy
analysis: Privacy Threat Model (`security/privacy-threat-model`).

## 9. Interaction capability and accessibility

<!-- Guidance: Name the user groups and contexts, and fix the accessibility conformance target to a published standard and level. Pitfall: accessibility left to the end, when fixing it means redesign. -->

| ID | Statement | Metric | Target | Minimum | Priority | Source | Verification |
|---|---|---|---|---|---|---|---|
| NFR-IC-001 *(Example)* | Customer web and mobile web pages shall conform to WCAG 2.2 level AA | Open failures of level A and AA success criteria | 0 | 0 | Must | SRC-06 | Automated scan plus manual audit, Accessibility Audit (`quality/accessibility-audit`) |
| NFR-IC-002 *(Example)* | Where EU rules apply, the service shall meet the applicable clauses of EN 301 549 | Applicable clauses failed | 0 | 0 | Must | SRC-06 | Audit against the current EN 301 549 version |
| NFR-IC-003 *(Example)* | A first-time customer shall complete checkout without help | Task completion rate in moderated usability test with [8] participants | 90 % | 80 % | Should | SRC-05 | Usability test |
| NFR-IC-004 *(Example)* | User interface text shall be available in [languages] | Untranslated strings at release | 0 | 0 | Must | SRC-01 | Inspection |
| [NFR-IC-NNN] | [Statement] | [Metric] | [Target] | [Minimum] | [Priority] | [Source] | [Method] |

Checklist for design reviews: Accessibility Checklist
(`design/accessibility-checklist`).

## 10. Compatibility and integration

<!-- Guidance: Record which systems, versions, browsers and devices must work, and the contract rules for interfaces. -->

| ID | Statement | Metric | Target | Minimum | Priority | Source | Verification |
|---|---|---|---|---|---|---|---|
| NFR-CO-001 *(Example)* | The web front end shall support the current and previous major versions of [browsers] | Critical journeys passing on the support matrix | 100 % | 100 % | Must | SRC-01 | Cross-browser test |
| NFR-CO-002 *(Example)* | Published APIs shall stay backward compatible within a major version | Breaking changes detected by contract diff | 0 | 0 | Must | SRC-04 | Contract test in pipeline |
| NFR-CO-003 *(Example)* | The solution shall exchange order data with the warehouse system using the agreed event schema | Messages rejected by the consumer for schema reasons | 0 | 0 | Must | SRC-04 | Integration test |
| [NFR-CO-NNN] | [Statement] | [Metric] | [Target] | [Minimum] | [Priority] | [Source] | [Method] |

## 11. Maintainability and flexibility

<!-- Guidance: Turn "easy to change" into measurable change cost, build time or test coverage of the parts that change most. -->

| ID | Statement | Metric | Target | Minimum | Priority | Source | Verification |
|---|---|---|---|---|---|---|---|
| NFR-MA-001 *(Example)* | A change to a single component shall be deployable to production independently | Components needing coordinated release | 0 | 0 | Should | SRC-05 | Analysis of pipeline design |
| NFR-MA-002 *(Example)* | A new sales channel shall be added without changing the order service code | Lines changed in order service for channel onboarding | 0 | Configuration only | Should | SRC-05 | Analysis, then demonstration at next channel |
| NFR-MA-003 *(Example)* | The full automated test suite of a component shall run within the target | Pipeline test stage duration | 10 min | 20 min | Could | SRC-05 | Pipeline metrics |
| NFR-FL-001 *(Example)* | The solution shall run on the corporate container platform without provider-specific code in the services | Provider SDK calls outside adapters | 0 | 0 | Should | Technology standards | Code inspection, architecture test |
| NFR-FL-002 *(Example)* | A new environment shall be created from code | Elapsed time from request to working environment | 2 h | 1 day | Should | SRC-01 | Demonstration |
| [NFR-MA-NNN] | [Statement] | [Metric] | [Target] | [Minimum] | [Priority] | [Source] | [Method] |

## 12. Functional suitability and safety

<!-- Guidance: Keep functional requirements in the functional specification; record here only correctness and precision qualities that apply across functions, and any safety requirement with its hazard source. -->

| ID | Statement | Metric | Target | Minimum | Priority | Source | Verification |
|---|---|---|---|---|---|---|---|
| NFR-FS-001 *(Example)* | Monetary amounts shall be calculated without rounding error beyond the currency's minor unit | Differences against reference calculations | 0 | 0 | Must | Finance policy | Test with reference data set |
| NFR-SA-001 *(Example)* | Not significant for this solution: no physical actuation and no safety function | Not applicable | Not applicable | Not applicable | Not applicable | Section 3 | Inspection at each release |
| [NFR-FS-NNN] | [Statement] | [Metric] | [Target] | [Minimum] | [Priority] | [Source] | [Method] |

## 13. Operability, observability and support

<!-- Guidance: Capture what the run teams need: support hours, deployment frequency and safety, monitoring coverage and the time to detect and restore. These are often missed because no user asks for them. -->

| ID | Statement | Metric | Target | Minimum | Priority | Source | Verification |
|---|---|---|---|---|---|---|---|
| NFR-OP-001 *(Example)* | A failed customer journey shall be detected before customers report it | Time from first failure to alert | 5 min | 10 min | Must | SRC-01 | Fault injection test |
| NFR-OP-002 *(Example)* | Production deployments shall need no downtime | Customer-visible errors during deployment | 0 | 0 | Must | SRC-01 | Test in pre-production, release records |
| NFR-OP-003 *(Example)* | Each alert shall have a runbook | Alerts without runbook | 0 | 0 | Must | SRC-01 | Inspection |
| NFR-OP-004 *(Example)* | Priority 1 incidents shall be supported around the clock | Support coverage hours | 24x7 | 24x7 | Must | SRC-01 | Inspection of support rota |
| NFR-OP-005 *(Example)* | Logs, metrics and traces shall share a correlation ID across all components | Requests traceable end to end in sample | 100 % | 95 % | Should | SRC-05 | Test |
| [NFR-OP-NNN] | [Statement] | [Metric] | [Target] | [Minimum] | [Priority] | [Source] | [Method] |

Related: Observability Specification (`ops/observability-spec`), SLO
Document (`dev/slo-doc`), Service Level Agreement
(`ops/service-level-agreement`).

## 14. Compliance, data and legal

<!-- Guidance: Name the law, regulation, contract clause or policy and the article or section that creates each requirement. Paraphrase; do not quote. This is a documentation format, not legal advice: confirm each row with your legal or compliance function and check the consolidated text. -->

| ID | Statement | Metric | Target | Minimum | Priority | Source | Verification |
|---|---|---|---|---|---|---|---|
| NFR-CP-001 *(Example)* | Customer personal data shall be stored and processed only in [approved regions] | Stores or processors outside approved regions | 0 | 0 | Must | Data residency policy, DPIA | Inspection, Data Residency and Sovereignty Assessment (`compliance/data-residency-sovereignty-assessment`) |
| NFR-CP-002 *(Example)* | Order records shall be retained for [7] years and personal fields anonymised afterwards | Records past retention with personal data | 0 | 0 | Must | [Tax or commercial law, article] | Test of retention job, inspection |
| NFR-CP-003 *(Example)* | A data subject request for access or erasure shall be fulfilled within the legal deadline | Requests completed on time | 100 % | 100 % | Must | [Privacy law, article] | Demonstration, records |
| NFR-CP-004 *(Example)* | Card data shall not be stored, processed or transmitted by the solution | Card data found in scope scans | 0 | 0 | Must | PCI DSS scoping decision | Inspection, PCI DSS Scoping and Segmentation (`compliance/pci-dss-scoping-segmentation`) |
| [NFR-CP-NNN] | [Statement] | [Metric] | [Target] | [Minimum] | [Priority] | [Source and article] | [Method] |

## 15. Cost and sustainability

<!-- Guidance: Put a ceiling on run cost and, where the organisation reports it, on energy or emissions. A unit cost (per order, per user) survives growth better than a monthly total. -->

| ID | Statement | Metric | Target | Minimum | Priority | Source | Verification |
|---|---|---|---|---|---|---|---|
| NFR-CT-001 *(Example)* | Run cost shall stay within the unit cost agreed in the business case | Cloud and licence cost per thousand orders, monthly | USD [x] | USD [y] | Should | Business case | Analysis of billing data, FinOps Cost Review (`ops/finops-cost-review`) |
| NFR-CT-002 *(Example)* | Non-production environments shall scale to zero outside working hours | Non-production compute hours outside working hours | 0 | 10 % of baseline | Could | FinOps policy | Inspection of schedules |
| NFR-CT-003 *(Example)* | Estimated emissions of the solution shall be reported each quarter | Reports produced | 4 per year | 4 per year | Could | Sustainability policy | Inspection, Sustainability Architecture Assessment (`architecture/sustainability-architecture-assessment`) |
| [NFR-CT-NNN] | [Statement] | [Metric] | [Target] | [Minimum] | [Priority] | [Source] | [Method] |

## 16. Measurement definitions

<!-- Guidance: Define each metric once: what counts, where it is measured, over what window, and what is excluded. Reference these IDs in the metric column above. -->

| ID | Metric | Definition | Measured at | Window | Exclusions |
|---|---|---|---|---|---|
| M-01 *(Example)* | Server-side latency percentile | Time from request received at the gateway to last byte sent, per operation | Gateway telemetry | Rolling 5 min in tests, 28 days in production | Requests rejected for authentication or rate limits |
| M-02 *(Example)* | Journey availability | Valid requests answered without server error within the latency minimum, divided by valid requests | Gateway and synthetic probes | Calendar month | Announced maintenance windows up to [4] hours per month |
| M-03 *(Example)* | Largest Contentful Paint at p75 | Browser field metric collected by the site's own monitoring | Real user monitoring | 28 days | Bots, sessions without consent where required |
| [M-NN] | [Metric] | [Definition] | [Where] | [Window] | [Exclusions] |

Measurement guidance in the SQuaRE series: ISO/IEC 25023:2016 gives
product quality measures; check iso.org for the revision in progress.

## 17. Verification plan

<!-- Guidance: Plan when and how each NFR is verified, by whom and in which environment, so that acceptance is not left to the last week. -->

| NFR ID | Method | Stage | Environment | Tool or activity | Evidence | Responsible |
|---|---|---|---|---|---|---|
| NFR-PE-001 *(Example)* | Test | System test and pre-release | Pre-production | Load test PT-01, Performance Test Plan (`quality/performance-test-plan`) | Test report | @performance-lead |
| NFR-RE-002 *(Example)* | Test | Pre-release, then every six months | Production-like | Failover exercise, Game Day Plan (`ops/game-day-plan`) | Exercise report | @sre-lead |
| NFR-SE-005 *(Example)* | Test and inspection | Each release | Test | Security verification and penetration test (`security/pentest-report`) | Findings report | @security-architect |
| NFR-IC-001 *(Example)* | Test | Each sprint and pre-release | Test | Automated scan and manual audit | Audit report | @qa-lead |
| NFR-CT-001 *(Example)* | Analysis | Monthly after launch | Production | Cost report | Monthly review | @finops-lead |
| [NFR ID] | [Method] | [Stage] | [Environment] | [Activity] | [Evidence] | [@owner] |

Overall test approach: Test Strategy (`quality/test-strategy`).

## 18. Traceability matrix

<!-- Guidance: Trace each NFR backwards to its source and forwards to the design element and the test. An NFR without a forward trace is either not designed for or not tested. -->

| NFR ID | Source | Scenario | Design element (HLD) | Decision | Test | Result |
|---|---|---|---|---|---|---|
| NFR-PE-001 *(Example)* | SRC-05 | QAS-PE-01 | HLD section 9, CMP-001 to CMP-003 | ADR-004 | PT-01 | [Pass / Fail / Not run] |
| NFR-RE-002 *(Example)* | SRC-01 | QAS-RE-02 | HLD section 11 | ADR-002 | DR-01 | [Result] |
| NFR-SE-002 *(Example)* | SRC-02 | Not applicable | LLD-002 section 12 | Not applicable | ST-ORD-03 | [Result] |
| [NFR ID] | [SRC] | [QAS] | [Element] | [ADR] | [Test] | [Result] |

Full requirements traceability: Traceability Matrix
(`requirements/traceability-matrix`).

## 19. Change control and change log

<!-- Guidance: After baseline, any change to a target, minimum or priority needs the owner's approval and an impact note on design, cost and schedule. Record every change here. -->

Change rules: [a request is raised with the NFR ID, the proposed value,
the reason and the impact; the owner and the solution architect approve;
Must items also need the product owner and, for SE and CP, the security
or compliance owner; approved changes are applied to the HLD allocation
within one sprint]. Formal process: Change Control
(`project/change-control`).

| Change ID | Date | NFR ID | Change | Reason | Impact | Approved by |
|---|---|---|---|---|---|---|
| CHG-001 *(Example)* | YYYY-MM-DD | NFR-PE-001 | Minimum relaxed from 600 ms to 800 ms; target stays 600 ms | Payment provider latency measured in spike | HLD allocation of 700 ms p95 now fits the minimum with 100 ms headroom; ADR-004 caps payment intent latency; no cost change | @product-owner |
| CHG-002 *(Example)* | YYYY-MM-DD | NFR-IC-002 | Added | New market in the EU | Accessibility audit scope widened | @product-owner |
| [CHG-NNN] | YYYY-MM-DD | [NFR ID] | [Change] | [Reason] | [Impact] | [@name] |

## 20. Glossary and references

<!-- Guidance: Define terms and list the sources with the version and the date checked. -->

### 20.1 Glossary

| Term | Meaning |
|---|---|
| NFR | Non-functional requirement: how well the system performs its functions, or a constraint on how it is built or run |
| Target and minimum | The aimed-for value and the lowest value accepted for release |
| Percentile (p95) | The value below which 95 % of measurements fall |
| RTO and RPO | Maximum tolerated time to restore service and maximum tolerated data loss, measured in time |
| SLO | Service level objective: internal reliability target measured from telemetry |
| Quality in use | Quality experienced by users in a specific context, as opposed to product quality |
| [Term] | [Meaning] |

### 20.2 References

| ID | Reference | Version or date | Use |
|---|---|---|---|
| REF-01 | ISO/IEC 25010:2023, Product quality model | Edition 2, November 2023 | Categories in section 3 |
| REF-02 | ISO/IEC 25019:2023, Quality-in-use model | Edition 1, November 2023 | Quality-in-use characteristic names in section 3 |
| REF-03 | ISO/IEC 25002:2024, Quality models overview and usage | 2024 | Use of quality models |
| REF-04 | ISO/IEC 25023:2016, Measurement of system and software product quality | 2016; revision in progress | Measurement definitions |
| REF-05 | ISO/IEC/IEEE 29148:2018, Requirements engineering | 2018; Edition 3 at draft stage | Attributes, statement checks, verification methods |
| REF-06 | W3C Web Content Accessibility Guidelines 2.2 | W3C Recommendation, October 2023 | NFR-IC-001 |
| REF-07 | ETSI EN 301 549, Accessibility requirements for ICT products and services | V4.1.1 (2026-09) | NFR-IC-002 |
| REF-08 | OWASP Application Security Verification Standard | 5.0.0, May 2025 | NFR-SE-005 |
| REF-09 | [Internal policies and contracts] | [Version] | Sources in section 4 |

## Standard and licence note

Structure aligned with ISO/IEC 25010:2023 (product quality
characteristics), ISO/IEC 25019:2023, ISO/IEC 25002:2024 and
ISO/IEC 25023:2016 (quality in use, quality models and measures) and
ISO/IEC/IEEE 29148:2018 (requirement attributes, characteristics of good
requirements and verification methods). Only characteristic names and
clause topics are used, with plain-language summaries; no definitions,
tables or other text are reproduced from ISO, IEC or IEEE standards.
WCAG 2.2, EN 301 549 and the OWASP ASVS are referenced by name and level
only. Edition 3 of ISO/IEC/IEEE 29148 is in development: check iso.org
for the current edition before use, and obtain the standards for their
normative requirements. Legal and regulatory rows are a documentation
format, not legal advice. This template is original text written for
this collection. Template licence: MIT.