The architecture of a product or information system shapes how it can be built, integrated, deployed, operated, and changed over time. Decisions made early can affect performance, security, reliability, accessibility, cost, and the organization’s ability to adapt the system later.

This chapter explains how to identify and document the requirements that should influence those decisions.

What Are Architecturally Significant Requirements?

Architecturally significant requirements, or ASRs, are requirements that have a substantial influence on how your solution is designed. They may affect the software, hardware, infrastructure, integrations, data, and processes that make up the system as a whole.

Many requirements concerning qualities such as performance, security, availability, and maintainability have historically been called non-functional requirements, or NFRs. However, this term can be misleading because it may make these essential qualities sound secondary or optional. Referring to a requirement as architecturally significant emphasizes its potential impact on the design rather than simply classifying it as functional or non-functional.

ASRs commonly include:

  • Quality Attribute Requirements: Define behaviors and measures like speed, security, and uptime.
  • System Constraints: Needs, rules or existing conditions that your solution must adhere to that limit design options.

Understanding ASRs is important because they drive major design decisions and often require trade-offs. Stronger security controls may add steps to the user experience. Greater availability may require redundant infrastructure and increase operating costs. Supporting tens of thousands of simultaneous users may require a more complex design that costs more to implement and maintain.

ASRs help you answer questions such as:

  • How many users or transactions must the system support?
  • How quickly must it respond under expected conditions?
  • What level of availability and recovery is required?
  • How must it protect sensitive information?
  • Which systems and data sources must it integrate with?
  • Which technologies, platforms, regulations, or standards constrain the solution?
  • How easily must the system be changed, scaled, tested, and maintained?

Identifying these high-impact requirements early helps you avoid committing to a design that cannot meet important performance, security, integration, or operational needs. Additionally, some architectural decisions are difficult or expensive to reverse once development is underway. You should therefore identify the requirements most likely to shape the architecture before making major design and technology decisions.

A Simple View of System Architecture

To identify architecture requirements, it helps to have a simple mental model of the parts of a system they may affect. One way to picture a system is as a set of connected layers, each responsible for a different part of the work. Not every system follows this structure exactly, but it provides a useful starting point for considering where requirements and design decisions apply.

User interface. This is where people interact with the system through web pages, mobile applications, dashboards, voice interfaces, or other channels. Decisions at this layer affect usability, accessibility, consistency, and how easily people can complete their work.

Application and business logic. This layer processes requests, applies business rules, and coordinates workflows. It determines how the system responds to different actions, events, and inputs.

Integration and communication. This layer allows the system to exchange data and requests with other components, services, devices, and external systems. It may include APIs, messaging services, integration platforms, and data pipelines. Decisions here affect reliability, interoperability, speed, and how dependent the system is on other systems.

Data storage and management. This includes databases, file storage, data warehouses, caches, and other ways of storing and retrieving information. Decisions about data models, storage technologies, ownership, retention, and access affect performance, consistency, scalability, privacy, and security.

Infrastructure and runtime environment. This includes the cloud services, servers, networks, operating systems, containers, and platforms the system runs on. These choices affect availability, scalability, deployment, cost, and the effort required to operate the system.

Some aspects of your solution need to be addressed by multiple parts of this architecture. Protecting sensitive data, for example, may require controls in the interface, application logic, integrations, data storage, infrastructure, and the connections between them.

Types of Architecture Requirements

The categories below represent common areas where architectural decisions can have significant consequences.

Accessibility

Accessibility requirements define how people with disabilities must be able to perceive, operate, understand, and interact with the system. They can affect interface components, authentication, document formats, notifications, keyboard operation, assistive-technology compatibility, and technology procurement.

Identify the organizational, contractual, or regulatory standard that applies and write testable criteria for the affected components and user journeys.

Accuracy

Some systems need calculations, measurements, or predictions to meet defined tolerances. You should define detailed, relevant rules, such as number of decimal places, allowable error or tolerance, validation method, and conditions under which the target applies. Avoid a general requirement that results must simply be “accurate.”

Availability

Availability requirements define when and how consistently a system must be accessible to its users (or other systems). Availability is usually expressed as a percentage over a defined period and should clarify whether planned maintenance is included. Related measures include maximum allowable downtime, mean time between failures, and mean time to recovery.

Performance

Performance requirements define how quickly and efficiently a system must respond under expected operating conditions. A target of two seconds may support a relatively simple design, while a target of 200 milliseconds may require caching, database optimization, asynchronous processing, or additional infrastructure. Tighter performance targets can therefore increase cost and architectural complexity.

