Non-Functional Requirements: The ISO/IEC 25010:2023 Quality Model, Making Them Measurable and Where to Record Them

Version note: This post is conceptual; the quality model follows ISO/IEC 25010:2023, published in November 2023, accessibility follows the W3C's WCAG 2.2, and personal data follows Turkey's Personal Data Protection Law No. 6698, known as KVKK.

Guess First

The Example Mapping sessions left four sentences in Selin's notebook that fit on no card. Gül: "When a 1,000-line list is pasted, check it without making people wait." Hakan: "The system must not go down in September; those two weeks are our year." Nevin Hanım: "Other schools must not see our order." The district library manager: "The municipality wants its digital services to be usable with a screen reader."

Three questions. Which of these sentences can go into the acceptance criteria of a single story? Which should hold for every story? Which one, once written down, forces the team to rethink an architecture decision? And a fourth question: how many seconds is "without making people wait"?

What Is a Non-Functional Requirement?

In the levels table of the first post we defined a non-functional requirement as one that says what quality the behaviour should have. A functional requirement says what the system does: "The system reports every ISBN not found in the catalog together with its line number." A non-functional requirement says how that same behaviour is delivered: how fast, open to whom, up under which conditions, accessible in what way.

The name is a little misleading. "Non-functional" suggests it does not touch what the system does, yet a screen that takes a minute to check a 1,000-line list is effectively non-functional in September. That is why the literature also uses "quality requirement" or "quality attribute requirement". Which name you use matters less than whether you write them as concretely as functional requirements.

We also covered the difference from constraints in the first post: a quality requirement can be negotiated within a range, while a constraint is a limit the team did not choose. "Invoices are exported to the existing ERP system" is a constraint; "the export finishes every night by 06:00" is a quality requirement. For the second you can talk to Bookstore accounting and get 07:00 accepted; for the first you cannot.

ISO/IEC 25010:2023: Nine Characteristics

ISO/IEC 25010 defines a quality model that breaks the quality of software products into characteristics and their subcharacteristics. One of the model's purposes is exactly requirements writing: a shared vocabulary for naming quality expectations and forgetting none of them. The 2011 edition had eight characteristics; the revision published in November 2023 raised that to nine. The main changes: safety was added as a new characteristic; usability was renamed interaction capability and portability was renamed flexibility. The subcharacteristics moved too: security gained resistance and flexibility gained scalability; under interaction capability the old accessibility was split into inclusivity and user assistance and self-descriptiveness was added; in reliability, faultlessness replaced maturity.

We do not reproduce the standard's definitions here; the standard is paid and its text is copyrighted. What is more useful is turning the nine characteristics into questions to ask about your own feature:

For a bookstore the last row stays almost empty, and that is fine. Use the model not as a form with every cell to fill but as a checklist: look at each characteristic and skip the irrelevant ones deliberately and with a reason. "Safety is out of scope for this feature because the system does not control a physical process" is a more valuable requirement record than never having thought about that row.

From "Make It Fast" to a Measurable Scenario

Gül's "without making people wait" is a typical catch of the vague word hunt from the first post. The established way to make it measurable is the quality attribute scenario: the source of the stimulus, the stimulus itself, the environment, the affected artifact, the system's response and the measure of that response. We covered each of the six parts in detail, along with why averages mislead and why percentiles are a better measure, in the Introduction to Architecture series post "Quality Attribute Scenarios". Here we use the same tool from the requirements side and focus on the real question: where do the numbers come from?

We build the environment from data. The document analysis in post 02 showed that 46 institutional orders came in last September and the largest list had 870 lines. Almost all of the orders were squeezed into the first two weeks of September; the busiest day had 9. So the problem is not thousands of simultaneous users but the size of a single request. This tells us that a sentence copied from another project, like "must handle 10,000 concurrent users", does not belong here.

