Requirements and the Quality Attributes That Decide Architecture

Lesson 1 established that a solution architect is accountable for fit. But fit to what? You cannot design a solution that fits requirements you have not surfaced, and the requirements that matter most are usually the ones nobody stated.

This lesson is about extracting them. It is the least glamorous part of architecture and the highest-leverage, because a design built on wrong or missing requirements is not a fixable mistake, it is the wrong building.

Requirements come in two fundamentally different kinds, and confusing them is a classic failure:

• Functional requirements: what the system does. "Customers can reset their password." "The system generates a monthly invoice." Features and behaviors.
• Non-functional requirements (NFRs): how well it must do it. "Handle 10,000 concurrent users." "Be available 99.9 percent of the time." "Respond in under 200 milliseconds." Qualities and constraints.

Here is the counterintuitive truth this lesson builds toward: the non-functional requirements usually drive the architecture more than the functional ones. What the system does often has many possible designs. How well it must do it narrows those designs brutally, and often to one. Two systems with identical features can need completely different architectures purely because of their NFRs.

So the architect's central skill is not listing features. It is uncovering, and pinning down, the qualities the system must have, which is where most of the design pressure comes from.

The claim that "how well" matters more than "what" deserves proof, because it is the heart of architectural thinking. Take one function, "users can post a message," and vary only the non-functional requirements.

• Ten users, occasional use. A single small server with a simple database. An afternoon's work.
• Ten million users, global, instant delivery, never loses a message, never goes down. Now you need distributed data storage, replication across regions, message queues, caching, failover, and careful consistency handling. Months of work and a fundamentally different system.

Same feature. The functional requirement, "post a message," did not change at all. The architecture changed completely, driven entirely by the non-functional requirements: scale, availability, durability, latency.

This is why experienced architects push hardest on NFRs. The functional requirements tell you what boxes to draw; the non-functional requirements tell you how those boxes must be built, connected, and multiplied, and that is where the cost, the risk, and the real design decisions live.

It is also why NFRs are dangerous when missed. A team can build every feature perfectly and still fail completely because the system falls over at real load, loses data, or is too slow to use. Those are not bugs to patch later; they are architectural properties that must be designed in from the start. You cannot bolt on scalability or availability to a system that was not built for it, which is exactly why the architect must extract these requirements before designing, not after launch when the system buckles.

Non-functional requirements are also called quality attributes, and informally, the -ilities, because so many end in those letters. Having a checklist matters, because the quality nobody thought to ask about is the one that sinks the project.

The international standard ISO/IEC 25010 gives a widely used catalogue, organizing software quality into eight characteristics. In practical architecture terms, the ones that most shape a design include:

• Performance efficiency: speed and resource use. How fast, under how much load, at what cost?
• Reliability: availability and fault tolerance. How often can it be down? What happens when a part fails?
• Security: protecting data and access. Who can do what, and how is it enforced?
• Maintainability: how easily it can be changed. Cheap to evolve, or brittle?
• Compatibility / interoperability: how well it works with other systems it must connect to.
• Usability, portability, and functional suitability round out the eight.

Beyond ISO's list, architects also weigh scalability (handling growth) and cost as first-class concerns, because both directly constrain the design.

The value of the catalogue is as a prompt. For any system, the architect walks the list and asks: does this one matter here, and how much? For a banking system, security and reliability dominate. For an internal tool, maintainability and cost matter more, and 99.99 percent availability would be wasteful over-engineering. Not every quality matters for every system, and pretending they all do is its own failure, you cannot maximize everything, which is the trade-off problem of Lesson 3. The catalogue's job is to make sure nothing important is silently forgotten.

Here is where most requirements work goes wrong. Stakeholders state quality needs in words that feel meaningful and are actually empty: "the system must be fast," "it should be highly available," "it needs to be secure." These are not requirements. They cannot be designed against and cannot be verified, because everyone pictures a different number.

The architect's job is to turn each vague quality into a measurable, testable statement. Compare:

A useful technique from architecture practice is the quality attribute scenario: state the quality as a concrete situation with a measurable response. "When traffic spikes to 10x normal (stimulus), the system continues to respond within 500ms (response measure)." That format forces the vagueness out.