Performance requirements should also specify the conditions under which the target applies, such as expected transaction volume, number of concurrent users, and peak load. They may conflict with other requirements, including security, consistency, reliability, and cost, so these trade-offs should be identified early.

Common measures include:

  • Response time: How long the system takes to complete a request, often expressed as a percentile, such as 95% of requests completing within two seconds.
  • Throughput: The number of transactions or requests the system can process within a defined period.
  • Concurrent users: The number of users the system can support at the same time while still meeting performance targets.
  • Resource utilization: Acceptable limits for processor, memory, storage, network, or database usage under expected load.

Scalability

Scalability requirements matter as soon as demand can grow faster than the current design allows. Scalability requirements define how well the system maintains performance as usage grows. You may need to scale vertically (adding resources to existing servers) or horizontally (adding more servers). The choice affects cost, complexity, and deployment strategy. A system designed only for vertical scaling may hit hard limits; one designed for horizontal scaling requires different approaches to data consistency and session management. Key measures include load handling capacity, resource allocation efficiency, and response times under varying workloads.

Security

Security decisions affect nearly every layer of the architecture, from how you authenticate users to how you encrypt data and handle logging. Stronger security often creates friction with usability and performance, so those trade-offs need to be discussed openly rather than left implicit. Security requirements should be explored early because they influence architecture, workflows, data handling, user experience, and operational practices.

Security requirements should state the required controls and how they will be verified. Examples include authentication and authorization rules, encryption for data in transit and at rest, logging and monitoring, vulnerability thresholds, and required security testing.

Governance and Compliance

Governance requirements come from laws, regulations, contracts, external standards, and organizational policies. Identify the source, version, and applicable clause or approved interpretation, including any conditions or exceptions that affect the requirement, and translate any obligations into system requirements. Common requirements related to compliance include:

  • Data handling. What data is in scope, where it may be stored, how it must be protected, and what can be done with it.
  • Access control. Who may access the data, what they may do with it, and what conditions govern that access.
  • Logging. What events must be recorded, what information each entry must contain, who may access the logs, and how they must be protected from alteration.
  • Retention and deletion. How long information must be kept and when it must be deleted. Minimum retention periods and maximum permitted retention periods may come from different obligations and may need to be reconciled.
  • Auditability. What evidence the system must produce to demonstrate that a control operated as intended.

Write each requirement so the development team can implement and test it without interpreting the law or policy themselves. As part of this you should specify the required system behavior, the conditions under which it applies, and how compliance will be verified.

Explainability

For systems that use AI or machine learning to support or make decisions, architecture may need to support explanation, traceability, and auditability. Different stakeholders may need different levels of explanation, from a plain-language account of how the system works to a record of the data, model, and logic behind a specific output.

Useful measures include:

  • Audit trail completeness.
  • Traceability of inputs, outputs, and model versions.
  • Whether users can understand and act on the explanation provided.

Interoperability

Most systems need to exchange data or coordinate work with other systems, services, or platforms. These requirements affect API design, data formats, authentication, and how tightly your solution depends on external services.

Reliability

A system can be running and accepting requests without actually working correctly. That’s the difference between availability and reliability. A payment processing system that is up 99.99% of the time but silently drops 1% of transactions has high availability and low reliability.

Reliability requirements cover fault tolerance, error handling, and data consistency. If your system must never lose a submitted order, that shapes how you design retry logic, how you handle partial failures in distributed systems, and what data integrity guarantees you commit to. A system where occasional data loss is acceptable looks very different architecturally. Key measures include:

  • Error rates and failure rates under normal and peak load.
  • Data consistency and integrity verification.
  • Graceful degradation behavior when something goes wrong.
  • Recovery completeness after a fault.

Maintainability

Every system will need to change after launch. Maintainability requirements define how easily you can make those changes, whether you are fixing defects, adapting to new needs, or extending the system over time.

Exploring and Identifying Architecture Requirements

You will rarely know every architecture requirement at the beginning. Start by identifying the requirements, constraints, and risks most likely to shape the architecture, investigating areas such as security, privacy, availability, performance, integration, regulatory obligations, data, and mandated technologies.

Use stakeholder interviews, existing documentation, system diagrams, operational data, regulations, technical research, and discussions with development and operations teams to uncover these needs. Prototypes, simulations, and testing can help you investigate uncertain areas and validate assumptions made by you or your stakeholders.

