Capturing Non-Functional Requirements (the Quiet Ones)

Contributor
Mar 30
5 min read

Functional requirements have champions. Someone asked for the feature; they care about it; it gets attention. Non-functional requirements (NFRs) are the quiet ones — assumed, implicit, ignored until they fail in production. Performance, reliability, security, accessibility, compliance: each has the same pattern. Nobody specifies them, and then they're surprises.

This guide is how to surface NFRs early so they're not surprises late.

The Categories to Cover

For each new system or feature, ask about:

Performance: response time, throughput
Scalability: how does this grow with load
Reliability: uptime, fault tolerance
Security: what threats does this need to handle
Privacy: PII handling, consent, retention
Accessibility: WCAG conformance, screen reader support
Compatibility: browsers, devices, integrations
Usability: ease of use targets
Maintainability: ongoing cost of ownership
Compliance: any regulatory requirements

Not every category applies to every project. The discipline is asking about each.

Why NFRs Get Skipped

Several specific reasons:

They don't have a stakeholder voice. No customer asks for "99.9% uptime." They assume it.

They're hard to write. "Fast" is vague; quantifying it requires thought.

They feel like engineering concerns. Often deferred to "we'll figure it out."

They span features. Hard to attribute to any single deliverable.

They surface as surprises. A failure post-launch becomes the requirement going forward.

Surface them upstream and they're cheap. Discover them post-launch and they're expensive.

How to Surface Implicit NFRs

Stakeholders often hold NFR expectations implicitly. Make them explicit.

Useful prompts:

"How fast should this feel? Specifically?"
"What would 'too slow' look like?"
"How much traffic do we expect? In a year?"
"What's our tolerance for downtime?"
"What customer data does this touch?"
"Who needs to be able to use this?"
"What regulatory environment applies?"

Each prompt surfaces implicit expectations that would otherwise stay unsaid.

Quantifying NFRs

Vague NFRs are useless.

Bad: "The system shall be fast."

Better: "The system shall respond to user requests within 500ms at p95 under normal load (1000 RPS)."

The quantification includes:

The metric (response time)
The threshold (500ms)
The percentile (p95)
The conditions (normal load, 1000 RPS)

Each element matters. Without them, the requirement is unmeasurable.

Common NFRs and How to Specify Them

Performance:

The system shall respond to [endpoint or action] within [threshold] at [percentile] under [load conditions].

Example: "The /search endpoint shall respond within 800ms at p95 under load of 100 concurrent users."

Reliability:

The system shall maintain [uptime] over [period], excluding [exclusions].

Example: "The system shall maintain 99.9% uptime over a calendar month, excluding scheduled maintenance windows announced 7 days in advance."

Security:

The system shall [security property] using [mechanism].

Example: "The system shall encrypt all customer data at rest using AES-256."

Accessibility:

The system shall conform to [standard] level [conformance level].

Example: "The system shall conform to WCAG 2.1 level AA."

Compatibility:

The system shall function correctly on [browsers/devices] [versions].

Example: "The system shall function correctly on the latest 2 versions of Chrome, Firefox, Safari, and Edge."

Where NFRs Live

Different places, depending on scope:

System-wide NFRs: in the architecture document or system specification
Component-specific NFRs: in the component's design document
Feature-specific NFRs: in the feature's PRD or acceptance criteria
Continuous obligations: in the team's Definition of Done

The same NFR shouldn't be duplicated across all of these. Pick the right level and reference it.

Connecting NFRs to Implementation

NFRs influence architecture and design decisions:

"Response time under 100ms" → caching, query optimization, CDN
"99.99% uptime" → multi-region, redundancy, automatic failover
"PCI compliance" → tokenization, network segmentation, audit logging
"WCAG AA" → accessibility considered throughout, not retrofitted

The architect's job is to design a system that satisfies the NFRs. Without explicit NFRs, the architecture is implicit guesswork.

Testing NFRs

NFRs need specialized testing:

Performance NFRs: load testing, stress testing
Reliability NFRs: chaos engineering, soak testing
Security NFRs: SAST, DAST, pentests
Accessibility NFRs: axe, manual screen reader testing
Compatibility NFRs: cross-browser test matrix

Each has its own tooling and cadence. Most are run less frequently than functional tests.

Monitoring NFRs in Production

Many NFRs are continuous obligations. They need ongoing verification:

Performance SLOs monitored continuously; alerts when violated
Uptime tracked and reported
Security scanning continuous
Accessibility audits periodic

Without monitoring, NFRs become aspirational. With it, they're enforced.

Trade-Offs

NFRs conflict with each other and with cost.

High availability requires redundancy = higher infrastructure cost
Faster response often requires caching = staleness or complexity
Strong security can hurt usability
Cross-browser compatibility requires more testing

Explicit NFRs force the trade-off conversation. "We want all of these at maximum levels" gets challenged with "pick your priorities."

Versioning NFRs

NFRs evolve. Update them when:

The product or user base grows (performance targets shift)
Compliance requirements change (new regulations apply)
Customer expectations evolve (what was acceptable becomes embarrassing)
New capabilities emerge (what was impossible becomes routine)

Stale NFRs misdirect investment. Update on a regular cycle.

The Quick Audit

For any feature, walk through this list:

[ ] Performance: do we have a target?
[ ] Reliability: do we have an uptime expectation?
[ ] Security: have we considered the threats?
[ ] Privacy: does this touch user data? PII?
[ ] Accessibility: have we committed to a standard?
[ ] Compatibility: which platforms?
[ ] Compliance: any regulations?

For each unchecked box, decide: does this apply? If yes, write the NFR. If no, document why not.

The audit takes 15 minutes. It surfaces NFRs that would otherwise stay implicit.

A Worked Example

For a new "export to CSV" feature:

Performance: Export of up to 10,000 rows completes within 30 seconds at p95.
Reliability: Export endpoint maintains parent service's SLO (99.9% uptime).
Security: Exports are accessible only to authenticated users with appropriate permissions.
Privacy: Exports respect existing data permissions; no over-exposure.
Accessibility: UI for triggering export conforms to WCAG AA.
Compatibility: Works on supported browsers (per system list).
Compliance: Exports of PII honor user data residency requirements.

Seven explicit NFRs for a small feature. None are surprising; the surprise would be omitting them.

When to Skip an NFR

Some NFRs don't apply.

Internal tool with 50 users: probably no need for global CDN
Prototype: probably no need for production-grade reliability
Experimental feature: probably no compliance review

Skipping is fine when the answer is "no, this doesn't apply." Skipping without consideration produces post-launch surprises.

Anti-Patterns

Implicit NFRs. "Of course it should be fast." How fast? Measured how?

Aspirational NFRs. "100% uptime." Unachievable. Aim where you can deliver.

Vague NFRs. "Highly performant." Useless.

Once-and-done NFRs. Specified at launch; never updated.

NFRs in test plans only. Not in requirements. Get tested but not designed for.

Key Takeaway

Non-functional requirements are often implicit and get skipped until they fail. Surface them early by asking about each category — performance, reliability, security, privacy, accessibility, compatibility, compliance — for every feature. Quantify them with specific metrics, thresholds, and conditions. Different levels (system, component, feature) hold different NFRs. Test and monitor continuously, not just at launch. The discipline of asking about each NFR category catches the quiet requirements that would otherwise become loud problems.

ShiftQuality