Non-functional requirements are addressed

Non-functional requirements define the quality bar your product must meet, not just its feature set. A PRD that requires WCAG 2.1 AA compliance means you have committed to accessibility for users with disabilities — omitting ARIA labels and semantic HTML is a functional failure against that commitment, not a cosmetic gap. A performance target of sub-2s load time is a user retention requirement backed by data: conversion drops measurably above that threshold. Security NFRs like encryption at rest are often compliance requirements under GDPR, HIPAA, or SOC 2. ISO 25010:2011 covers functional suitability and reliability jointly — both require that NFRs are demonstrably addressed, not just aspirationally listed.

Check your configuration files and src/ code for each NFR category:

# Performance: verify image optimization and caching are configured
grep -r 'next/image\|Cache-Control\|stale-while-revalidate' src/ next.config.js

# Accessibility: verify ARIA attributes are present on interactive elements
grep -r 'aria-label\|aria-describedby\|role=' src/components/

# Security: verify encryption and rate limiting configuration
grep -r 'encrypt\|rateLimit\|@upstash' src/ prisma/

For each unaddressed NFR, file a specific implementation task rather than a vague "improve accessibility" note. The Security Headers audit, Performance and Load Readiness audit, and Accessibility Fundamentals audit each cover their respective NFR domains in detail if you need a dedicated check.

• ID: nonfunctional-requirements-addressed
• Severity: high
• What to look for: Enumerate every relevant item. Review the PRD for non-functional requirements (NFRs): performance targets (page load times, API response times), security requirements (data encryption, specific compliance needs), scalability targets (concurrent users, data volume), availability requirements (uptime SLA, graceful degradation), and accessibility requirements (WCAG level, screen reader support). Then look for evidence in the codebase that these have been addressed: performance optimizations (caching, lazy loading, CDN configuration), security configurations, rate limiting, error boundaries, accessibility attributes.
• Pass criteria: There is visible evidence in the codebase that each stated NFR has been considered and addressed, even if not fully optimized. For example, if the PRD requires "support 1000 concurrent users", the presence of database connection pooling, caching, and rate limiting provides reasonable evidence of intent.
• Fail criteria: The PRD states specific NFRs that have no corresponding implementation evidence. For example, PRD requires "all user data encrypted at rest" but the database has no encryption configuration, or PRD requires WCAG 2.1 AA compliance but no accessibility attributes are present in the codebase.
• Skip (N/A) when: The PRD contains no non-functional requirements — no performance, security, scalability, or accessibility targets. Signal: PRD is purely a feature list with no quality attributes specified.
• Detail on fail: Name the unaddressed NFRs. Example: "PRD requires page load time <2s but no image optimization, lazy loading, or caching configuration found. PRD requires WCAG 2.1 AA but no ARIA labels or semantic HTML present." Max 500 chars.
• Remediation: Non-functional requirements define the quality bar for your product, not just its features. Check configuration files like next.config.js, deployment configs, and src/ code for each NFR. For each unaddressed NFR: identify the specific implementation changes needed, prioritize them by impact on user experience and risk, and plan them into your remaining build work. For deeper analysis of specific NFR domains, the Security Headers audit covers security header implementation, the Performance & Load Readiness audit covers performance optimization, and the Accessibility Fundamentals audit covers accessibility compliance.