Functional and non-functional requirements

Two teams get the same brief: "a ticketing app for the college fest". One ships something that handles fest day without a hiccup. The other's app melts at 10:00:01. Usually the difference isn't skill. It's that the first team wrote down how good the app had to be before they built it.

Two kinds of requirement

Every requirement answers one of two questions.

Functional requirements: what does the system do? They're features, best written as things a user can do:

• A student can see this year's events and pass types.
• A student can buy a pass and get a QR code.
• A volunteer can scan a QR code and see if it's valid.
• An organiser can see how many passes have sold.

Non-functional requirements: how well does it do it? They're qualities, and they only mean something with a number attached:

• Latency: the event page loads in under 300 ms for 95% of requests.
• Throughput: handle 50 purchases per second at peak.
• Availability: up 99.9% of fest week.
• Correctness: never sell more passes than the venue holds.
• Durability: a paid booking is never lost.

A useful test: if you can't imagine a load test or a check that would fail the requirement, it isn't written well enough yet. "The app should be fast" can't fail. "95% of event page loads under 300 ms" can.

Why the non-functional ones matter more

Here's the uncomfortable truth: functional requirements rarely change the architecture. Nearly any architecture can "let a student buy a pass". It's the non-functional numbers that decide whether you need one server or twenty, one database or a primary with replicas, a cache, a queue.

Take the same feature with two different numbers:

• "Buy a pass", 2 per second. One server, one database, a transaction. Done.
• "Buy a pass", 20,000 per second for the first minute of a stadium sale. Now you need a waiting room, a fast way to hold seats, payments in the background, and a database that won't lock up on one hot row.

Same verb, completely different system. That's why experienced designers spend their requirement time on the adjectives.

Writing them down for Gatepass

Let's write Gatepass's real list for the first fest. Notice the scope line at the end; it's as important as anything above it.

Functional

1. Students browse events and pass types without signing in.
2. Students sign in with their college email and buy passes.
3. A purchase returns a QR code that also arrives by email.
4. Volunteers scan passes at two gates; each pass works once.
5. Organisers see live sales numbers.

Non-functional

1. 4,000 students; expect 2,000 purchases, most in the first hour.
2. Browsing: p95 under 300 ms. Purchase: p95 under 2 s (payment is slow anyway).
3. The sale window (first two hours) must not go down. Outside it, a few minutes of downtime is fine.
4. Zero overselling, zero lost payments.
5. Gate scanning keeps working without internet for up to 30 minutes.

Out of scope for now: refunds, seat maps, transfers between students, multiple colleges.

Hidden requirements

Some requirements nobody says out loud, but everybody expects:

• Security: students can't see other students' passes or forge a QR code.
• Privacy: phone numbers and emails aren't exposed.
• Operability: when something goes wrong at 10:02 on sale day, someone can tell what happened from the logs.
• Cost: the committee's budget is a few thousand rupees a month, not a few lakh.

You won't always design deeply for these on day one, but you should name them. Interviewers and reviewers notice when you do.

Check yourself

Which of these is a well-written non-functional requirement?

AThe booking page should be fast and reliableBStudents can cancel a bookingC99% of booking requests complete in under 1.5 seconds at 50 requests per secondDUse Redis for caching

Percentiles, not averages

You'll see "p95" and "p99" everywhere in this course, so let's pin them down. If you sort 100 response times from fastest to slowest, p95 is the 95th one: 95% of requests were at least that fast.

Why not the average? Because averages hide pain. Imagine 99 requests at 100 ms and one at 10 seconds. The average is about 200 ms, which sounds fine. But one student in a hundred stared at a spinner for ten seconds, and on fest day that's twenty angry people in the group chat. The p99 (10 s) tells you that; the average doesn't.

Your turn

Write two non-functional requirements for the gate scanner that a test could fail.

01

02

Stuck? Think about how long a volunteer waits per scan, and what happens with no internet.

Compare with an expertWrite at least 2 first.

Key takeaways

• Functional requirements are what the system does; non-functional ones are how well, with numbers.
• Non-functional requirements drive the architecture; the same feature at 2/s and 20,000/s are different systems.
• Write requirements a test could fail, and rank them so you know which wins in a conflict.
• Use percentiles (p95, p99), not averages, for latency.
• Write down what's out of scope. It's a decision too.