← Back to principles
Architecture
Non-Functional Requirements Are First Class
Statement
Non-Functional Requirements Are First Class
What this means in practice
Non-functional requirements such as security, performance, resilience, observability, and supportability are treated as core design inputs from day one. These concerns are made explicit, measurable, and traceable, with operational realities considered alongside feature delivery rather than deferred or treated as afterthoughts.
Why this matters
Treating non-functional requirements as first class ensures systems are secure, reliable, operable, performant, and cost-effective in real-world use—not just functionally complete. Without this, systems may go live but prove unstable, slow, insecure, or expensive to run. Incidents are harder to diagnose, risks emerge late, and operational teams inherit fragile solutions that undermine confidence and long-term value.
Practices that meet this principle
Non-functional requirements are captured and agreed alongside functional requirements at the start of delivery
Acceptance criteria include measurable non-functional targets (e.g. response times, availability, recovery objectives)
Security, performance, and resilience are reviewed as part of architecture and design activities
Operational concerns such as monitoring, alerting, and supportability are addressed before go-live
Non-functional requirements are tested and validated during delivery, not deferred to later phases
Validation
A project meets this principle when:
Non-functional requirements are documented with measurable targets
Security, performance, and resilience have been explicitly addressed in the architecture
OR:
Non-functional concerns are traceable from requirements through to implementation and testing
Scoring Guide
Score −1 — Disagreement / Rejected: The team acknowledges this principle is applicable but has explicitly decided not to follow it for this product. A rationale and decision record exist explaining why treating NFRs as first class is not adopted.
Score 0 — Not doing: Non-functional requirements are not captured or discussed. Security, performance, and resilience are not addressed until issues arise in production. No operational readiness activities before go-live.
Score 1 — Planned: The team has committed work to treat non-functional requirements as first class. An owner and target date exist for introducing NFR capture, measurable targets, and operational readiness practices. The plan is tracked.
Score 2 — Adopted for new work: All new work captures non-functional requirements with measurable targets alongside functional requirements. Security, performance, and resilience are reviewed in architecture and design. Operational readiness (monitoring, alerting, supportability) is confirmed before production. Any exceptions are explicit and reviewed.
Score 3 — Enforced for new work + migration plan: First-class NFR treatment is systematically enforced for all new work through process or tooling (e.g. NFR checklists, operational readiness gates). A tracked migration plan exists to bring existing systems into compliance with NFR standards.
Score 4 — Fully adhered: Non-functional requirements are first-class across all work including legacy. Acceptance criteria include non-functional measures that are tested during delivery. NFRs are traceable from requirements through to implementation and testing. Operational readiness is comprehensive and verified. Remaining gaps are minimal, known, and time-bound.