Non-Functional Requirements

Turning a quality into a requirement

A quality becomes a requirement when you can answer five questions about it:

1. Which quality? Name the characteristic.
2. Measured how? Seconds, per cent, taps, pixels, attempts, hours.
3. To what target? The number that separates pass from fail.
4. Under what conditions? How many users, on what device, over what network, at what time.
5. Verified how? Which test, in which chapter of your plan, will prove it.

Watch the difference:

Two details in the first testable row matter. "95 per cent" instead of "all" admits that at a moment of load a few requests will be slower, and sets a limit on how many. "On the lab server" fixes the conditions: the same system is faster on a powerful machine and slower on a weak one, so a performance requirement without its conditions cannot be checked.

Borrow numbers from standards

For some qualities, somebody has already done the hard work of choosing testable numbers, and you should use theirs rather than inventing your own.

Accessibility has the Web Content Accessibility Guidelines, WCAG 2.2, a W3C Recommendation. Its success criteria are precise:

Each of these is a requirement you can quote, with a number, and test. Level A is the minimum; level AA is the level most organisations aim for.

Password storage has the OWASP Password Storage Cheat Sheet, which Chapter 31 uses. Performance has no universal standard number, so your target must come from your own problem, as the worked team's did from its load estimate in Chapter 6.

The worked project: non-functional requirements

The worked team went down the ISO list and wrote twelve requirements. Every one says how it will be verified, and every one was verified; the last column says where.

Some notes on how they arrived at these.

NFR-1 is the load estimate of Chapter 6 made into a promise. The team estimated a peak of about 7 orders a minute and set the requirement at 100, about fourteen times more, because the estimate might be wrong and the cost of a slow rush is high.

NFR-2 came from a question nobody asked in an interview. Ganesh had said two students sometimes claim the same plate. Farhan asked what happens if they both press Place order for the last portion at the same instant. The answer depends entirely on how the stock is updated, and the requirement makes sure somebody tests it.

NFR-7's 320 pixels is WCAG's number, not the team's. Their first draft said 360, the width of a common phone. Reading WCAG 2.2, they found SC 1.4.10 sets 320, and adopted it: a published number is easier to defend than a guessed one.

The team measured NFR-8 before writing it. They computed the contrast of every text colour in their stylesheet with the formula WCAG gives for relative luminance, and the weakest pair, the red of an error message on white, was 6.47:1, comfortably above 4.5:1. A requirement you already know you meet is a strong one to put in front of an examiner.

Safety was considered and left out, in writing. Nothing the canteen system does can put a person or property in danger, and the SRS says so under safety, so the reader knows the question was asked.

Do this for your project

1. Go down the nine ISO/IEC 25010 characteristics. For each, write a requirement or a sentence saying why none is needed.
2. For each requirement answer the five questions: quality, measure, target, conditions, verification.
3. Take numbers from standards where they exist: WCAG 2.2 for accessibility, the OWASP cheat sheets for security.
4. Take performance numbers from your own load estimate, with a margin.
5. Add a "verified in" column and make sure your test plan in Module 2 contains every test it names.
6. Where you can, measure before you promise.

Mistakes that cost marks

Adjectives instead of numbers. Fast, secure, reliable, user-friendly, scalable: none is testable without a number and a condition.

A target with no conditions. "Within 1 second" on what machine, with how many users?

A non-functional requirement no test ever checks. It is a claim in the SRS the examiner can ask you to demonstrate.

Security as one line. Security is several different requirements about passwords, sessions, access and attack, each tested differently.

Accessibility forgotten. Many examiners now ask about it, and WCAG 2.2 gives you ready-made, testable requirements.

Quick revision

• A non-functional requirement says how well; it needs a number and a way to verify it.
• ISO/IEC 25010:2023 has nine characteristics: functional suitability, performance efficiency, compatibility, interaction capability, reliability, security, maintainability, flexibility, safety. The 2011 edition had eight.
• Five questions: which quality, measured how, to what target, under what conditions, verified how.
• Borrow numbers: WCAG 2.2 (contrast 4.5:1, reflow at 320 CSS px, targets 24 by 24 CSS px, keyboard, labels); the OWASP cheat sheets for security.
• Performance targets come from your own load estimate, with a margin.
• Every requirement has a "verified in" entry that leads to a real test.

Questions you must be able to answer

1. Distinguish functional and non-functional requirements with one example of each from the worked project. A functional requirement states a behaviour: the system shall let a student cancel their own order while it is placed. A non-functional requirement states how well the system behaves: with 100 students ordering in the same minute, 95 per cent of menu and order requests are answered within 1 second.

2. What is ISO/IEC 25010, and how is it used when writing requirements? The international standard that defines a product quality model for software; its 2023 edition has nine characteristics, each with sub-characteristics. It is used as a checklist: for each characteristic the team either writes a measurable requirement or records why none is needed.

3. Rewrite "the system should be user-friendly" as testable requirements. For example: a one-item order takes no more than 4 taps from the menu page; every page is usable at 320 CSS pixels wide without sideways scrolling; every input has a visible label; every counter action is a single tap.

4. Why does NFR-1 say 95 per cent and name the lab server? Because under load a few requests are always slower, so the requirement limits how many may be, and because performance depends on the machine and the load, so a target without its conditions cannot be tested or reproduced.

5. Which WCAG 2.2 success criteria did the worked project adopt, and what does each require? 1.4.3, text contrast of at least 4.5:1; 1.4.10, no two-dimensional scrolling at 320 CSS pixels wide; 2.5.8, pointer targets of at least 24 by 24 CSS pixels; 2.1.1, all functions operable from a keyboard; and labels for every input, as 3.3.2 requires.