We build the response measure from measurement. When the walking skeleton runs at the end of the first sprint, Ayşe validates the real 870-line list a hundred times in the test environment: the p95, the time 95 percent of requests stay under, is 2.1 seconds. Leaving room for fifty percent growth and a margin, the team proposes 5 seconds for 1,000 lines; Nevin Hanım is asked about that time in the prototype and answers "I'll paste the list and get my coffee." The scenario is written like this: "During the first two weeks of September, while ten institutions place orders within the same hour (environment), when a purchasing officer (source) pastes and checks a 1,000-line list (stimulus), the validation endpoint (artifact) returns a result for every line (response); this request stays under 5 seconds at p95 and never exceeds the 30-second timeout (measure)."

The value of this sentence is that every number in it has a source. 1,000 lines comes from document analysis, 5 seconds from measurement and a conversation with the user, ten institutions from last September's busiest day. If one number changes, say a library chain starts sending 3,000-line lists, it is clear which one changed and why.

Other Quality Requirements of the Institutional Order

Hakan's "must not go down" falls under reliability, and it needs a number too. Bookstore's answer: "Between September 1 and 15, on business days between 08:00 and 20:00, the institutional order flow is available at least 99.5 percent of the time." That allows about 40 minutes of downtime in total over roughly eleven business days. The target for the rest of the year is looser; writing the requirement together with its environment saves the team from holding itself to the September standard all year. A recoverability sentence goes next to it: if the session drops, the pasted list comes back as a draft with at most one minute of loss.

Nevin Hanım's sentence falls under security and produces two separate requirements. One is confidentiality: "A user of an institution sees only their own institution's orders; a request with another institution's order number gets a not-found response that does not even reveal the order exists." This is the requirements-side counterpart of the IDOR flaw we covered in the Web Security (OWASP Top 10) series post on OWASP A01 Broken Access Control. The other is accountability: "Every status change of an institutional order is recorded with the user who made it, the time, and the previous and new status; application users cannot change these records." The team does not invent how many years the records are kept; Bookstore accounting and legal decide, and the number goes into the requirement.

A detail from elicitation brings KVKK into play here. School lists sometimes include teachers' names and class sections. One of the principles in Article 4 of the law is that personal data must be relevant, limited and proportionate to the purpose for which it is processed; another is that it must not be kept longer than the purpose requires. An order needs only ISBN, quantity and delivery point. The requirement is written accordingly: "The system stores only the ISBN and quantity columns of a pasted list; other columns are discarded after validation." The purchasing officer's contact details, on the other hand, are personal data, and legal decides their retention period too. The team does not do the legal assessment; it writes the requirement and has it approved by the company's data protection officer.

The library manager's sentence falls under the inclusivity subcharacteristic of interaction capability. "Make it accessible" is again unmeasurable; WCAG 2.2, however, offers measurable success criteria. The team sets level AA as the target for the validation results screen and names the four most critical criteria for that screen: wrong lines are marked with text, not only with red (1.4.1 Use of Color); every error is identified in text with its line number and reason (3.3.1 Error Identification); the whole flow can be completed with the keyboard alone (2.1.1 Keyboard); a result message like "3 lines have errors" is announced to screen readers without moving focus (4.1.3 Status Messages). The details of the criteria and the obligations in Turkey are the subject of the Accessibility (a11y) series.

Where Do They Go?

Depending on where they are written, quality requirements either live or get forgotten on a wiki page. The Bookstore team uses four places and asks three questions for every requirement: does it belong to one story or to every story? Does it change the structure of the system? Can it be checked automatically?

The first two rows continue the distinction from post 05: if an item repeats in every story, it moves to the Definition of Done. In the third row the requirement has become an input to comparing options; in the Architecture Decisions series we saw in "Trade-off Analysis" how quality attribute scenarios are used to weigh options, and in "Writing ADRs" how the decision is recorded. The fourth row is the requirements side of the idea in the same series' "From ADR to Automated Check": if a quality expectation can turn red in CI, nobody needs to remember it.

