Functional vs Non-Functional Requirements: Performance, Security and Usability
When building a website or SaaS product, many people equate "requirements" with a list of features and skip the part that defines "how well the system does it." The IIBA BABOK explicitly distinguishes two kinds of requirements: functional requirements describe what the system must do, while non-functional requirements (also called quality requirements in BABOK) describe the degree to which those functions are satisfied.
The difference between the two
| Dimension | Functional requirements | Non-functional requirements |
|---|---|---|
| Question answered | What the system does | How well the system does it |
| Examples | Users can register, pay, export reports | Page loads in 3s, data encrypted at rest, 99.9% availability |
| Testability | Usually clearly acceptable | Needs quantified metrics such as response time, concurrency |
| Common source | User stories, business processes | Performance, security, compliance, usability constraints |
Software engineering standards such as IEEE 29148 use a similar split: functional requirements define behavior, quality requirements define the level at which that behavior should be delivered.
Common types of non-functional requirements
- Performance: response time, throughput, concurrent users — for example "API P95 response < 200ms." Use Core Web Vitals to quantify the front-end experience.
- Security: authentication, authorization, encryption, audit logs, and compliance such as GDPR — see website security best practices.
- Usability/availability: the share of uptime (SLA), for example 99.9% availability, which maps to SLOs and error budgets.
"99.9%" sounds like just one fewer nine, but the actual uptime difference is large:
| Availability | Downtime per year | Downtime per month | Best fit |
|---|---|---|---|
| 99% | 87.6 hours | 7.3 hours | Internal tools, non-critical systems |
| 99.9% | 8.76 hours | 43 minutes | Most commercial sites |
| 99.95% | 4.38 hours | 21 minutes | Transactional sites |
| 99.99% | 52.6 minutes | 4.3 minutes | Payments, core infrastructure |
When writing an SLA, first answer "how long can the business tolerate being down" and work back to the architecture — 99.99% usually means multi-zone plus automatic failover, with cost and complexity that most small and mid-sized sites cannot casually take on.
- Scalability: whether the system can scale horizontally under growth, often considered during tech stack evaluation.
- Maintainability and accessibility: maintainable code and accessibility (a11y) standards.
Why non-functional requirements get ignored
Non-functional requirements have no "button" to click, so they are easy to defer to "later." By the time you discover the system is slow, insecure, or cannot handle traffic, rework is expensive. When writing a PRD, give every class of non-functional requirement a measurable acceptance criterion instead of vague phrases like "the system must be fast and secure."
How to write them clearly in a PRD
- Quantify: turn "good performance" into "LCP < 2.5s and API P95 < 300ms."
- Add scenarios: state the peak conditions, for example "support 500 concurrent users and 100,000 requests per day."
- Give a validation method: say which tool to use and the threshold, so QA can align with your acceptance criteria.
- Set priorities: not every quality attribute matters equally; use a requirement prioritization framework to trade off.
A concrete before/after example:
| Vague wording | Measurable wording |
|---|---|
| The system must be fast | Homepage LCP < 2.5s (mobile median) |
| It must handle traffic | 1,000 concurrent users at promo peak, 1M requests/day, P95 < 300ms |
| Data must be secure | TLS 1.2+ in transit, encryption at rest, sensitive fields masked |
| It must be reliable | Monthly availability >= 99.9%, one failover drill per quarter |
Trade-offs
Performance, security, and cost often pull in different directions: stronger encryption and auditing add latency, and higher redundancy raises cost. BABOK's value is making these trade-offs explicit — record the constraints and compromises of each non-functional requirement so the team decides before development, not after launch.
Quality attributes need continuous validation
Non-functional requirements should run through the whole development cycle instead of ending up in the PRD: performance needs load testing during integration, security needs code review during implementation, and availability needs a dry run before launch. Fold these quality attributes into CI and monitoring and alerting so they are validated continuously, just like functional requirements. For products already in production, use real traffic data — response time percentiles, error rates — to recalibrate the thresholds you set initially, so quality targets evolve with the business.
A case of being dragged down by "we'll do it later"
An e-commerce team shipped with a PRD that only listed features; the "concurrency support" field said "needs to be stable". On the Double 11 sale day, homepage API latency P95 climbed from 300ms to 6 seconds and order-page timeouts spiked. Rate limiting saved the payment path, but a large share of add-to-cart conversions was lost. The postmortem found: had they written "5,000 concurrent users at peak, P95 < 300ms" as a measurable acceptance criterion, load testing would have exposed the bottleneck during integration, not on the big sale day.
The cost of non-functional requirements is that they never "throw an error" on launch day — they become incidents slowly and cumulatively. That is why performance, security, and availability targets belong in automated CI checks rather than only in the PRD document.
Reference: IEEE 29148 software requirements engineering standard https://standards.ieee.org/ieee/29148/6710/; IIBA BABOK https://www.iiba.org/business-analysis-body-of-knowledge/
16IDC perspective
For small and mid-sized websites, non-functional requirements do not have to be "everything at once." Start by locking down 3-5 key quality attributes (usually performance and security) as measurable standards, then add scalability and availability goals as the business grows. What separates mature teams from makeshift ones is rarely how many features they ship — it is whether "how well it works" was defined at all.
Source: https://www.iiba.org/business-analysis-body-of-knowledge/