Functional requirements, quality attributes and constraints

Three kinds of requirement

A requirement is anything a system must satisfy to be acceptable to its stakeholders. Architects find it useful to sort requirements into three kinds, because each kind influences the design in a different way. A functional requirement says what the system must do: 'a customer can add an item to the basket', 'the pharmacy system checks every new prescription against the patient's allergies', 'a rider can see the driver's position on a map'. Functional requirements describe behaviour, data and the rules that connect them. They are what most user stories and use cases capture.

A quality attribute says how well the system must do it. 'Search results appear within half a second', 'the booking service is available 99.95% of the time', 'a new payment provider can be added in under two weeks', 'patient records are readable only by clinicians treating that patient'. Quality attributes are properties of the system as a whole or of a function, and they only make sense with a measure attached: fast enough for whom, under what load, measured how?

A constraint is a decision that has already been made for you. 'The system must run in the company's existing Azure tenancy', 'all personal data stays in the European Union', 'the team knows Java and has no budget to retrain', 'the first release must be live before the tax year starts on 6 April'. Constraints remove options rather than describe behaviour. They are not negotiable within the project, although a good architect checks that each one really is a constraint and not just a habit or an assumption.

The boundaries are not always crisp, and that is fine. The point of the classification is not bureaucratic tidiness; it is to make sure that nobody collects fifty user stories and forgets to ask how many users there will be, how long the business can survive an outage, or which regulator is watching.

Why many architects avoid the term 'non-functional requirements'

Requirements documents traditionally split everything into functional and non-functional requirements (NFRs). The term is everywhere, in contracts, tender documents and job adverts, so you need to recognise it. Many architects and researchers nevertheless avoid it, for three reasons.

First, it defines a large and important category by what it is not. Anything that is not a function lands in the same bin: response times, encryption rules, the choice of cloud provider and the colour of the logo. Martin Glinz's paper On Non-Functional Requirements (IEEE International Requirements Engineering Conference, 2007) showed that published definitions disagree on what belongs in the category and that the same need can be classed either way depending on how it is phrased: 'only authorised staff may see salaries' reads as a function when written as an access rule and as a quality when written as a security goal.

Second, the name suggests these requirements are separate from functions and can be added later. They cannot. A quality attribute qualifies a function: it is the checkout that must be fast, the payment that must never be lost, the medical record that must be confidential. Bass, Clements and Kazman, in Software Architecture in Practice, therefore speak of quality attribute requirements and treat constraints as a separate category.

Third, 'non-functional' sounds optional, as if a system that works but is slow, insecure or impossible to change still 'functions'. In practice those are exactly the systems that get rewritten. Some teams prefer 'quality requirements'; others, notably at Thoughtworks, say 'cross-functional requirements' to stress that they cut across every feature. This course uses quality attributes and constraints. If your organisation says NFRs, there is no need to fight about the word; just make sure every NFR is either a measurable quality or a clearly stated constraint.

Constraints: technical, organisational, regulatory, time and budget

Constraints deserve more attention than they usually get, because they often decide more of the architecture than any feature. A constraint is simply a requirement with no remaining freedom. It helps to group them by where they come from.

Two habits help. First, write down the source of every constraint (a regulation, a contract, a named decision-maker) so that it can be checked and, if circumstances change, revisited. Second, distinguish real constraints from preferences dressed up as constraints. 'We must use microservices' is rarely a constraint; it is a design decision someone made early, and it should be justified by quality attributes like any other decision. Chapter 1's section on decisions and trade-offs explains why early, hard-to-reverse choices deserve that scrutiny.

Architecturally significant requirements

Most requirements do not affect the architecture. Whether the invoice shows the customer's postcode above or below the street name is a detail; it can be changed in an afternoon. An architecturally significant requirement (ASR) is one that has a measurable effect on the architecture: if it changed, the structure of the system would have to change. Recognising ASRs early matters because they are expensive to accommodate late. Adding a waiting room to a ticketing site the week before a sale is possible; partitioning the seat inventory across servers after launch is a rewrite.

Lianping Chen, Muhammad Ali Babar and Bashar Nuseibeh interviewed practitioners about how they recognise ASRs (Characterizing Architecturally Significant Requirements, IEEE Software, 2013). Their findings match most architects' experience. ASRs tend to be hard to satisfy, they often concern the system as a whole rather than one feature, they frequently conflict with each other, and they are often stated vaguely or not at all. Quality attributes and constraints make up the majority, but some functional requirements are significant too.

Examples of functional ASRs: 'every change to a patient record must be traceable to a person and a time' (it needs an audit mechanism across all components), 'users can collaborate on the same document in real time' (it demands a synchronisation model and probably a different communication style), and 'customers can undo a bank transfer within 30 minutes' (it affects how money moves between accounts). Each forces a structural decision, not just more code.

Why qualities shape architecture more than functions do

Here is the central idea of this chapter. If functionality were all that mattered, almost any structure would do: you could write the whole system as one large program and it would still compute the right answers. Bass, Clements and Kazman make this point directly: functionality does not determine architecture, because many different architectures can deliver the same functions. What separates them is how well each one achieves the qualities.

Consider two ticketing systems with identical features: browse events, hold seats, pay. One sells tickets for a 300-seat village hall; the other sells a 60,000-seat stadium tour. The village hall's busiest moment might bring a few requests per second, and a single web application with one database is the right answer: cheap, simple and easy to change. The stadium tour must absorb a burst thousands of times larger, must never sell the same seat twice, and must keep bots from buying everything in the first second. That system needs a content delivery network, a queue in front of the shop, a carefully designed seat inventory, partitioned storage and a payment flow that can wait for an overloaded provider. Same functions, completely different architectures, and the difference comes entirely from quality attributes and constraints.

Implicit qualities nobody writes down

Some of the most important qualities are never stated because every stakeholder assumes them. These implicit requirements surface only when they are violated, usually in production. Nobody writes 'do not lose orders', 'do not charge the customer twice', 'keep working when the clocks go forward', 'show the same balance on the phone and the website', or 'do not leak one customer's data to another'. Yet each of these is an ASR with heavy consequences: idempotent payment handling, durable writes, time-zone-safe scheduling, consistency between channels and strict tenant isolation.

Implicit requirements hide for social reasons. Business stakeholders think they are too obvious to mention; developers assume someone else has handled them; and requirement templates rarely prompt for them. Useful questions to flush them out are: 'What would make you furious if it happened?', 'What would put us in the newspaper?', 'What has gone wrong with the system we are replacing?', and 'What does the operations team get woken up for?'. Incident reports and support tickets of predecessor systems are a rich source; so are regulators' published guidance and the obligations in customer contracts.

How professionals work with ASRs

Experienced architects keep a short, living list of ASRs, typically five to fifteen items, rather than a long requirements document. Each item states the quality as a testable scenario (Section 2.3), names the stakeholder who cares, records its priority and links to the decisions it drove. The arc42 template, for example, asks for the top three to five quality goals on its first page and a fuller list of quality requirements later. The list is revisited whenever a big decision is made or the business changes direction, and the most important items are eventually backed by automated checks called fitness functions, introduced in Section 2.8.