Functional and non-functional requirements: the full picture

Why non-functional requirements matter more than functional ones

Functional and non-functional requirements compared, and why the second set usually drives the design.

Functional requirements describe what a system does. They're the features, the user stories, the capabilities that appear in backlogs and get demonstrated at sprint reviews. They matter, obviously. But they rarely drive architecture. Two systems with identical functional requirements can have completely different architectures depending on how fast they need to respond, how many users they need to support, how available they need to be, and how secure the data is. Those are non-functional requirements, and they're the ones that actually shape the design.

Consider a simple example: a service that lets citizens report energy performance data. The functional requirement is straightforward: accept a form submission, validate it, store it, and confirm receipt. You could build that with a static form and a single database. But add the non-functional context and the architecture changes completely. The service needs to handle 50,000 submissions in the final week of a reporting deadline. It needs to be available 99.9% of the time during that window. It processes personal data, so it needs appropriate security controls. It must meet WCAG 2.2 AA. Suddenly the architecture involves queuing, autoscaling, caching, monitoring, and a fundamentally different deployment model. The functional requirement didn't change. The non-functional requirements drove every significant design decision.

This is why architects who focus only on functional requirements produce designs that work in demos but fail in production. The architecture is shaped by the qualities the system must exhibit, not just the tasks it must perform.

Functional requirements tell you what to build. Non-functional requirements decide whether what you build will survive contact with production.

Performance: what "fast enough" actually means

How to turn "the system should be fast" into something an architect can actually use.

"The system should be performant" is not a requirement. It's a wish. Performance requirements only become useful when they name the operation, the load, the target, and the conditions. A useful performance requirement looks like this: "The search results page must return within 2 seconds for 95% of requests under a concurrent load of 500 users." That gives you something to design for, test against, and monitor in production.

In government services, performance matters because users often have no alternative. If a commercial site is slow, people leave and use a competitor. If a government service is slow, people are stuck, and they lose trust in the institution. The Service Standard expects services to work well for everyone, and that includes people on slow connections, older devices, and assistive technologies where performance overhead compounds.

When capturing performance requirements, think about response time targets for key operations, throughput under expected and peak load, behaviour under stress (graceful degradation rather than catastrophic failure), and deadline spikes where load concentrates around specific dates. Be specific about percentiles: a 2-second average means half your users experience something worse. A 2-second 95th percentile is a much stronger commitment. And always ask what happens when the target is missed. If the answer is "nothing much," it's probably not a hard requirement. If the answer is "citizens can't file their tax return," it's a constraint that shapes your entire architecture.

Ask how fast, under what load, for which operation, and at what cost. Anything looser is a hope, not a requirement.

Scalability and availability: designing for reality

The two properties that determine whether your service holds up when it matters.

Scalability is the ability to handle growth, whether that's more users, more data, or more transactions. Availability is the ability to keep working when things go wrong. They're related but distinct: a system can scale well but have poor availability if it has single points of failure, and a highly available system can still fall over if load exceeds what it was designed for.

For scalability, the key questions are: what's the expected growth pattern, is it gradual or does it spike around events and deadlines, and does the architecture support elastic capacity or does it require manual intervention to scale? Government services often have predictable spikes: tax deadlines, benefit payment dates, policy announcements that drive traffic. Designing for the average and hoping the peak works out is a recipe for outages at exactly the moment the service matters most.

For availability, the conversation starts with impact. What happens if the service is down for an hour? A day? A week? The answer determines the investment. A 99.9% availability target (roughly 8.7 hours of downtime per year) requires redundancy, automated failover, and robust monitoring. A 99.99% target (roughly 52 minutes per year) requires active-active deployment, zero-downtime releases, and significant operational maturity. Match the target to the real impact rather than picking a number because it sounds professional. And be honest about what "available" means: is it the whole service, or just the critical path? Partial degradation is often acceptable and much cheaper to achieve than full redundancy.

Design for the peak, recover from failure, and match uptime to real impact rather than industry folklore.

Security as an architecture concern

Why security has to be designed in from day one, and what that means in practice.

Security is not a feature you add at the end. It's a property of the architecture that either exists from the start or gets retrofitted at enormous cost. In government, the stakes are higher because you're handling citizens' data, and the trust relationship between government and the public depends on that data being protected properly.

The starting point is data classification. What data does the service handle? Is it OFFICIAL, OFFICIAL-SENSITIVE, or higher? Does it include personal data subject to UK GDPR? Does it include special category data? The classification drives the security architecture: what encryption is needed, where data can be stored, who can access it, and what audit trail is required. Get this wrong and you'll be redesigning the data layer after a security review rejects your approach.

The NCSC's Secure by Design principles provide the framework: understand your risks before choosing controls, make security proportionate to the threat, and design systems that are secure by default rather than relying on users to make safe choices. In practice, this means thinking about authentication and authorisation models early, designing network boundaries and data flows with security in mind, planning for secrets management and key rotation, and building audit logging into the architecture rather than bolting it on later. A Data Protection Impact Assessment (DPIA) is required for services processing personal data at scale, and it's far easier to complete when the architecture was designed with privacy in mind from the start.

Good security is designed in, not bolted on. Know your data, understand your risks, and choose controls that match the threat instead of performing compliance theatre.

Accessibility is the one NFR that isn't negotiable

