In requirements analysis, what is the difference between a functional requirement and a non-functional requirement, and why does an architect need to treat them differently?
answer
- what vs how well
- cross-cutting = architecture-level
- additive vs foundational
- quantify NFRs or they're untestable
- asymmetric retrofit cost
basics
~20 sFunctional requirements describe what the system must do, e.g. 'let a user reset their password.' Non-functional requirements describe how well it must do it, e.g. 'password reset must respond in under 2 seconds for 99% of requests.'
solid answer
~40 sFunctional requirements are testable feature/behavior statements (verb-subject-object), each satisfiable by a local piece of code. Non-functional requirements are quality attributes, performance, availability, security, scalability, maintainability, that apply across every transaction, not one feature. The distinction matters because functional requirements are additive and cheap to defer or add later, while non-functional requirements are usually cross-cutting and get baked into the architecture itself (topology, data partitioning, sync vs async communication). Retrofitting a missing NFR, like turning a single-instance database into a sharded one to hit a scale target, is an architecture-level rewrite, not a code patch. NFRs also must be quantified ('p99 under 300ms') rather than vague ('fast') or they can't be tested or verified.
go deeper
Can define the difference and give an example of each; not expected to know how NFRs drive architecture decisions yet.
Should recognize when an NFR is hiding inside a vague functional statement and know to quantify NFRs before accepting them.
Expected to explain why NFRs are architecture drivers, prioritize which NFRs are foundational vs deferrable, and push back on unquantified requirements during elicitation.
Expected to set organizational policy for how NFRs are captured and traced (e.g., SLO frameworks), calibrate NFR targets against real evidence to avoid over-engineering, and own the trade-off conversation with stakeholders when NFR targets conflict with cost or timeline.
## The two lenses Functional and non-functional requirements are the two lenses solution architects use to decompose a system's needs. - **A functional requirement** states an action the system must perform in response to some trigger: "when a customer submits a claim, the system must generate a claim ID and store the claim in pending status." It's phrased as a verb-subject-object statement, is directly observable in the running system, and can usually be verified with a single test case that either passes or fails. - **A non-functional requirement** (also called a quality attribute or an '-ility') describes a constraint on how the system performs its functions across many transactions or over time: latency, throughput, availability, durability, security, scalability, maintainability, observability, and so on. Instead of 'the system does X,' it says 'whenever the system does anything, it must do so within these bounds' - for example, '95% of claim submissions complete in under 500ms' or 'the system remains available during a single availability-zone outage.' ## Why the two are satisfied differently The distinction exists because the two categories are elicited, verified, and, most importantly for an architect, architecturally satisfied by completely different mechanisms. Functional requirements map fairly directly to features, screens, endpoints, and business logic; you can usually add a missing functional requirement later without redesigning the system's skeleton, because it's local to one code path. Non-functional requirements, by contrast, are usually **cross-cutting**: they constrain every request that flows through the system, which means they get baked into the architecture itself: - the choice of synchronous vs. asynchronous communication - the data partitioning strategy - the caching layers - the deployment topology - the choice between a monolith and services A requirements analyst who lumps 'must support bulk CSV export' (functional) together with 'must sustain 10,000 requests/second with p99 latency under 200ms' (non-functional) in the same undifferentiated backlog risks having the architect discover the throughput number only after the database schema and API contracts are already locked in. ## The central trade-off That leads to the central trade-off in how much rigor to apply to each category. - **Functional requirements** benefit from being captured just-in-time and iteratively - you can defer detail, prototype, and revise them cheaply because they're additive. - **Non-functional requirements** need to be captured early and quantified precisely, because retrofitting them is expensive: turning a request/response API into an eventually-consistent event-driven system to hit an availability target, or sharding a database that was designed as a single instance to hit a scale target, are architecture-level rewrites, not code-level patches. The cost of getting this wrong is asymmetric - under-specifying a feature costs you a sprint; under-specifying a non-functional requirement can cost you a re-platforming effort measured in quarters. The flip side is that non-functional requirements are also the easiest to over-specify: teams that gold-plate every NFR ('must scale to 1M concurrent users') without evidence of actual demand pay an ongoing complexity tax for headroom they'll never use. Good requirements analysis calibrates NFR targets to real, evidenced numbers (current load, projected growth, contractual SLAs) rather than aspirational round numbers. ## How the gap shows up in production In production, the failure mode of conflating or neglecting non-functional requirements shows up in a specific, recognizable way: the system passes every functional acceptance test - every button works, every workflow completes - and only falls over once it meets real traffic, real data volume, or a real outage, because nobody wrote down (or measured against) an explicit latency, availability, or security requirement during design. - You'll see this as 'it worked in the demo' incidents: a reporting feature that's functionally correct but times out once the table has ten million rows, because 'must handle the full production data volume within an acceptable query time' was never captured as an NFR alongside 'must generate a report.' - **Vague NFRs** cause the same problem in a different disguise - 'the system should be secure' or 'the system should be fast' cannot be tested, so they get silently deprioritized under deadline pressure, and the gap only surfaces in a penetration test or an incident postmortem. ## A payments illustration A concrete illustration: when a team builds a payments API, the functional requirements are things like 'authorize a card,' 'capture a payment,' 'issue a refund' - each independently testable and each independently deferrable to a later release. The non-functional requirements are not deferrable, because they dictate the entire architecture up front: - **PCI-DSS compliance** for how card data is stored and transmitted - **99.95% availability**, because merchants lose revenue on downtime - **sub-second p99 authorization latency**, because checkout abandonment rises sharply past that threshold Tokenization service, network segmentation, multi-region failover, and idempotency keys are all NFR-driven design decisions that have to be in place before the first functional feature ships, not bolted on afterward.
- Give an example of a requirement that looks functional but is actually hiding a non-functional requirement.'The search feature must return results' sounds functional, but it implicitly needs a latency bound and a relevance/quality bound to be useful - the real requirement is 'return relevant results in under 300ms,' which is an NFR wearing a functional disguise. The lesson is to always probe vague functional statements for implicit quality attributes.
- How do you make a non-functional requirement testable?Quantify it with a measurable threshold and a measurement method - not 'fast' but 'p99 latency under 300ms measured under X concurrent load via a specific load-testing tool' - then write it as an acceptance test or SLO that CI or synthetic monitoring can check continuously.
- Where do non-functional requirements typically come from if stakeholders don't volunteer them?SLAs and contracts, regulatory or compliance mandates, historical incident data, capacity and growth projections, and the architecture team itself probing 'what happens at 10x load' or 'what happens if this dependency is down' during elicitation, since business stakeholders often only think in features.
Functional requirements are like the rooms a house needs (kitchen, bedroom, garage); non-functional requirements are like the building code and foundation specs (must withstand a magnitude-7 earthquake, must support X occupants) - you can add a room later, but you can't retrofit earthquake-resistance without touching the foundation.
saying these in an interview costs you the question
- treats NFRs as a checkbox added at the end
- gives non-quantified NFRs like 'must be fast/secure'
- doesn't distinguish deferrable from foundational requirements
- assumes functional coverage means the system is done
- can't name where an NFR target came from (SLA, regulation, measured load)