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.
Document control
| 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
1. Introduction
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
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
| 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
| 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
| 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
| 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
| 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
| 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
| 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
| 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
| 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
| 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
| 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
| 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
| 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
| 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
| 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
| 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
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
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.