Non-Functional Requirements Analysis

Purpose

Non-functional requirements analysis specifies the criteria used to judge how a solution operates rather than its precise behaviours. A functional requirement describes a behaviour: the portal issues a premium statement, the system records a change of address. A non-functional requirement describes the quality of that behaviour: the statement renders in under two seconds, the portal stays available 99.8% of service hours, health data is encrypted at rest. The technique exists because this second half decides, on its own, whether users accept the solution: a service that is accurate but slow, unavailable at peak hours or non-compliant with data protection fails in operation even when each of its functions is correct.

NFRs also go by the name of quality attributes or quality-of-service requirements. They are readily associated with IT systems, wrongly: they apply just as much to the human and the process side of a solution. A process has a turnaround requirement, a workstation an ergonomics requirement, a team an availability requirement. An NFR does one of three things: it augments a functional requirement, it places a constraint on it or it describes a quality attribute the solution must exhibit.

The technique also answers a question functional requirements never pose: how far to push quality, given that it has a price. An attribute pushed to its maximum strains another and drives up cost. Security and performance compete for the same response time, availability and budget compete for redundancy, usability and functional richness compete for the screen. The analyst's job is then to compose the NFR portfolio that is most useful in a given context, each threshold held at the level the context warrants rather than at the maximum attainable. Determining that optimal portfolio is at the centre of the value the technique delivers.

The deliverable is a non-functional requirements catalogue: a register in which every row carries a quality attribute, a declarative statement, a metric, a threshold, a source and a verification method. Its value rests on a chain of measurable = testable = verifiable. An NFR fitted with a threshold becomes an acceptance criterion that is replayed at test time, and its verdict is binary: the threshold is met or it is not. The benefit comes down to a simple test: on acceptance day, each quality requirement produces a test that passes or fails, with no argument over what "fast" was meant to mean.

Usage

When to use it

• Solution whose operation carries the stakes: quality of service drives adoption as much as the functions themselves.
• Quality requirement phrased in vague terms: "fast", "easy", "reliable" to be converted into testable thresholds before any development.
• Quality attributes in competition: security, performance and cost compete for the same solution, and the trade-off must be set and recorded.
• Constraint imposed from outside: a regulator, certification standard or service-level agreement setting an enforceable minimum quality.
• Writing acceptance criteria: each quantified NFR feeds acceptance testing and the test plan directly.
• Architecture or procurement decision: availability, performance and security thresholds separate the technical options.
• International or multilingual expansion: localisation and compliance become quantified requirements specific to each jurisdiction.
• Replacing a system in operation: measure the service levels met today to set the thresholds the successor must at least match.

When not to use it

• Irreducibly qualitative attribute: no honest metric exists, so gather a structured acceptance judgement from users rather than impose an arbitrary threshold.
• Throwaway prototype or proof of concept: the solution will never reach operation, so drop the formal catalogue and frame only the few constraints that would block the demonstration.
• Requirement source still unstable: regulation or scope still being defined, setting a threshold now freezes a false target, so wait for the context to settle.

Description

The quality-attribute categories

An NFR always belongs to a quality-attribute category, and the list of categories is the inventory the analyst sweeps so as not to forget a dimension. BABOK lists about fifteen, and the reference model they attach to is the ISO/IEC 25010 standard, the product quality model of the SQuaRE series. The 2023 revision organises quality into nine characteristics: functional suitability, performance efficiency, compatibility, interaction capability (the former usability), reliability, security, maintainability, flexibility (widened from portability, it now covers adaptability, scalability and replaceability) and safety (new). Each characteristic breaks down into measurable sub-characteristics.