Document what you learn and revise the requirements as your understanding of the system and its operating environment develops. Validate significant requirements with specialists in areas such as security, compliance, infrastructure, data, accessibility, and operations.

How much investigation you need depends on the nature of the system, the uncertainty involved, and the consequences of making the wrong architectural decision. Spend more time identifying and investigating architecture requirements when:

  • The system has strict safety, privacy, security, accessibility, compliance, or regulatory obligations.
  • It must meet demanding availability, performance, security, or recovery expectations from its first release.
  • Integrations with existing systems are complex, tightly coupled, or poorly understood.
  • Decisions about platforms, infrastructure, data, or vendors could create costly long-term commitments.
  • Several teams depend on shared interfaces, services, data, or infrastructure.
  • Important technical risks would be difficult, unsafe, or expensive to investigate after deployment.

Your goal is to investigate enough to identify significant requirements, constraints, assumptions, and risks before committing to decisions that would be difficult or expensive to reverse.

How to Define and Document Architecture Requirements

This section introduces several ways to help you define and document architecture needs. When defining architecture requirements it is important to include things you can measure rather than broad aspirations. For example, replace “the system must be fast” with a defined response time under expected levels of demand. Replace “the system must be highly available” with a specific availability target and recovery expectation.

Architecture Diagrams

Architecture diagrams show the overall structure, components, and design of a software system. They help you illustrate elements such as applications, services, databases, data stores, interfaces, external integrations, and the relationships and communication channels between them.

You can use an architecture diagram to show how the proposed design meets requirements related to performance, availability, security, scalability, and maintainability.

Making the system’s structure visible can reveal logical dependencies, single points of failure, security boundaries, integration risks, and potential performance bottlenecks that may be difficult to identify from written requirements alone. An architecture diagram provides a shared view of the system that stakeholders can review alongside user stories and architecture decision records.

Common Elements of an Architecture Diagram

  • Components. The primary functional units of the system (e.g., API gateway, authentication service, front-end client, message broker).
  • Data Stores. The repositories where data is saved, processed, or cached, such as relational databases, NoSQL stores, object storage, or in-memory caches.
  • Relationships and Data Flows. Connectors showing how components interact with one another, including the flow of data and execution. Labels typically specify protocols, integration styles, or payload formats (e.g., REST API, gRPC, Pub/Sub, WebSockets).
  • Boundaries. Visual groupings that help illustrate system boundaries, operational zones, security perimeters, and other edges of the system.

Architecture Decision Records (ADRs)

An Architecture Decision Record is a short document that captures a single architectural decision, the context that led to it, and its consequences. Writing an ADR helps you explain why the choice was made, surface assumptions and trade-offs that might otherwise remain implicit, and revisit the decision later if conditions change (Keeling, 2022).

The format can vary, but most ADRs include the same core elements: the decision being made, the context behind it, the alternatives considered, and the consequences that follow. Keep it short.

Example ADR

ADR 004: Use a managed relational database service

Status: Accepted

Context: The system must support transactional updates, role-based access, encrypted storage, daily backups, and high availability for internal operations. The team has limited capacity to manage database infrastructure directly, and downtime during business hours would disrupt critical work.

Decision: Use a managed PostgreSQL service rather than self-hosting the database on virtual machines.

Alternatives considered:

  • Self-host PostgreSQL on cloud infrastructure
  • Use a NoSQL document database

Consequences: A managed service handles backups, patching, replication, and failover, which reduces operational load on the team. The trade-off is higher recurring platform cost and less control over low-level configuration. If performance or scaling needs change significantly, this decision may need to be revisited.

Backlog Items and Acceptance Criteria

Capturing architecture requirements as backlog items helps ensure they are prioritized, estimated, and tracked through the same process as other development work, improving visibility and giving you a full picture of the work needed to deliver your solution.

There are several ways you can represent architecture requirements in the backlog:

Epics can be used when a requirement is broad enough to involve multiple pieces of supporting work, such as improving platform security, implementing audit logging, or increasing system resilience.

User stories may capture architecture-related capabilities needed by operational, administrative, or technical users. However, not every architecture requirement needs to be forced into a user-story format; technical backlog items may be clearer when the work does not directly serve a particular user interaction.

Acceptance criteria capture architecture-related needs within the context of a user story. For example, a document upload story might include criteria such as: “Files are encrypted at rest using AES-256” and “Uploads complete within 3 seconds for files up to 25 MB.”

