Non-Functional Requirements and Quality Attribute Scenarios: [System name]
Complete non-functional requirements (NFR) specification. Quality
characteristics follow the product quality model of ISO/IEC 25010:2023;
each important quality is made testable with six-part quality attribute
scenarios in the style taught by the Software Engineering Institute
(SEI), and prioritised in a utility tree. Replace every [bracketed]
value and every row marked Example.
Document control
| Field | Value |
|---|
| Document ID | [NFR-SYSTEM-001] |
| System | [System name] [release] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@architect] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |
| Related documents | [SRS / SyRS], [Architecture description], [Performance test plan], [Threat model], [SLOs] |
[release]: how well the system must perform its functions, under which
Approvals
| Role | Name | Decision | Date |
|---|
| Product owner | [@name] | [Approved / Rejected / Approved with comments] | YYYY-MM-DD |
| Lead architect | [@name] | [Decision] | YYYY-MM-DD |
| Operations / SRE lead | [@name] | [Decision] | YYYY-MM-DD |
| Security lead | [@name] | [Decision] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@name] | Initial utility tree from quality workshop |
| 0.2 | YYYY-MM-DD | [@name] | Example: Tightened QAS-PE-01 to 300 ms after load test baseline; added safety scenarios |
| 1.0 | YYYY-MM-DD | [@name] | Example: Approved with architecture baseline |
Contents
1. Introduction
1.1 Purpose and scope
This document defines the quality requirements for [System name]
[release]: how well the system must perform its functions, under which
conditions, and how that will be measured. Functional behaviour is
specified in [SRS-xxx].
1.2 Business drivers for quality
| Driver | Quality implication |
|---|
| Example: Checkout conversion drops 7% per extra second of latency | Performance efficiency is top priority for checkout |
| Example: Card data in scope of PCI DSS | Security, confidentiality and accountability are mandatory |
| Example: Three releases per week planned | Maintainability and testability must stay high |
| [Driver] | [Implication] |
1.3 Stakeholders consulted
| Stakeholder | Qualities of most concern | Workshop or source |
|---|
| Example: Product owner | Performance, interaction capability | QAW-1 |
| Example: SRE lead | Reliability, observability | QAW-1 |
| [Stakeholder] | [Qualities] | [Source] |
2. Quality model and conventions
2.1 Identifiers
- Requirements:
NFR-<char>-<nn>, for example NFR-PE-03.
- Scenarios:
QAS-<char>-<nn>, for example QAS-RE-01.
- Characteristic codes:
FS functional suitability, PE performance
efficiency, CO compatibility, IC interaction capability, RE
reliability, SE security, MA maintainability, FL flexibility, SA
safety.
2.2 Six-part scenario format
| Part | Meaning |
|---|
| Source | Who or what generates the stimulus (user, attacker, operator, timer, failing component) |
| Stimulus | The event or condition that arrives (request, fault, change request, attack) |
| Artifact | The part of the system stimulated (whole system, a service, the data store, the code base) |
| Environment | Conditions at the time (normal load, peak, degraded, during deployment) |
| Response | What the system does |
| Response measure | How the response is measured, with a threshold |
3. Quality characteristics
| Code | Characteristic | Sub-characteristics (summary) | Relevance | Notes |
|---|
| FS | Functional suitability | Functions are complete for the stated needs, give correct results, and suit the tasks users perform | [High / Medium / Low / Not significant] | [Why] |
| PE | Performance efficiency | Response and processing time, use of resources such as CPU and memory, and capacity limits under load | Example: High | Checkout latency drives revenue |
| CO | Compatibility | Coexists with other software sharing an environment, and exchanges and uses information with other systems | [Relevance] | [Why] |
| IC | Interaction capability | Users can recognise if it fits their needs, learn it, operate it, avoid and recover from errors, find it engaging, include users of all abilities, get help, and understand its behaviour | Example: High | Many first-time buyers |
| RE | Reliability | Free of faults in normal use, available when needed, tolerant of faults, and able to recover data and state after failure | Example: High | 24/7 storefront |
| SE | Security | Protects confidentiality and integrity, proves actions took place, traces actions to who did them, confirms identities, and resists attack | Example: High | Card and personal data |
| MA | Maintainability | Built from separable modules, reusable parts, easy to analyse, change and test | Example: Medium | Frequent releases |
| FL | Flexibility | Adapts to new environments, scales up or down with demand, installs easily, and can replace another product | [Relevance] | [Why] |
| SA | Safety | Avoids states that endanger people, property or the environment: limits operation when risky, fails safe, warns of hazards, and integrates safely | [Relevance] | [Why, or "Not significant: no physical actuation"] |
4. Utility tree and priorities
The tree below shows the top-level refinements; the table lists every leaf
with its rating.
| Quality | Refinement | Scenario | Importance | Difficulty | Priority |
|---|
| Performance efficiency | Latency | QAS-PE-01 Checkout response at peak | H | M | (H,M) |
| Performance efficiency | Capacity | QAS-PE-02 Sale-day traffic spike | H | H | (H,H) |
| Reliability | Availability | QAS-RE-01 Payment provider outage | H | H | (H,H) |
| Reliability | Recoverability | QAS-RE-02 Database node loss | H | M | (H,M) |
| Security | Confidentiality | QAS-SE-01 Card data exposure attempt | H | M | (H,M) |
| Security | Accountability | QAS-SE-02 Admin price change audit | M | L | (M,L) |
| Maintainability | Modifiability | QAS-MA-01 New payment method | M | M | (M,M) |
| Maintainability | Testability | QAS-MA-02 Regression suite time | M | L | (M,L) |
| Interaction capability | Learnability | QAS-IC-01 First-time checkout | H | L | (H,L) |
| Interaction capability | Inclusivity | QAS-IC-02 Screen reader checkout | H | M | (H,M) |
| [Quality] | [Refinement] | [QAS-xx-nn] | [H/M/L] | [H/M/L] | [(I,D)] |
5. Quality attribute scenarios
5.1 Performance efficiency
QAS-PE-01 Checkout response at peak
| Part | Value |
|---|
| Source | 2,000 concurrent shoppers |
| Stimulus | Submit order with payment |
| Artifact | Checkout service and its dependencies |
| Environment | Normal peak load (Friday evening), all components healthy |
| Response | Order accepted, payment authorised, confirmation shown |
| Response measure | p95 end-to-end latency at most 800 ms; p99 at most 1,500 ms; error rate below 0.1% |
QAS-PE-02 Sale-day traffic spike
| Part | Value |
|---|
| Source | Marketing campaign |
| Stimulus | Traffic rises from 300 to 3,000 requests per second within 5 minutes |
| Artifact | Storefront and checkout |
| Environment | Autoscaling enabled |
| Response | Capacity scales out; no requests dropped |
| Response measure | Scale-out complete within 3 min; p95 latency stays under 1,200 ms during ramp |
5.2 Reliability
QAS-RE-01 Payment provider outage
| Part | Value |
|---|
| Source | External payment provider |
| Stimulus | Provider returns errors or times out for all requests |
| Artifact | Payment adapter |
| Environment | Normal load |
| Response | Circuit opens; traffic fails over to secondary provider; customer sees no error |
| Response measure | Failover within 30 s; fewer than 0.5% of checkouts fail during the event |
QAS-RE-02 Database node loss
| Part | Value |
|---|
| Source | Infrastructure fault |
| Stimulus | Primary database node terminates |
| Artifact | Order database cluster |
| Environment | Peak load |
| Response | Replica promoted; writes resume |
| Response measure | Recovery time at most 60 s; zero committed orders lost (RPO = 0) |
5.3 Security
QAS-SE-01 Card data exposure attempt
| Part | Value |
|---|
| Source | External attacker with a valid customer account |
| Stimulus | Attempts to read another customer's stored payment methods through the API |
| Artifact | Account API |
| Environment | Production, normal operation |
| Response | Request denied; event logged and alerted |
| Response measure | 100% of cross-account requests denied in penetration test; alert within 1 min |
QAS-SE-02 Administrator price change audit
| Part | Value |
|---|
| Source | Administrator |
| Stimulus | Changes the price of a product |
| Artifact | Catalogue admin |
| Environment | Normal operation |
| Response | Change recorded with who, when, old and new value |
| Response measure | 100% of changes traceable to a named user; records kept 7 years |
5.4 Maintainability
QAS-MA-01 New payment method
| Part | Value |
|---|
| Source | Product team |
| Stimulus | Request to add a new wallet payment method |
| Artifact | Payment module code base |
| Environment | Design time |
| Response | Method added as a new adapter without changing checkout logic |
| Response measure | At most 10 developer-days; no change to more than 2 existing modules |
QAS-MA-02 Regression suite time
| Part | Value |
|---|
| Source | Developer |
| Stimulus | Opens a pull request |
| Artifact | CI pipeline |
| Environment | Normal CI load |
| Response | Full automated regression suite runs |
| Response measure | Completes within 15 min with flaky failure rate below 1% |
5.5 Interaction capability
QAS-IC-01 First-time checkout
| Part | Value |
|---|
| Source | First-time shopper |
| Stimulus | Buys one item as a guest |
| Artifact | Web storefront |
| Environment | Mobile phone, 4G connection |
| Response | Purchase completed without help |
| Response measure | 90% of test participants finish in under 3 min with no critical errors |
QAS-IC-02 Screen reader checkout
| Part | Value |
|---|
| Source | Shopper using a screen reader |
| Stimulus | Completes checkout |
| Artifact | Checkout pages |
| Environment | Current versions of two major screen readers |
| Response | All controls labelled, errors announced |
| Response measure | Zero WCAG 2.2 AA failures in audit; task success in assisted test |
5.6 Other characteristics
| Scenario | Characteristic | Summary | Response measure |
|---|
| QAS-CO-01 | Compatibility | Example: Order export consumed by the ERP | 100% of exports accepted by ERP schema validation |
| QAS-FL-01 | Flexibility | Example: Deploy a new region | New region live within 2 days using existing templates |
| QAS-FS-01 | Functional suitability | Example: Tax calculation | Matches tax engine reference for 1,000 sampled baskets |
| QAS-SA-01 | Safety | [Scenario or "Not significant" with reason] | [Measure] |
6. Measurement methods
| Measure | Method | Tool / source | Environment | Frequency |
|---|
| Latency percentiles | Load test with production-like traffic mix | [Load test tool] | Pre-production | Each release |
| Latency in production | Server-side histograms | [Monitoring platform] | Production | Continuous |
| Availability | Successful requests over total, per month | [Monitoring platform] | Production | Monthly |
| Recovery time | Fault injection exercise | [Chaos tool] | Staging | Quarterly |
| Security controls | Penetration test, automated scanning | [Tools] | Staging, production | Annual, per build |
| Usability | Moderated usability test, 8 to 12 participants | [Method] | Prototype or staging | Per major change |
| Accessibility | Automated audit plus manual screen reader test | [Tools] | Staging | Each release |
| Modifiability | Change effort recorded against estimate | Issue tracker | Development | Per change |
Availability is calculated as:
A=total valid requestssuccessful requests×100% A 99.9% monthly target allows an error budget of 0.001×30×24×60≈43 minutes of full outage.
7. Acceptance thresholds
| Scenario | Measure | Target | Minimum for release | Verification | Owner |
|---|
| QAS-PE-01 | p95 checkout latency | 600 ms | 800 ms | Load test PERF-01 | [@name] |
| QAS-PE-02 | Scale-out time | 2 min | 3 min | Load test PERF-04 | [@name] |
| QAS-RE-01 | Failover time | 15 s | 30 s | Chaos test CH-02 | [@name] |
| QAS-RE-02 | Recovery time, data loss | 30 s, 0 | 60 s, 0 | Chaos test CH-05 | [@name] |
| QAS-SE-01 | Cross-account denial | 100% | 100% | Pen test PT-2026 | [@name] |
| QAS-MA-02 | CI regression time | 10 min | 15 min | CI metrics | [@name] |
| QAS-IC-01 | Task success under 3 min | 95% | 90% | Usability test UT-03 | [@name] |
| [QAS-xx-nn] | [Measure] | [Target] | [Minimum] | [Method] | [@name] |
8. Traceability and trade-offs
| Scenario | Source need | Architecture decision | Test | Monitoring |
|---|
| QAS-PE-01 | BR-003 conversion | ADR-004 read-through cache | PERF-01 | Checkout latency dashboard |
| QAS-RE-01 | BR-005 revenue continuity | ADR-009 dual payment providers | CH-02 | Payment error alert |
| [QAS-ID] | [Need] | [ADR-ID] | [Test] | [Dashboard or alert] |
| Trade-off | Qualities in tension | Decision | Rationale |
|---|
| Example: Caching product prices for 60 s | Performance vs functional correctness | Accept 60 s staleness; checkout re-validates price | Latency gain outweighs rare price mismatch |
| [Trade-off] | [Qualities] | [Decision] | [Rationale] |
9. Appendices
9.1 Glossary
| Term | Definition |
|---|
| p95, p99 | 95th and 99th percentile of a measured distribution |
| RPO | Recovery point objective: maximum acceptable data loss, in time |
| Utility tree | Hierarchy that refines overall system utility into prioritised, testable scenarios |
| [Term] | [Definition] |
9.2 References
| ID | Title | Version |
|---|
| REF-01 | ISO/IEC 25010:2023 Product quality model | 2023 |
| REF-02 | Bass, Clements, Kazman, Software Architecture in Practice | [Edition] |
| REF-03 | WCAG 2.2 | 2023 |
| [REF-nn] | [Title] | [Version] |
Standard and licence note
Structure aligned with ISO/IEC 25010:2023, Systems and software
Quality Requirements and Evaluation (SQuaRE): Product quality model, for
the set of quality characteristics, and with the quality attribute
scenario and utility tree techniques published by the Software
Engineering Institute. Characteristic descriptions are summaries in
original wording. This template is original text written for this
collection and reproduces no text from the standard; obtain the standard
from ISO or IEC for its normative definitions. Template licence: MIT.