The categories met most often in business analysis deserve a definition, because it is the category that suggests the metric. Availability measures the share of time the solution is operable when needed, usually a percentage over a defined service window. Performance efficiency measures the resource consumed to deliver a service and varies by context (peak hour, off-peak). Reliability measures the ability to hold a function over a given duration, often by a mean time between failures. Scalability measures the ability to absorb increased load. Security protects content and components against accidental or malicious access, modification or disclosure. Usability measures ease of learning and of use. Compliance covers the regulatory, financial and legal constraints, which vary by jurisdiction. Localisation covers languages, currencies, formats and local conventions. Service-level agreements (SLAs), finally, are constraints agreed formally between the supplier and the organisation served, and they carry their own measure of success.

Measurement at the heart of the technique

An NFR is almost always stated first in vague terms, because that is how stakeholders express it: "the process must be easy to learn", "the system must respond fast". In that form it is unusable, for two reasons that are really one. The developer does not know what to build, for lack of a target. The tester does not know what to verify, for lack of a threshold. The technique consists in quantifying the requirement whenever possible, and an appropriate measure of success is the occasion for a verification. BABOK's two canonical transformations illustrate it:

• "The process must be easy to learn" becomes "90% of operators must be able to use the new process after at most six hours of training".
• "The system must respond fast" becomes "the system must deliver 90% of responses within two seconds".

The target form carries four pieces. A metric: what is measured (share of self-sufficient operators, response time at the 90th percentile). A threshold: the value to hold (90%, two seconds). A condition: the measurement context (after six hours of training, under nominal load). A source: where the threshold comes from. For some categories the source dictates the measure with no negotiation. Certification points to a standard (an ISO, an industry standard). Compliance and localisation are fixed in measurable detail by their authority. An effective SLA states its own measure of success. The organisation's enterprise architecture defines the requirements tied to the solution's environment. The metric is often retrieved from the source that imposes it.

Context and conflicts between requirements

The relevant category and the right threshold depend on the context. A regulator imposes compliance and security, an expansion abroad triggers localisation and scalability. The right threshold is a property of the context more than of the attribute itself: a jurisdiction can make an acceptable performance or reliability target lower than elsewhere, legitimately lowering a threshold one might have thought fixed. The context is also dynamic: an NFR is revised or withdrawn when its source moves, and the analyst weighs the stability of the context before setting a threshold in stone.

Above all, the interaction between attributes is the real subject. Setting security to the maximum, through heavy encryption and exhaustive logging, degrades the response time performance aims at. Aiming for extreme availability multiplies redundancy, hence cost. Exhaustive localisation weighs on maintainability, every screen then existing in three languages. These tensions do not read line by line, they show up only when looking at the catalogue as a whole, and that is why the technique produces a catalogue rather than a collection of isolated requirements. The trade-off is then conducted explicitly: name the two attributes in conflict, designate the one that wins in this context, record the threshold kept for each and the reason. A priority, on the MoSCoW model, makes that trade-off legible: the mandatory requirement holds, the desirable one gives way first when the budget tightens.

What makes the exercise fail

Leaving the requirement at the vague stage

An NFR with no metric or threshold travels the whole project and is settled as a dispute at acceptance, when the person who said "fast" and the one who built "fast" discover they were not talking about the same thing.

Inventing a threshold nothing grounds

A "99.99%" set down to look serious commits a real cost without any source requiring it. The threshold ties to an expectation, an SLA, a standard or a measurement of what exists, failing which it is arbitrary.

Over-constraining

Requirements that are too strict add time and cost, and that weight harms the adoption they claimed to serve. A ninth digit of availability can cost more than the outage it prevents.

Treating NFRs as purely IT

The process and human sides of a solution carry their own quality requirements, and ignoring them leaves a whole span of quality of service without a target.

Settling each requirement in isolation

Conflicts between attributes (security versus performance, availability versus cost) show up only by looking at the whole catalogue, and a requirement maximised alone in its corner silently breaks another.

Forgetting to tie the threshold to a verification

A threshold nothing measures in operation is a wish. Each row of the catalogue names the method that will prove, one day, that it is met.

AI considerations