Validating Architecture Needs

Architecture Tradeoff Analysis Method (ATAM)

ATAM is a structured workshop method for evaluating whether an architecture can support the solution’s quality attribute goals (Kazman et al., 2000). It brings stakeholders together to walk through scenarios (e.g., performance under load, system failure, security threats) and assess how the proposed design is impacted.

The focus is on identifying risks, trade-offs, and where design changes have a large impact on attributes like performance, security, or reliability. Rather than trying to prove the architecture is “correct,” ATAM helps teams understand where it is strong, where it is vulnerable, and what trade-offs are being made.

Prototypes and Technical Spikes

A spike is a short, time-boxed investigation used to reduce architectural uncertainty. A spike can expose hidden constraints in third-party APIs or infrastructure, test quality attribute assumptions before you commit to an architecture, and validate integration approaches in your actual environment. The findings from a spike provide concrete evidence for architecture decisions.

Using Generative AI to Validate Architecture Requirements

Generative AI can help you conduct a first-pass review of architecture and other system requirements. It may flag unclear wording, missing measures or conditions, implementation assumptions, and requirements that could be difficult to verify. It may also suggest areas that deserve closer attention, such as performance, security, reliability, integration, or data handling. Emerging research supports some of these uses, but the evidence is still developing and results vary by model, prompt, and context.

Use these findings to guide further analysis, not as evidence that a requirement is valid or that an architecture concern is real. An LLM does not have reliable access to the full system context, technical constraints, stakeholder needs, or available evidence. Review each concern against the project’s actual risks, architecture, and operating environment before deciding whether the requirement needs to change.

Chapter close

Best Practices

  1. Be specific and measurable. Vague statements like "the system must be fast" or "the system should be secure" do not support architectural decisions. Define testable criteria: response time thresholds, uptime percentages, encryption standards, or compliance checkpoints.
  2. Prioritize based on business value and risk. Not all architecture requirements are equally critical. Focus on the requirements that provide the most value or pose the highest risk if unmet. A social media feed can tolerate occasional slowness; a payment processing system cannot.
  3. Validate assumptions early. Discovering that your chosen database cannot handle projected load is far cheaper during a two-day spike than after six months of development. Prototypes and proofs of concept serve the same purpose: they turn assumptions into evidence before the cost of being wrong gets high.
  4. Differentiate across components. Apply higher standards to critical components and avoid over-engineering low-impact ones.
  5. Record your reasoning. Use ADRs to capture why decisions were made, not just what was decided. The reasoning is what future team members need most when deciding whether to change course.
  6. Monitor and adapt. Use testing, monitoring, and audits throughout the lifecycle to verify that architecture requirements are being met. Requirements that seemed adequate at launch may need revision as usage patterns, data volumes, or regulatory expectations change.
  7. Make trade-offs explicit. Acknowledge architecture trade-offs and make sure they align with organizational priorities. When you tighten security at the cost of performance, or choose a simpler design knowing it limits future scalability, document the reasoning so the team can revisit it when circumstances change.

References

Bass, L., Clements, P., & Kazman, R. (2021). Software architecture in practice (4th ed.). Addison-Wesley.

Boehm, B. (2002). Get ready for agile methods with care. Computer, 35(1), 64–69.

Chen, L., Babar, M. A., & Nuseibeh, B. (2013). Characterizing architecturally significant requirements. IEEE Software, 30(2), 38–45.

Kazman, R., Klein, M., & Clements, P. (2000). ATAM: Method for architecture evaluation (CMU/SEI-2000-TR-004). Software Engineering Institute, Carnegie Mellon University.

Keeling, M. (2022). The psychology of architectural decision records. IEEE Software, 39(4), 114–117.

The architecture of a product or information system shapes how it can be built, integrated, deployed, operated, and changed over time. Decisions made early can affect performance, security, reliability, accessibility, cost, and the organization’s ability to adapt the system later.

This chapter explains how to identify and document the requirements that should influence those decisions. You will learn how to define technical constraints, quality attributes, integration and data needs, and other architecturally significant requirements. You will also consider the trade-offs these requirements create and how to record important architecture decisions.

What Are Architecture Requirements?

Architecture requirements help you identify the technical and operational characteristics that a product or information system must support. They influence important design decisions about how the solution is structured, how components interact, what technologies are used, and how the system will be deployed, operated, secured, and maintained.