A requirement can live in more than one place. The 5-second rule sits both in the story's acceptance criteria and in a fitness function; the first answers "is this story done?", the second "is it still true six months later?".

A Number Written Without Measuring

A measurable requirement also has to be measured, and that happens at three separate moments. First, before writing it: measure today's state, a baseline. Without Ayşe's 2.1-second measurement, 5 seconds could have been either impossible or meaninglessly loose. Then, before delivery: repeat the same scenario with the same data in an environment similar to production. The details of measuring under load, workload modeling and k6 tests wired into CI are the subject of the Performance and Load Testing series. Finally, in production: watch p95 with telemetry and look at the real number when September comes. The number in the requirement was an estimate; the production measurement is its verification.

You do not have to reject a requirement you cannot measure; but mark it as such. If "managers can read the report easily" cannot be measured today, write a verification method next to it: "a ten-minute usability test with two accounting staff, completed without help". The measure does not have to be a number; it has to be a repeatable check.

In Production

Write a quality requirement together with its environment. If "99.5 percent available" doesn't say for which period, which hours and which flow, the team either invests in the wrong place or everyone means something different when an outage is discussed.

Give every quality requirement an owner. The Product Owner owns the 5 seconds, corporate sales owns the availability window, legal owns the retention period. If a number is going to change, it is clear whose approval it needs.

Reopen the numbers from time to time. If after September the real p95 was 1.2 seconds and nobody complained, 5 seconds may be giving the team false comfort; if a single request hit the 30-second timeout, that request's list is most likely next year's environment.

Do not interpret legal requirements inside the team. For topics such as KVKK, accessibility regulations or the retention period of accounting records, the team writes the requirement but legal or the compliance officer approves its content; the approval is noted next to the requirement with its date.

Common Pitfalls

The first pitfall is leaving quality requirements to the end of the project. When accessibility and institution isolation are bolted on after the screens and endpoints are finished, every screen and every endpoint gets reopened. Even the first version of the walking skeleton should have an institution isolation test and a keyboard check.

The second is unmeasured items: "The system must be secure", "the system must be scalable". Sentences like these sit in a backlog for years, are never done and influence no decision. Turn each one into at least one scenario or checkable sentence; if you can't, you don't have a requirement yet, you have a concern.

The third is copying numbers from another project. "99.99 percent availability" or "200 ms response time" may make sense for an e-commerce storefront; for an institutional flow that receives 46 orders a year, those numbers make the team spend months on the wrong problem.

The fourth is turning a quality requirement into a story starting with "As a system". It is the twin of the "As a developer" pitfall from post 03: "As the system, I want to be fast" gives value to nobody and is never done. The requirement goes into the acceptance criteria of the story it belongs to, the Definition of Done or a fitness function.

The fifth is using ISO/IEC 25010 as a form to fill in. A document with a sentence for every subcharacteristic under all nine characteristics produces forty lines nobody reads. The model is a checklist; the real work is writing good scenarios for the three or four characteristics that matter.

A Small Experiment

★☆☆ Search your team's backlog or wiki for the words "fast", "secure", "scalable" and "user-friendly". Label every sentence you find with one of the nine characteristics of ISO/IEC 25010:2023 and look at which ones are not represented at all.

★★☆ Write a quality attribute scenario for a feature you are working on. Note the source of every number next to it: measurement, document analysis, a conversation with users, or a guess. Make a plan to measure the numbers whose source is "guess".

★★★ Move an existing quality requirement to the most suitable of the four places in this post's table. If it fits a fitness function, write a small check that runs in CI; if it fits the Definition of Done, discuss it with the team and add it; if it calls for an ADR, list the options of the decision.

We now have a specification with rules, examples and quality expectations. But it all still lives in human language, on cards and in story descriptions; when the code changes, nobody checks them automatically. In the next post we turn the output of Example Mapping into Gherkin: with Given-When-Then, Rule and Scenario Outline we will write an executable specification that stakeholders can read and computers can run.