sdlc-nfr-spec

name	sdlc-nfr-spec
description	Use to define measurable NFRs for performance, reliability, security, privacy, accessibility, observability, and operations.
metadata	{"version":"0.5","updated":"2026-07-26"}

NFR Spec

Use this workflow when a software feature, system, release, or integration needs measurable non-functional requirements.

NFRs are quality and constraint requirements. They must be explicit, measurable where possible, and connected to validation. They should not be left as vague claims inside a PRD or SRS.

When an NFR changes architecture, it must be resolved before or during HLD. Do not leave performance, reliability, security, privacy, observability, or compatibility constraints as late implementation notes if they affect module boundaries, data flow, trust boundaries, deployment shape, or rollback strategy.

Use when

• A requirement mentions performance, security, privacy, reliability, availability, scalability, compatibility, accessibility, maintainability, compliance, monitoring, logging, auditability, data retention, localization, rollout, or rollback.
• A product requirement must become verifiable engineering quality criteria.
• The release or platform has app store, compliance, privacy, security, SLO, SLA, or operational constraints.
• Dev needs thresholds, validation methods, or release gates.
• An existing NFR section is too vague to test.
• Architecture, HLD, LLD, or ADR work needs measurable quality inputs before design choices can be justified.

Do not use when

• The task only needs product framing, BRD, URS, or PRD.
• The work is direct implementation, debugging, or PR review.
• The user asks for architecture decisions without a requirement source. Recommend sdlc-hld-workflow, sdlc-architecture-decision-record, or $codex-next:sdlc-solution-spec-workflow after NFRs are identified.
• The quality requirement cannot be evaluated yet because the product behavior is still undefined. Use sdlc-srs-workflow or sdlc-prd-workflow first.

Inputs

Prefer these sources:

• PRD, SRS, or scope baseline
• platform constraints
• security/privacy requirements
• legal or compliance notes
• operational incident history
• existing SLO/SLA documents
• support requirements
• usage forecast
• expected traffic or data volume
• device/browser/platform support matrix
• launch plan or release requirements
• known production constraints
• prior performance, reliability, or security findings

If the input lacks measurable data, write a decision-needed NFR rather than inventing a target.

NFR categories

Use only the categories relevant to the requested work.

Category	Examples
Performance	latency, response time, startup time, page load, throughput, QPS, memory, CPU, energy
Scalability	users, tenants, data volume, concurrency, growth assumptions
Availability	uptime, maintenance window, degradation behavior
Reliability	failure handling, retries, consistency, durability, backup, recovery
Security	authn, authz, injection, secrets, threat model, abuse resistance
Privacy	PII, data minimization, consent, retention, deletion, third-party sharing
Compliance	audit, legal, platform policy, data residency, export or industry constraints
Accessibility	screen reader, keyboard, contrast, dynamic text, focus order, touch target
Compatibility	browser, OS, devices, API versions, backward compatibility
Maintainability	configuration, modularity, upgrade path, documentation, ownership
Observability	logs, metrics, traces, alerts, dashboards, audit trail
Operability	feature flags, rollout, rollback, support tools, runbook
Localization	language, date/time, currency, RTL, regional rules
Data quality	freshness, completeness, accuracy, lineage, reconciliation

Architecture impact

Route NFRs into architecture work when they affect structure or ownership:

NFR area	Architecture impact
Performance	cache, async processing, indexing, queues, pagination, resource budgets
Reliability / availability	retry, fallback, circuit breaker, recovery, idempotency, backup strategy
Security	authentication, authorization, tenant isolation, secrets, audit, abuse controls
Privacy	data minimization, retention, deletion, anonymization, third-party boundaries
Observability	logs, metrics, traces, alerts, dashboards, audit trail
Compatibility	API versioning, schema migration, deprecation, feature flags, rollout strategy

If the NFR implies a long-lived architecture decision or meaningful trade-off, create or request an ADR via sdlc-architecture-decision-record.

Workflow

1. Confirm NFR scope

Write:

Feature/system:
Delivery profile:
Target users:
Deployment or platform:
Release target:
Critical risk areas:
NFR categories in scope:
NFR categories out of scope:

If the system is consumer-facing, enterprise-facing, regulated, AI-driven, financial, health-related, or admin/security-sensitive, make the risk category explicit.

2. Extract quality claims

Read source materials and extract every quality claim, such as:

fast
secure
reliable
low latency
privacy friendly
accessible
works offline
highly available
supports many users
safe for children
enterprise ready
app store ready

For each claim, decide whether it is:

Type	Action
measurable requirement	convert to NFR
design principle	record as guidance
unresolved target	mark decision needed
unsupported claim	remove or flag
implementation detail	move to solution/design material

3. Create NFR IDs

Use stable IDs:

Prefix	Category
NFR-PERF	Performance
NFR-SCALE	Scalability
NFR-AVAIL	Availability
NFR-REL	Reliability
NFR-SEC	Security
NFR-PRIV	Privacy
NFR-COMP	Compliance
NFR-A11Y	Accessibility
NFR-COMPAT	Compatibility
NFR-MAINT	Maintainability
NFR-OBS	Observability
NFR-OPS	Operability
NFR-L10N	Localization
NFR-DQ	Data quality

4. Write each NFR as a measurable requirement