Many requirements describe features, workflows, data, and business rules. Architecture requirements focus on the qualities and constraints that shape how those capabilities are delivered. They help answer questions such as:

  • How many users must the system support?
  • How quickly must it respond?
  • What level of availability is required?
  • How will it protect sensitive information?
  • Which systems must it integrate with?
  • What technologies, platforms, or standards must be used?
  • How easily must the system be changed, scaled, or maintained?

Some requirements have a particularly strong influence on the solution’s design. These are often called architecturally significant requirements (ASRs) because they drive major architectural decisions and trade-offs (Bass et al., 2021). For example, a requirement to support millions of users, comply with strict privacy regulations, or integrate with dozens of existing systems will influence the architecture much more than a minor reporting feature.

Architecture requirements rarely exist in isolation. Improving one quality attribute may make another more difficult or expensive to achieve. Increasing security can affect usability. Improving availability may increase infrastructure costs. Supporting extensive customization can increase complexity and maintenance effort. Understanding these trade-offs helps you make informed decisions about which qualities matter most for a particular product or information system.

The goal is not to document every possible technical detail upfront. Instead, you want to identify the requirements, constraints, risks, and quality attributes that are most likely to influence architecture decisions and the long-term success of the solution.

Understanding System Architecture

A system’s architecture describes its major components, how they connect, where they run, and how they work together. These decisions affect performance, security, integration, availability, data management, cost, and how easily the system can change over time.

Some architecture decisions are difficult or expensive to reverse. For example, changing the user interface of a simple web page may be relatively straightforward, but changing how data is stored, how systems exchange information, or where important processing takes place is more complicated. This is why you need to identify the requirements that could shape the architecture before major design decisions are made.

A Simple View of System Architecture

One way to picture a system is as a set of connected layers. Each layer handles a different part of the work. This is not a complete architecture model, and not every system will follow it in exactly the same way, but it gives you a useful starting point for thinking about where different requirements and design decisions apply.

User interface. This is where people interact with the system through web pages, mobile applications, dashboards, voice interfaces, or other channels. Decisions at this layer affect usability, accessibility, consistency, and how easily people can complete their work.

Application and business logic. This layer processes requests, applies business rules, and coordinates workflows. It determines how the system responds to different actions, events, and inputs.

Integration and communication. This layer allows the system to exchange data and requests with other components, services, devices, and external systems. It may include APIs, messaging services, integration platforms, and data pipelines. Decisions here affect reliability, interoperability, speed, and how dependent the system is on other systems.

Data storage and management. This includes databases, file storage, data warehouses, caches, and other ways of storing and retrieving information. Decisions about data models, storage technologies, ownership, retention, and access affect performance, consistency, scalability, privacy, and security.

Infrastructure and runtime environment. This includes the cloud services, servers, networks, operating systems, containers, and platforms the system runs on. These choices affect availability, scalability, deployment, cost, and the effort required to operate the system.

Some concerns such as security, privacy, performance, and reliability cannot be handled in only one part of the architecture. Protecting sensitive data, for example, may require controls in the interface, application logic, integrations, data storage, infrastructure, and the connections between them.

Types of Architecture Requirements

Architecture requirements are easier to identify when you think about the risks the system must manage. The categories below represent common areas where architectural decisions have significant consequences.

Accessibility

Accessibility requirements define how people with disabilities must be able to perceive, operate, understand, and interact with the system. They can affect interface components, authentication, document formats, notifications, keyboard operation, assistive-technology compatibility, and technology procurement.

Identify the organizational, contractual, or regulatory standard that applies and write testable criteria for the affected components and user journeys.

Accuracy

Some systems need calculations, measurements, or predictions to meet defined tolerances. You should define detailed relevant rules, such as number of decimal places, allowable error or tolerance, validation method, and conditions under which the target applies. Avoid a general requirement that results must simply be “accurate.”

Availability

Availability requirements define when and how consistently a system must be accessible to its users (or other systems). Common measures include availability percentage, maximum allowable downtime, mean time between failures (MTBF), and mean time to recovery (MTTR) and are usually expressed as a percentage over a defined period and should clarify whether planned maintenance is included. For example, 99.9% annual availability allows about 8.76 hours of downtime, while 99.99% allows about 52 minutes. Achieving higher availability often requires additional redundancy, automated failover, monitoring, operational support, and cost, so the target should reflect the business impact of an outage rather than an arbitrary percentage (Nygard, 2018).

