Non-functional requirements for systems analyst interviews

Why interviewers grill you on NFRs

Functional requirements describe what the system does. Non-functional requirements describe how well it does it — and that is exactly where most junior systems analysts collapse on stage. You can ship a checkout that takes the right card numbers, charges the right amount, and emits the right receipt, and still be paged at 02:00 because p99 latency hit 12 seconds under Black Friday load and the payment provider started timing out. NFRs are the contract that prevents that pager.

Interviewers at Stripe, Uber, Airbnb, and Snowflake know this pattern because they have lived it. So they ask deceptively short questions: "Give me three NFRs for this order service." or "How would you test the availability requirement you just wrote?" The candidate who answers "it should be fast and secure" is gone. The candidate who answers "p95 < 250 ms for GET /orders/{id} at 2,000 RPS sustained, measured at the API gateway, excluding cold-start cases" advances.

The reason this matters in 2026 is volume. A typical mid-level systems analyst job posting on LinkedIn lists 8–12 NFR keywords (SLO, RPO, RTO, WCAG, GDPR, HIPAA, PCI-DSS, OWASP Top 10) and expects you to talk through each without notes. Base compensation on levels.fyi for a US mid-level SA hovers around $135k–$165k; the NFR delta between candidates is real money.

The NFR categories that show up most

Different shops use different taxonomies — ISO/IEC 25010, FURPS, BABOK — but in interviews the same nine buckets resurface. Here is the cheat sheet I drilled with candidates before their loops at Notion and DoorDash.

A solid answer references three to five of these per system, not all nine. Picking the right subset is itself the skill — checkout cares about security, payments, and availability; a CMS for marketing cares about authoring usability and SEO performance.

How to phrase an NFR so it actually passes review

The single most useful framework is SMART: Specific, Measurable, Achievable, Relevant, Time-bound. Apply it ruthlessly. Here is the same requirement at three quality levels.

Lazy: "The system should be fast." Rejected — no metric, no scope, no condition.

Better: "API responses should be under one second." Rejected — which API, which percentile, under what load, measured where, over what window.

Acceptable: "For GET /api/orders/{id}, the p95 response time measured at the API gateway shall be below 300 ms when sustaining 1,000 RPS for 10 minutes, on a steady-state cluster (no cold starts), measured weekly via the load-test rig in staging."

The acceptable version names the endpoint, the percentile, the throughput, the duration, the measurement point, the exclusion, and the cadence. Every one of those clauses exists because someone, somewhere, exploited the absence of it to ship a broken system.

The FURPS+ frame and when to use it

HP popularized FURPS in the 1990s, and the "+" extensions are still the cleanest way to map requirements to test types in an interview whiteboard.

• Functionality — features and capabilities. Strictly speaking not an NFR, but the F is there so you remember the boundary.
• Usability — learnability, efficiency, accessibility, aesthetic feel.
• Reliability — frequency of failure, recoverability, predictability.
• Performance — speed, efficiency, resource use, throughput.
• Supportability — maintainability, serviceability, configurability, install-ability.

The + adds four constraint families that often slip through pure FURPS reviews: design constraints (must use Postgres, must run on Kubernetes), implementation constraints (Java 21, no GPL libraries), interface constraints (gRPC public contract, OpenAPI 3.1), and physical constraints (must fit on an in-vehicle ARM box with 2 GB RAM).

Use FURPS+ as a checklist after you draft NFRs, not before. Drafting against the framework produces a wall of bland clauses; using it as a review pass catches the gaps.

Worked examples by category

These are the phrasings I would write on a whiteboard for a 45-minute SA interview at a mid-size payments company. They are deliberately concrete — interviewers reward concreteness over coverage.

Performance
- p95 latency for POST /v1/charges < 250 ms at 2,000 RPS sustained for 15 min,
  measured at the edge load balancer, excluding TLS handshake.
- Throughput: process at least 5,000 settlement records per second per worker pod.
- Cold-start budget: a new instance must serve traffic within 8 s of K8s readiness.

Reliability and availability
- Service-level objective: 99.95% monthly availability for all customer-facing
  endpoints, computed on 5xx + timeouts over total requests, excluding planned
  maintenance windows announced 14 days ahead.
- RTO 30 min, RPO 5 min for the orders database.
- MTTR for P1 incidents < 60 min, measured from PagerDuty ack to resolve.

Security
- All endpoints behind OAuth 2.1 with PKCE; legacy basic auth rejected with 401.
- PII encrypted at rest with AES-256-GCM, keys rotated every 90 days via KMS.
- All traffic over TLS 1.3; weak ciphers disabled at the load balancer.
- Annual third-party pen test plus continuous OWASP ZAP scans in CI.

Compliance
- PCI-DSS Level 1 scope limited to the tokenization service; merchant pages never
  see raw card numbers.
- GDPR right-to-erasure honored within 30 calendar days of verified request.
- HIPAA BAA in place with all subprocessors before any PHI flows.

Usability and accessibility
- WCAG 2.2 AA conformance verified by axe-core in CI, zero serious violations.
- Onboarding flow completion rate ≥ 80% for new merchants within 24 h of signup.
- UI input latency < 100 ms on a 2022 mid-tier Android device.

