Non-functional requirements

🏠The everyday picture

Two houses can both have three bedrooms, yet one stays cool in summer, survives an earthquake and costs little to maintain, while the other doesn't. "How well" matters as much as "what".

📘What it really is

Non-functional requirements (NFRs), also called quality attributes, describe how well the system works:
performance: "search results appear within 1 second for 95% of requests";
scalability: "handles 10 times today's users without redesign";
availability: "99.5% monthly uptime" (Module 72);
reliability and data durability: "no confirmed booking is ever lost"; RPO and RTO (Module 58);
security: "only the student and tutor can see a booking's details"; OWASP review (Level 6);
privacy and compliance: DPDP Act duties (Module 79); payment rules (never store card details);
usability and accessibility: works well on low-end Android phones and slow connections; meets accessibility guidelines (Module 37);
maintainability: a new developer can make a small change in their first week;
cost: hosting under a set amount per month at the expected size;
localisation: Hindi and English; Indian time zone and rupee formats.
Make them measurable. "Fast" can't be tested; "under 1 second at the 95th percentile with 200 users" can.
NFRs drive architecture more than features do: "a booking must never be double-sold" shapes the database design; "works offline" shapes the frontend; "99.99% uptime" shapes everything (and the budget).
They conflict: more security can mean less convenience; more availability costs more. Lesson 4 is about choosing.

🖱️Try it

Write ten measurable NFRs for the booking platform, at least one for each of performance, availability, security, privacy, usability and cost. For each, write how you'd test or measure it. Mark the three that will most shape the design.

✅Quick check

Rewrite "the site should be fast" as a measurable requirement.

Show the answer

For example: "pages load within 2 seconds on a 4G phone for 95% of visits" (any specific, measurable version).

Why do non-functional requirements shape architecture so strongly?

Show the answer

They decide things like data consistency, redundancy, caching and hosting, which are hard to change later.