Performance

Performance requirements define how quickly and efficiently a system must respond under expected operating conditions. A target of two seconds may support a relatively simple design, while a target of 200 milliseconds may require caching, database optimization, asynchronous processing, or additional infrastructure. Tighter performance targets can therefore increase cost and architectural complexity.

Performance requirements should also specify the conditions under which the target applies, such as expected transaction volume, number of concurrent users, and peak load. They may conflict with other requirements, including security, consistency, reliability, and cost, so these trade-offs should be identified early.

Common measures include:

  • Response time: How long the system takes to complete a request, often expressed as a percentile, such as 95% of requests completing within two seconds.
  • Throughput: The number of transactions or requests the system can process within a defined period.
  • Concurrent users: The number of users the system can support at the same time while still meeting performance targets.
  • Resource utilization: Acceptable limits for processor, memory, storage, network, or database usage under expected load.

Scalability

Scalability requirements matter as soon as demand can grow faster than the current design allows. Scalability requirements define how well the system maintains performance as usage grows. You may need to scale vertically (adding resources to existing servers) or horizontally (adding more servers). The choice affects cost, complexity, and deployment strategy. A system designed only for vertical scaling may hit hard limits; one designed for horizontal scaling requires different approaches to data consistency and session management. Key measures include load handling capacity, resource allocation efficiency, and response times under varying workloads.

Security

Security decisions affect nearly every layer of the architecture, from how you authenticate users to how you encrypt data and handle logging. Stronger security often creates friction with usability and performance, so those trade-offs need to be discussed openly rather than left implicit. Security requirements should be explored early because they influence architecture, workflows, data handling, user experience, and operational practices.

Security requirements should state the required controls and how they will be verified. Examples include authentication and authorization rules, encryption for data in transit and at rest, logging and monitoring, vulnerability thresholds, and required security testing.

Governance and Compliance

Governance requirements come from laws, regulations, contracts, external standards, and organizational policies. Someone has already decided what the organization must do. Your job is to identify the applicable obligation and translate it into system requirements.

Name the source, version, and specific clause or approved interpretation and identify the provision that applies, including any conditions or exceptions that affect the requirement.

Then translate the obligation into system behavior. Check the following common areas and add others when the obligation requires them:

  • Data handling. What data is in scope, where it may be stored, how it must be protected, and what can be done with it.
  • Access control. Who may access the data, what they may do with it, and what conditions govern that access.
  • Logging. What events must be recorded, what information each entry must contain, who may access the logs, and how they must be protected from alteration.
  • Retention and deletion. How long information must be kept and when it must be deleted. Minimum retention periods and maximum permitted retention periods may come from different obligations and may need to be reconciled.
  • Auditability. What evidence the system must produce to demonstrate that a control operated as intended.

Write each requirement so the development team can implement and test it without interpreting the law or policy themselves. As part of this you should specify the required system behavior, the conditions under which it applies, and how compliance will be verified.

Explainability

For systems that use AI or machine learning to support or make decisions, architecture may need to support explanation, traceability, and auditability. Different stakeholders may need different levels of explanation, from a plain-language account of how the system works to a record of the data, model, and logic behind a specific output.

Useful measures include:

  • audit trail completeness
  • traceability of inputs, outputs, and model versions
  • whether users can understand and act on the explanation provided

Sustainability

Architectural decisions affect how much infrastructure, energy, and ongoing effort your system requires. Sustainability covers environmental impact, how efficiently the system uses resources.

These concerns influence decisions about compute allocation, data retention, system complexity, and model selection. For example, keeping unused capacity running increases both cost and energy use, and storing data indefinitely creates compliance overhead that compounds over time.

Sustainability requirements help you avoid these issues by setting expectations for efficient resource use and long-term viability.

Key measures include:

  • Resource utilization (CPU, memory, and storage efficiency)
  • Cost per transaction or request
  • Data retention and storage growth over time
  • Energy use or infrastructure footprint where measurable

Interoperability

Most systems need to exchange data or coordinate work with other systems, services, or platforms. These requirements affect API design, data formats, authentication, and how tightly your solution depends on external services.

Reliability

A system can be running and accepting requests without actually working correctly. That's the difference between availability and reliability. A payment processing system that is up 99.99% of the time but silently drops 1% of transactions has high availability and low reliability.

