Use only when the user explicitly invokes this skill to evaluate a skill with representative cases, isolated runs, independent judging, and evidence-driven edits.

2026-07-2621

dev-bugfix

BlueSkyXN/Codex-is-all-you-need

Use for a concrete defect or regression that needs reproduction, root-cause diagnosis, a fix, and regression validation. Do not trigger for routine localized edits or primarily performance-focused work.

2026-07-2621

dev-fullstack-feature

BlueSkyXN/Codex-is-all-you-need

Use when the requested feature genuinely spans at least two delivery layers such as frontend, backend, API, data, scripts, or tests. Do not expand a single-layer change into a full-stack workflow.

2026-07-2621

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:

NFR matrix
release-blocking NFRs
validation methods
environment assumptions
open decisions
architecture-impacting NFRs
links to related SRS/SPEC/HLD/LLD/ADR IDs