Why this is non-negotiable: a testable requirement can be designed toward and verified; a vague one cannot, so it is quietly interpreted differently by everyone and the mismatch surfaces only in production. "Fast" also has wildly different costs, 300ms and 10ms may demand entirely different architectures, so leaving it unquantified means you cannot even estimate the work. Numbers are what turn a wish into an engineering target. Extracting them, by pressing stakeholders past their comfortable vagueness, is one of the most valuable things an architect does.

Alongside functional and non-functional requirements sits a third category the architect must capture: constraints. These are fixed conditions the solution must live within, and unlike requirements, they are not negotiable and not yours to design away.

Common constraints:

• Existing systems. The solution must integrate with the databases, services, and platforms already running the business. This is often the single biggest shaper of a real-world design, and the one greenfield thinking ignores.
• Budget and timeline. A fixed amount of money and a hard deadline (recall the iron-triangle logic from project work).
• Team and skills. The people who will build and run it, and what they actually know. A design the team cannot build or operate is not a solution.
• Regulation and compliance. Data residency, privacy law, industry rules, none optional.
• Technology mandates. "We are a Microsoft shop." "Everything runs on our existing cloud." Standards set above the architect.

Constraints matter because they are where beautiful, textbook architectures meet reality and lose. The theoretically ideal design is irrelevant if it violates a hard constraint. In fact, a large part of the architect's skill is finding the best solution within the constraints, not the best solution imaginable. Constraints are not obstacles to good architecture; they are the boundaries that define what good architecture even means here.

The complete requirements picture, then, has three parts: what it must do (functional), how well (non-functional, quantified), and within what limits (constraints). Miss any one and the design is built on sand. With all three surfaced, the architect can finally do the part everyone pictures, choosing among options, which is where the real trade-offs begin.

See all three categories surface on one initiative. A hospital wants a "patient portal where patients can view their records and book appointments."

Taken at face value, that is two features. A good architect extracts far more.

Functional (what it does), clarified by questioning:

• View records, book, cancel, and reschedule appointments; receive reminders.

Non-functional (how well), pressed until testable:

• Security: "protected health data, so all access authenticated and authorized, encrypted in transit and at rest, every access logged for audit." (Non-negotiable given the domain.)
• Availability: "99.9 percent, since patients rely on it, with no scheduled downtime during clinic hours."
• Performance: "records load within 3 seconds for 95 percent of requests."
• Scalability: "support the full patient population, with headroom for a flu-season spike."

Constraints (the fixed limits):

• Must integrate with the existing electronic health record system (its data model is not changing).
• Must comply with health-privacy regulation (dictates data handling and residency).
• Fixed annual budget; the IT team knows one specific cloud.

Look at what dominates. The two features are trivial. The architecture will be decided almost entirely by security, availability, the health-record integration, and compliance, exactly the non-functional requirements and constraints, none of which appeared in the one-line request. An architect who built "view records and book appointments" without surfacing these would produce a system that is illegal, insecure, and unable to connect to the data it needs.

That gap, between what was asked for and what actually determines the design, is the entire reason the requirements phase exists.

The requirements discipline in one view.

The throughline for an aspiring architect: most of a system's shape is decided by the non-functional requirements and constraints, not the features, and both are usually unstated until someone extracts them. The functional requirements are the visible tip; the architecture-driving mass is below the surface.

Three habits make an architect good at this:

• Push past the first phrasing. "Real-time," "secure," "scalable" are the start of a conversation, not requirements. Keep asking until there is a number.
• Walk the quality-attribute catalogue. Use a list like ISO 25010 so an important quality is never silently forgotten, and consciously decide which ones matter here.
• Capture the constraints early. The existing systems, the budget, the team, the regulations. These are where real designs are actually made or broken.

Get this right and the design work becomes tractable, because the target is finally clear. Get it wrong and no amount of elegant design saves you, because you built the wrong thing well, the very failure Lesson 1 named.

With requirements in hand, the architect faces the real work: the options all involve trade-offs, and choosing among them, defensibly, is the craft of Lesson 3.

A solution architect extracts functional requirements (what it does), non-functional requirements pressed until quantified (how well), and constraints (fixed limits); the non-functional requirements and constraints, mostly unstated, drive the architecture far more than the features.