The pattern across categories is identical: name the scope, name the metric, name the threshold, name the measurement method, name the cadence. If any of those five are missing, the requirement is half-baked.

Common pitfalls

The most common pitfall is using adjectives instead of numbers. "Fast," "reliable," "secure," "user-friendly" are not requirements — they are vibes. The interviewer hears the adjective and immediately asks "how fast?" or "secure against what threat model?" The candidate who reaches for a number has a chance; the candidate who reaches for another adjective is done. Train yourself to translate every adjective into a measurement before it leaves your mouth.

A close second is mixing functional and non-functional clauses in the same requirement. "The system shall accept credit card payments and process them in under one second" is two requirements stapled together. The functional half ("accept credit card payments") needs acceptance criteria; the non-functional half ("under one second") needs an SLO with percentiles. Splitting them clarifies ownership: backend owns the functional, SRE owns the NFR.

The third trap is inheriting NFRs without questioning them. A team copies "99.99% availability" from a previous project because it sounds professional, never realizing that four nines costs roughly 4x what three nines costs and the actual business need is two nines. NFRs have price tags. The senior SA always asks "what does this requirement cost to meet, and is the business willing to pay it?" before signing off.

Fourth is writing NFRs without a measurement plan. A requirement that says "p95 latency < 300 ms" without specifying where the 300 ms is measured (client device, edge, load balancer, application, database) can be satisfied or violated depending on choice of vantage point. Always pin the measurement location and the tooling — Datadog APM at the load balancer, sampled at 100%, computed in 5-minute windows.

Fifth, forgetting compliance until late. GDPR, HIPAA, and PCI-DSS each impose hard architectural choices (data residency, BAA chain, scope minimization) that are cheap to honor at design time and brutally expensive to retrofit. If the system will touch PII, payment cards, or protected health information, the relevant compliance NFR belongs in the first draft, not the security review three sprints later.

Related reading

• Acceptance criteria for systems analysts
• Capacity planning for systems analysts
• Definition of ready and done for systems analysts
• Latency budget for systems analysts
• Load testing for systems analysts

If you want to drill NFR phrasing the way real interviews hit you — with timed prompts, sample answers, and grading rubrics — NAILDD ships systems analyst question sets built around exactly this pattern.

FAQ

What is the difference between an SLA, an SLO, and an SLI?

An SLI (service level indicator) is the raw measurement — for example, the ratio of successful requests to total requests over a five-minute window. An SLO (service level objective) is the internal target you commit to — "the success-rate SLI shall be at least 99.95% over a rolling 30-day window." An SLA (service level agreement) is the externally enforceable contract with the customer, typically set looser than the SLO so the engineering team has internal headroom before contractual penalties trigger. In an NFR document, you usually write the SLO and reference the SLA only when discussing customer-facing commitments.

How do I pick a target like 99.9% versus 99.99% availability?

Pick based on business cost of downtime, not on what sounds impressive. Three nines (99.9%) allows about 43 minutes of downtime per month and is appropriate for most internal tools and B2B SaaS dashboards. Four nines (99.99%) allows about 4 minutes per month and is appropriate for payment processing, authentication, and core marketplace flows. Each additional nine roughly multiplies infrastructure cost by 3–10x because you need multi-region failover, faster failure detection, and more redundant components. The senior move is to compute revenue-at-risk per minute of downtime and back into the availability target.

Are accessibility requirements really enforceable in interviews?

Yes, and increasingly so. Both the EU Accessibility Act (in force June 2025) and US ADA Title III case law have made WCAG 2.2 AA the de facto baseline for any consumer-facing web product. Interviewers at companies with mature legal teams — Microsoft, Apple, Google — will dock candidates who omit accessibility entirely. The safe phrasing is "all customer-facing flows conform to WCAG 2.2 AA, verified by axe-core in CI plus quarterly manual screen-reader audits."

How should NFRs change between MVP and scale?

Aggressively. At MVP, your latency NFR might be "p95 < 2 s at 50 RPS" because you have no traffic and need to ship. At scale, the same endpoint might carry "p95 < 150 ms at 20,000 RPS with regional failover and chaos testing." The mistake is writing scale-grade NFRs at MVP (you burn the runway over-engineering) or writing MVP-grade NFRs at scale (you burn the on-call rotation under-engineering). The senior SA writes NFRs against the next growth milestone, not the current state and not the five-year vision.

What is the right level of detail for an NFR in a PRD?

Enough that an engineer can implement and a tester can verify without asking you a question. That usually means one to three sentences per requirement, citing the scope, the metric, the threshold, the measurement method, and the cadence. Avoid prose paragraphs that bury the number — every NFR should be skimmable in under five seconds. If your NFRs run longer than half a page, you are probably writing design decisions disguised as requirements.

What sources should I cite if the interviewer asks where my NFR framework comes from?

The defensible references are ISO/IEC 25010 (software quality model), the IEEE 830 / ISO/IEC/IEEE 29148 family (requirements engineering), BABOK Guide v3 from IIBA (business analysis body of knowledge), and the original FURPS paper from Robert Grady at HP. Name-dropping these calmly signals seniority; pretending to have invented the categories yourself signals the opposite.