Functional requirements = what the system does. "Users can submit cases via email." Functional reqs come from business analysis.
Non-functional requirements (NFRs) = how well the system does it. Performance, security, scalability, availability, maintainability, etc.
Categories:
- Performance — page load times, transaction throughput, query response.
- Scalability — handles N users, M records, growing over time.
- Availability — uptime expectations, SLA tier.
- Security — authentication strength, encryption, audit, compliance.
- Reliability — failure rate, recoverability.
- Maintainability — how easy is it to modify, debug, deploy.
- Usability — how intuitive for users.
- Compatibility — works with existing systems, browsers, devices.
- Interoperability — integrates cleanly with other tools.
- Compliance — meets regulatory requirements (GDPR, HIPAA, PCI).
Why architects care:
- Functional reqs are easy to write; NFRs are easy to forget.
- Functional bugs are cheap to fix; NFR violations (poor performance, security gaps) are catastrophic.
- Architectural decisions are mostly about NFRs — choosing patterns that satisfy them.
- "It works" is functional; "it scales / is secure / is fast / is maintainable" is non-functional.
Common NFR examples:
- "Page load < 2 seconds for 95th percentile."
- "Recovery from production outage < 1 hour."
- "Audit log retained 7 years."
- "100 concurrent users without degradation."
- "Daily build completes in < 30 minutes."
Discovery should capture both. Often NFRs are implicit ("of course it should be fast"); architect surfaces them explicitly so they can be designed for.
Senior architects keep an NFR checklist. Each new project: walk through, ensure each is addressed.
Common architectural failures are NFR failures. A solution that meets functional needs but doesn't scale is broken. A solution that meets functional needs but lacks audit trail is broken. Architects guard against this.