core practice · coding problem
Split functional from non-functional
Implement classify(requirements) returning { functional, nonFunctional } — two arrays preserving input order. A functional requirement states what the system DOES; a non-functional one states a quality or constraint it must hold (latency, availability, throughput, durability, consistency, cost, security posture).
The mechanism
Functional requirements say what the system does; non-functional ones say what it must survive — and only the second kind changes the architecture. 'Users can post' does not tell you anything, while 'reads outnumber writes 100:1 and p99 must stay under 200ms' picks your caching and replication strategy outright. Scoping is an act of subtraction: naming what you are explicitly not building is what makes the rest defensible.
Expected evidence
'Users can upload a photo' -> functional; 'p99 read latency under 200ms' -> nonFunctional
Try this drill in the practice workspace →
Hints when you need them
- Ask whether the statement could be satisfied by a feature, or only by an architectural property.
- Anything with a number attached to time, availability, or scale is almost always non-functional.
Watch for these mistakes
- Starting to design before agreeing what is out of scope, then re-architecting mid-answer
- Treating a latency or availability target as a detail to add later, when it is the constraint that selects the design
- Collecting requirements without a scale number, so every later decision is unfalsifiable
- Accepting 'highly available' as a requirement instead of pinning an availability target and its cost