Reliability requirements cover fault tolerance, error handling, and data consistency. If your system must never lose a submitted order, that shapes how you design retry logic, how you handle partial failures in distributed systems, and what data integrity guarantees you commit to. A system where occasional data loss is acceptable looks very different architecturally. Key measures include:

  • Error rates and failure rates under normal and peak load
  • Data consistency and integrity verification
  • Graceful degradation behavior when something goes wrong
  • Recovery completeness after a fault

Maintainability

Every system will need to change after launch. Maintainability requirements define how easily you can make those changes, whether you are fixing defects, adapting to new needs, or extending the system over time.

When maintainability is poor, technical debt can accumulate quickly, and each change becomes slower and riskier than the last.

Exploring and Identifying Architecture Requirements

identify architecturally significant requirements, constraints, and risks as early as possible because they shape decisions that may be difficult or expensive to change later. Security, privacy, accessibility, availability, performance, integration, regulatory obligations, and mandated technologies can influence the overall architecture before development begins.

Express the most important quality attributes as measurable requirements rather than broad aspirations. Continue to refine them as you investigate the technical environment, design the system, build prototypes, test components, and observe how the system behaves under realistic conditions. Replace assumptions with evidence and revise requirements when stakeholder needs, operating conditions, or technical constraints become clearer.

Identifying these requirements early does not mean fully designing or implementing the entire architecture upfront. Build and validate enough architectural capability to support the work ahead. This architectural runway might include shared infrastructure, integration mechanisms, security controls, data services, deployment pipelines, or other technical foundations needed for upcoming increments. Extend the runway as priorities and risks change rather than building speculative capabilities that may never be needed.

You typically need more architectural work upfront when:

  • The system has strict safety, compliance, privacy, or regulatory obligations.
  • Integration with existing systems is complex or tightly coupled.
  • Platform, infrastructure, or data decisions create long-term commitments.
  • The system must meet demanding availability, performance, or security thresholds from its initial release.
  • Several teams will develop components that depend on shared interfaces, services, or infrastructure.
  • Architectural risks cannot be tested safely or economically after deployment.

You can limit the amount of upfront architectural work when:

  • The domain and technical environment are familiar.
  • The system is relatively self-contained and has few integration dependencies.
  • You can deploy incrementally and learn from actual use.
  • You can test uncertain decisions through prototypes or small experiments.
  • Architectural decisions can be reversed or revised without prohibitive cost.

The following practices help you surface architecture needs before they become costly surprises.

Architecture workshops. Bring together business stakeholders, developers, and operations staff to surface concerns such as performance, security, or compliance. Define measurable quality scenarios rather than vague goals. Instead of stating that the system must be “fast,” specify what that means. For example, the system might be required to process 1,000 transactions per second during peak usage (Bass et al., 2021).

Quality attribute scenarios. Capture architecture requirements in a structured way that clearly describes a situation and its expected outcome. For example: "Under normal load, when a user submits a search query, the system returns results within two seconds for 95% of requests."

System metrics analysis. Review current performance, scalability patterns, and security incidents to uncover hidden needs.

Deployment modeling. Map system architecture to identify potential points of failure that may affect performance, scalability, or security. Deployment diagrams (described below) are a practical tool for this.

How to Define and Document Architecture Requirements

This section introduces three practical ways to define and document architecture needs: deployment diagrams, architecture decision records, and backlog items with acceptance criteria.

Deployment Diagrams

Deployment diagrams illustrate the physical and virtual components that make up the system, showing where software artifacts run and how infrastructure is organized. They help you identify architecture requirements by making the system's structure visible, which reveals dependencies, potential failure points, and performance bottlenecks that might not be apparent from requirements documents alone.

Key Elements of a Deployment Diagram

Nodes represent physical or virtual hardware components, such as servers, virtual machines, containers, mobile devices, or cloud services. Each node represents a runtime environment where software executes.

Artifacts are the software components deployed on nodes: executable files, libraries, databases, configuration files, or container images. They show what is running where.

Communication paths are network connections between nodes, shown as lines connecting them. Labels typically indicate the protocol or interface used (e.g., HTTPS, API).

Components are optional elements showing the logical software modules within artifacts, useful when you need to show how responsibilities are distributed inside a deployment unit.

Using Deployment Diagrams to Surface Architecture Requirements

Walking through a deployment diagram with stakeholders can surface architecture requirements that might otherwise remain hidden. For example:

  • A single database node with no replica poses an availability risk, which may necessitate automated failover.
  • A communication path between your application and an external payment gateway raises questions about latency, retry logic, and what happens when the gateway is unavailable.
  • Deploying to multiple cloud regions to comply with data residency regulations adds complexity for data synchronization and consistency.