Recommended structure:

### NFR-PERF-001: <Requirement name>

- Source:
- Requirement:
- Measurement:
- Target:
- Floor threshold:
- Test or validation method:
- Environment:
- Frequency:
- Owner:
- Related REQ IDs:
- Related SPEC IDs:
- Architecture impact:
- Related HLD / LLD / ADR:
- Release impact:

A valid NFR should answer:

What is constrained?
How is it measured?
What target must be met?
Where is it measured?
When is it measured?
Who owns validation?
What happens if it fails?

5. Define performance requirements

For performance-sensitive work, consider:

• user-perceived latency
• API latency
• p95 / p99 thresholds
• page load or app startup
• resource usage
• throughput
• concurrency
• data processing time
• background job timing
• battery or energy impact
• cold start and warm start differences

Use environment-specific targets. Do not compare local development timing with production requirements unless explicitly marked.

6. Define reliability and availability requirements

For reliability-sensitive work, consider:

• acceptable error rate
• retry behavior
• timeout behavior
• idempotency
• partial failure handling
• degraded mode
• backup and restore
• data durability
• queue or job recovery
• offline or weak network behavior
• manual recovery path

Distinguish:

availability target
data correctness target
user-visible resilience
operator recovery

7. Define security and privacy requirements

For security-sensitive work, identify:

• authentication
• authorization
• role-based access
• tenant isolation
• input validation
• secret handling
• audit logging
• rate limiting or abuse protection
• data classification
• personal data fields
• consent and disclosure
• data retention and deletion
• third-party data sharing
• admin access
• compliance constraints

If security or privacy decisions are uncertain, record them as blocking open questions rather than guessing.

8. Define accessibility and compatibility requirements

For user-facing UI, consider:

• keyboard operation
• screen reader labels
• focus order
• color contrast
• dynamic text
• reduced motion
• error announcement
• touch target size
• browser and OS support
• mobile/desktop behavior
• viewport breakpoints
• localization impact

If accessibility is out of scope for a delivery profile, state who accepted that risk.

9. Define observability and operations requirements

For production-facing work, specify:

• logs to emit
• metrics to collect
• trace points
• dashboards
• alerts
• audit events
• operational runbook needs
• feature flag or config needs
• rollout and rollback monitoring
• support diagnostics

Observability requirements should be linked to user or business risk, not collected by default without purpose.

10. Build the NFR matrix

Use this table:

NFR ID	Category	Requirement	Target / threshold	Validation	Release gate	Related SRS / SPEC

Release gate values:

blocker
required before full rollout
required before beta
recommended
monitor after launch

11. Record decisions and unknowns

Use:

ID	Question / decision	Category	Blocks dev?	Blocks release?	Owner	Needed by

Do not hide unknown thresholds. A requirement such as “performance must be good” is not ready; write it as an unresolved decision.

Output

Return or write:

# NFR Spec: <Feature / System>

## 1. NFR Scope
## 2. NFR Category Coverage
## 3. NFR Matrix
## 4. Performance Requirements
## 5. Reliability / Availability Requirements
## 6. Security / Privacy / Compliance Requirements
## 7. Accessibility / Compatibility Requirements
## 8. Observability / Operations Requirements
## 9. Release Gates
## 10. Decisions, Assumptions, and Open Questions
## 11. Handoff Notes

Validation

Before calling the NFR spec ready, verify:

• Each NFR has an ID.
• Each P0/P1 NFR has a measurable target or a marked decision-needed gap.
• Each NFR has a validation method.
• Each release-blocking NFR has an owner or explicit owner-needed note.
• Architecture-impacting NFRs are marked for HLD, LLD, ADR, or solution package follow-up.
• Security, privacy, accessibility, and observability were considered when relevant.
• NFRs are linked to SRS/SPEC IDs when possible.
• Vague quality language has been removed or clarified.
• Unsupported compliance claims are not presented as facts.
• Release gates are explicit.

Boundaries

• Do not implement code.
• Do not invent legal, compliance, security, or privacy requirements.
• Do not choose architecture merely to satisfy an NFR unless the architecture decision is already approved.
• Do not promise production performance without measurement or a defined test plan.
• Do not treat monitoring as a substitute for meeting a requirement.
• Do not let this narrow NFR workflow replace solution-package coordination or sdlc-dev-handoff-planning.

Handoff

Recommend the smallest next step. For an explicit-control workflow, return its exact $codex-next:<skill-name> command and stop; do not begin it here.

Route downstream:

Need	Next skill
software requirement mapping	sdlc-srs-workflow
UI/API/Data/Admin/Permission/Directory slices	sdlc-spec-slice-writer
HLD	sdlc-hld-workflow
LLD	sdlc-lld-workflow
architecture decision record	sdlc-architecture-decision-record
solution package coordination	$codex-next:sdlc-solution-spec-workflow
implementation task package	sdlc-dev-handoff-planning
traceability	sdlc-requirements-traceability
readiness judgment	$codex-next:sdlc-readiness-review

For dev handoff, provide:

1. NFR matrix
2. release-blocking NFRs
3. validation methods
4. environment assumptions
5. open decisions
6. architecture-impacting NFRs
7. links to related SRS/SPEC/HLD/LLD/ADR IDs