The first useful use of a language model is shaping the vague requirement. Given an informal statement ("the portal must be responsive") and the target category, the model proposes a candidate quantified wording, with a metric and a threshold slot to fill. It does the mechanical half of the work (fitting the template) and leaves the analyst the only part that matters: the choice of the threshold and its source. The second use is a completeness sweep: feed it the list of quality-attribute categories and the description of the solution, and the model flags the categories for which no requirement is written, surfacing the oversights (no one had thought of portability, of maintainability). The third use is conflict detection: feed it the catalogue, and the model flags the pairs of attributes in likely tension (a security threshold and a performance threshold hard to reconcile), surfacing trade-offs to work through that a line-by-line reading lets slip.

The limits follow the nature of the technique. The threshold is a business decision, not data to generate: choosing 99.8% over 99.9% commits a cost and a risk only the business can weigh, and a model that proposes a plausible number masks the absence of grounding under an appearance of rigour. Resolving a conflict between two requirements (lowering security to hold performance or the reverse) is a trade-off that belongs to the responsible parties, never to a tool that decides in silence. The residual subjectivity of qualitative attributes escapes the model: what is "fast enough" for one user is not for another, and no generation replaces the negotiation that aligns expectations. Finally, an NFR catalogue describes a system's defences (encryption schemes, security thresholds, compliance points): submitting it to an external service exposes a map of vulnerabilities, and this work is conducted on tooling the organisation controls.

Examples

The catalogue covers the self-service portal of a health insurer in French-speaking Switzerland, through which the insured consult their statements and report a change of circumstances. It gives one row per quality-attribute category, to show the target form: each requirement carries a metric, a threshold, a source and a verification method, and each replays as an acceptance criterion. The column that carries the technique is the threshold, because that is what makes the requirement testable.

Three readings come out of the catalogue. The Usability row reuses BABOK's canonical metric (90% of operators self-sufficient after at most six hours): an attribute reputed subjective becomes a practical test whose verdict is binary. The Security and Performance rows are in tension, because the encryption and logging the first imposes weigh on the response time the second aims at, and it is the whole catalogue that makes this trade-off visible. The Localisation row is nothing incidental in a country with three official languages: screens in French, German and Italian and amounts in CHF with the apostrophe separator are a quantified requirement, verified at acceptance, on the same footing as availability.

Visualisations

Two artifacts, two forms. The transformation of the requirement, from the vague stage to the verifiable threshold and then to the acceptance criterion, is a directed sequence: it is drawn as a diagram that shows the technique's central operation. The NFR catalogue is a grid of rows and columns: it stays a table, readable, selectable and resizable. That is the right form, since all the value rests on a column-by-column comparison: does each requirement indeed have its metric, its threshold, its source, its verification. A quality attribute with no threshold then stands out at a glance, like an empty cell in the column that carries the technique.

Cost

Tools

A spreadsheet is enough to hold the catalogue while the volume stays modest: one column per piece of the statement, namely the attribute, the metric, the threshold, the source and the verification. Sorting by column then surfaces the missing thresholds. Its limit is traceability, because a spreadsheet does not mechanically link the NFR to the functional requirement it constrains or to the test that verifies it.

The next step up hosts the NFRs in the requirements tooling the organisation already owns: a dedicated requirement type in a repository such as Jama, Polarion or Azure DevOps or structured pages in Confluence wired to Jira. The gain is the link: each NFR ties to the function it qualifies and to the test case that verifies it, and the impact analysis of a threshold change becomes a query. Prioritisation techniques, MoSCoW ranking foremost, structure the priority column and the debate that fills it. Testing tools (load-testing platforms for performance, vulnerability scanners for security, monitoring dashboards for availability) close the loop by producing the measurement that proves, in operation, that the threshold is met. It is this pairing of a threshold with a measuring instrument that separates a finished NFR from a wish.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.30 Non-Functional Requirements Analysis.
• ISO/IEC 25010:2023, Systems and software engineering, SQuaRE, Product quality model: the product quality model, the reference for quality-attribute categories (nine characteristics).