Architecture Decision Records (ADRs)

An Architecture Decision Record is a short document that captures a single architectural decision, the context that led to it, and its consequences. Writing an ADR helps you explain why the choice was made, surface assumptions and trade-offs that might otherwise remain implicit, and revisit the decision later if conditions change (Keeling, 2022).

The format can vary, but most ADRs include the same core elements: the decision being made, the context behind it, the alternatives considered, and the consequences that follow. Keep it short.

Example ADR

ADR 004: Use a managed relational database service

Status: Accepted

Context: The system must support transactional updates, role-based access, encrypted storage, daily backups, and high availability for internal operations. The team has limited capacity to manage database infrastructure directly, and downtime during business hours would disrupt critical work.

Decision: Use a managed PostgreSQL service rather than self-hosting the database on virtual machines.

Alternatives considered:

  • Self-host PostgreSQL on cloud infrastructure
  • Use a NoSQL document database

Consequences: A managed service handles backups, patching, replication, and failover, which reduces operational load on the team. The trade-off is higher recurring platform cost and less control over low-level configuration. If performance or scaling needs change significantly, this decision may need to be revisited.

Backlog Items and Acceptance Criteria

Capturing architecture requirements as backlog items helps ensure they are prioritized, estimated, and tracked through the same process as other development work, improving visibility and giving you a full picture of the work needed to deliver your solution.

There are several ways you can represent architecture requirements in the backlog:

Epics can be used when a requirement is broad enough to involve multiple pieces of supporting work, such as improving platform security, implementing audit logging, or increasing system resilience.

User stories may capture architecture-related capabilities needed by operational, administrative, or technical users. However, not every architecture requirement needs to be forced into a user-story format; technical backlog items may be clearer when the work does not directly serve a particular user interaction.

Acceptance criteria capture architecture-related needs within the context of a user story. For example, a document upload story might include criteria such as: "Files are encrypted at rest using AES-256" and "Uploads complete within 3 seconds for files up to 25 MB."

Validating Architecture Needs

Architecture Tradeoff Analysis Method (ATAM)

ATAM is a structured workshop method for evaluating whether an architecture can support the solution’s quality attribute goals (Kazman et al., 2000). It brings stakeholders together to walk through scenarios (e.g., performance under load, system failure, security threats) and assess how the proposed design is impacted.

The focus is on identifying risks, trade-offs, and where design changes have a large impact on attributes like performance, security, or reliability. Rather than trying to prove the architecture is “correct,” ATAM helps teams understand where it is strong, where it is vulnerable, and what trade-offs are being made.

Prototypes and Technical Spikes

A spike is a short, time-boxed investigation used to reduce architectural uncertainty. A spike can expose hidden constraints in third-party APIs or infrastructure, test quality attribute assumptions before you commit to an architecture, and validate integration approaches in your actual environment. The findings from a spike provide concrete evidence for architecture decisions.

Using Generative AI to Validate Architecture Requirements

Generative AI can help you conduct a first-pass review of architecture and other system requirements. It may flag unclear wording, missing measures or conditions, implementation assumptions, and requirements that could be difficult to verify. It may also suggest areas that deserve closer attention, such as performance, security, reliability, integration, or data handling. Emerging research supports some of these uses, but the evidence is still developing and results vary by model, prompt, and context.

Use these findings to guide further analysis, not as evidence that a requirement is valid or that an architecture concern is real. An LLM does not have reliable access to the full system context, technical constraints, stakeholder needs, or available evidence. Review each concern against the project’s actual risks, architecture, and operating environment before deciding whether the requirement needs to change.

References

Bass, L., Clements, P., & Kazman, R. (2021). Software architecture in practice (4th ed.). Addison-Wesley.

Boehm, B. (2002). Get ready for agile methods with care. Computer.

Chen, L., Babar, M. A., & Nuseibeh, B. (2013). Characterizing architecturally significant requirements. IEEE Software.

Kazman, R., Klein, M., & Clements, P. (2000). ATAM: Method for architecture evaluation. Software Engineering Institute, Carnegie Mellon University.

Keeling, M. (2022). The psychology of architectural decision records. IEEE Software.

Nygard, M. (2018). Release it!: Design and deploy production-ready software (2nd ed.). Pragmatic Bookshelf.