Why accessibility shapes core architecture decisions, not just frontend polish.

Public sector services in the UK must meet WCAG 2.2 at AA level. This isn't optional, it's a legal requirement under the Public Sector Bodies Accessibility Regulations 2018. But accessibility isn't just a compliance checkbox; it's an architecture concern that affects fundamental design decisions.

Single-page applications (SPAs) built with heavy JavaScript frameworks create accessibility challenges that are expensive to fix after the fact: screen reader compatibility, keyboard navigation, focus management, and meaningful page announcements all require architectural support. Progressive enhancement, where the service works without JavaScript and is enhanced with it, is far easier to make accessible and aligns with the GDS Design System's approach. The choice of frontend architecture is an accessibility decision.

Content management systems, form builders, and PDF generators all need to produce accessible output by default. If your CMS can't generate semantic HTML, or your form builder doesn't support proper labelling and error handling, or your document generation creates inaccessible PDFs, you have an architecture problem that no amount of manual remediation will fix at scale. The GDS Design System provides accessible components and patterns, but only if your architecture can consume them properly. Choose technology that supports accessibility by default rather than fighting against it.

Accessibility isn't something you add at the end. If the architecture doesn't support accessible patterns from the start, you'll be rebuilding it before launch.

Operability and maintainability: building for the long term

Most architecture attention goes into building the system. Far less goes into running and changing it.

Operability is how easy the system is to run in production. Maintainability is how easy it is to change over time. Both are NFRs that get neglected because they don't affect the initial delivery, only everything that comes after it. Government services typically run for five to ten years. The team that built the service will move on. The people who inherit it need to be able to understand it, monitor it, deploy changes safely, and respond to incidents without the original architects on call.

Operability means designing for observability from the start: structured logging, meaningful metrics, distributed tracing, and health checks that tell you something useful. It means deployment pipelines that support zero-downtime releases, rollback capabilities, and feature flags for gradual rollouts. It means runbooks for common incidents and clear escalation paths. None of this is glamorous, but it's the difference between a service that runs smoothly and one that generates out-of-hours calls every week.

Maintainability means code that's readable, well-tested, and structured so that changes in one area don't cascade unpredictably. It means documentation that explains why decisions were made, not just what was built. It means dependency management that keeps libraries current rather than letting them drift into unsupported versions. Set specific targets: deployment frequency, mean time to recovery, change failure rate. These give future teams something to measure against and help you design an architecture that supports sustainable pace rather than heroic effort.

Design for the people who'll run and change the system after you've moved on. That work is the difference between an architecture that ages well and one that becomes everyone's least favourite codebase.

Capturing and quantifying NFRs

A practical approach to writing non-functional requirements that actually drive design.

The difference between useful NFRs and useless ones is specificity. "The system should be secure" tells you nothing. "All data at rest must be encrypted using AES-256, and all data in transit must use TLS 1.2 or higher" tells you exactly what to implement and test. The goal is requirements that are measurable, testable, and tied to real constraints rather than aspirational statements that nobody can verify.

Start with categories as a checklist: performance, scalability, availability, security, accessibility, operability, maintainability, and any domain-specific qualities that matter for your service. For each category, ask whether there's a real constraint. Not every service needs five-nines availability or sub-second response times. The requirement should reflect the actual need, not a gold-plated ideal.

Make each requirement measurable by specifying the condition, the metric, and the target. "Under normal load (up to 1,000 concurrent users), the case search must return results within 1.5 seconds at the 95th percentile." That's testable. Prioritise using MoSCoW or a similar method so the team knows which NFRs are hard constraints and which are desirable targets. Include the rationale: why does this number matter? What happens if it's missed? And define how each requirement will be verified, whether through automated testing, load testing, penetration testing, or operational monitoring.

Well-captured NFRs become the bridge between architecture decisions and acceptance criteria. They give developers clear targets, testers clear pass/fail conditions, and assessors clear evidence that the service meets its obligations.

Well captured NFRs are one of the most valuable artefacts an architect produces. They drive decisions, guide testing, and define what success looks like.

NFRs in the service assessment context

How service assessment criteria turn directly into NFR conversations, and how to be ready for them.

The Government Service Standard isn't separate from architecture; it's a direct source of non-functional requirements. Several standard points translate directly into NFR categories. Point 5 (make sure everyone can use the service) drives accessibility requirements. Point 9 (create a secure service) drives security requirements. Point 11 (choose the right tools and technology) drives maintainability and operability requirements. Point 14 (operate a reliable service) drives availability and performance requirements.

Service assessors will ask how you know the service is accessible, secure, reliable, and well-supported. They'll want evidence, not assertions. Strong NFRs give you that evidence base. If you can show that you defined specific accessibility targets, tested against them, and monitor them in production, you've answered the assessor's question before they finish asking it. If your answer is "we followed best practice," you'll get follow-up questions you may not be able to answer.

The practical approach is to map each relevant Service Standard point to specific, measurable NFRs early in the project. Use those NFRs to drive architecture decisions, build them into your test strategy, and track them through delivery. When assessment comes, you're not scrambling to produce evidence; you're presenting the natural output of a well-run architecture practice. The NFR specification becomes your assessment preparation, because it was always the same thing.

Don't treat service assessment as separate from architecture. Strong NFRs give you the evidence base that proves the service is accessible, secure, well justified, and reliable.