TOGAF Architecture Requirements Specification Explained
If Requirements Management is the process that keeps requirements alive throughout the ADM, the Architecture Requirements Specification is the formal document that captures them in a structure architects can design to and programme managers can verify against.
The Architecture Requirements Specification is one of the most important deliverables in a TOGAF-based architecture project. It translates stakeholder needs, which are often expressed in business language, into precise, measurable criteria that the architecture must satisfy. Without it, both architects and delivery teams are working to informal understandings that inevitably diverge.
This post covers what the specification contains, how it is built, and how it is used across the ADM lifecycle.
What Is the Architecture Requirements Specification?
The Architecture Requirements Specification is a formal document that defines the quantitative aspects of an architecture — the specific measures and criteria that represent success for each domain of the architecture.
It is not a list of user stories or functional requirements for individual applications. Those are the domain of business analysts and product owners. The Architecture Requirements Specification operates at a higher level, defining the architectural quality attributes and constraints the entire solution must comply with.
It covers requirements across all four architectural domains:
- Business Architecture requirements
- Data Architecture requirements
- Application Architecture requirements
- Technology Architecture requirements
How the Architecture Requirements Specification Is Created
The specification is not produced in a single pass. It is built incrementally through the ADM phases, with each phase contributing requirements relevant to its domain.
Input from Phase A
Phase A's stakeholder engagement produces the initial set of business requirements and the high-level architecture requirements that flow directly from the Architecture Vision. These form the first entries in the specification.
Input from Phase B
Phase B adds detailed business architecture requirements: the business capabilities that must be supported, the business processes that must be enabled, the organizational constraints that apply, and the performance requirements for key business services.
Input from Phase C
Phase C adds application and data architecture requirements: which business services must be application-supported, what integration capabilities are required, what data quality standards apply, what data governance requirements are mandated, and what data retention and privacy controls must be implemented.
Input from Phase D
Phase D adds technology architecture requirements: platform performance specifications, availability and resilience requirements, security standards, geographic constraints on infrastructure, and technology standards compliance.
The Specification Is Versioned
Because the Architecture Requirements Specification accumulates input from multiple phases, it is a versioned document. The version produced after Phase A is much shorter than the version produced after Phase D. Each version is baselined, and changes are managed through Requirements Management.
The Structure of an Architecture Requirements Specification
A well-formed Architecture Requirements Specification typically contains the following sections.
1. Success Measures
For each architectural domain and major business outcome, the specification defines measurable indicators of success. These are the criteria against which the delivered architecture will be assessed.
Examples:
- Business: Customer onboarding time reduced from 5 business days to under 10 minutes for 80% of standard applications
- Application: All customer-facing applications integrate with the enterprise IAM platform by the go-live date
- Data: A single Customer Master Index exists as the authoritative source within 12 months. No more than two data quality defects per 1,000 records
- Technology: All production systems achieve 99.9% availability. Recovery Time Objective of 4 hours for Tier 1 systems
2. Architecture Requirements
The formal list of requirements each domain imposes on the architecture, expressed precisely enough to be testable. Each requirement is documented with:
- A unique identifier
- The requirement statement
- The source (stakeholder, principle, regulation)
- The priority (mandatory, high, medium, low)
- The relevant ADM phase and domain
- Acceptance criteria: how will it be verified that this requirement has been met?
3. Business Service Contracts
For each business service defined in Phase B, the specification captures the agreed service quality parameters:
- Response time (for online services)
- Throughput (transactions per second or per day)
- Availability (percentage uptime during business hours vs 24/7)
- Data quality thresholds
4. Constraints
The specification explicitly documents all hard constraints — the absolute boundaries the architecture cannot cross. This includes:
- Regulatory requirements (data sovereignty, privacy laws, sector-specific compliance)
- Budget ceilings
- Fixed delivery dates imposed by business or regulatory events
- Technology constraints (must integrate with specified legacy systems)
- Organizational constraints (must operate within current operating model)
5. Gap Assessment
The specification includes a summary of the gaps between current capabilities and the requirements identified above. This connects directly to the Gap Analyses performed in Phases B, C, and D and ensures the requirements context for each gap is clear.
How the Specification Is Used
As a Design Target for Architects
Throughout Phases B, C, and D, the Architecture Requirements Specification acts as the design target. Every architectural decision should be traceable to a requirement in the specification. If an architect makes a design choice with no linkage to any requirement, that is a signal that either the choice is unnecessary or the specification has a gap.
As a Compliance Baseline for Phase G
During Phase G, Architecture Compliance Reviews compare the implemented system against the Architecture Requirements Specification. Each requirement should be assessed as either satisfied, partially satisfied, or not satisfied by the current state of the implementation. Non-satisfied requirements trigger remediation actions.
As a Performance Measurement Baseline for Phase H
In Phase H, the success measures defined in the specification serve as the long-term performance targets against which the enterprise architecture is measured over time. Monitoring these measures tells the architecture team whether the delivered architecture is actually producing the business outcomes it was designed to achieve.
Make Requirements Testable
The most common quality problem in Architecture Requirements Specifications is vagueness. Requirements like 'the system must be user-friendly' or 'performance must be acceptable' cannot be tested. Every requirement must have a measurable acceptance criterion. If you cannot describe a test that would definitively pass or fail the requirement, rewrite it until you can.
Common Requirement Types in Enterprise Architecture
To help structure requirements gathering, here are the main categories of requirements that typically appear in an Architecture Requirements Specification.
Functional Requirements
What the architecture must do. These describe the business capabilities and services the architecture must enable. Most functional requirements originate from Phase B business architecture work.
Quality Attribute Requirements (Non-Functional)
These describe how well the architecture must perform its functions. They include:
- Performance: Response times, throughput, processing capacity
- Availability: Uptime targets and maintenance windows
- Scalability: The ability to grow capacity in response to demand
- Security: Authentication, authorisation, encryption, and audit requirements
- Maintainability: How easily the architecture can be updated, patched, and supported
- Interoperability: Standards the architecture must comply with to integrate with internal and external systems
Transition Requirements
Requirements specific to the migration from the current to the target architecture, rather than properties of the target state itself. For example: "There must be zero data loss during the migration from the legacy CRM to the new platform" is a transition requirement. Once migration is complete, this requirement is retired.
Regulatory and Compliance Requirements
Requirements imposed by external regulators, legal frameworks, or contractual obligations. These are typically absolute constraints. Examples include GDPR Article 5 data minimisation principles, PCI-DSS requirements for card data handling, or sector-specific requirements like Solvency II for insurance organizations.
Practical Example: Logistics Company Digital Transformation
A national logistics company uses the Architecture Requirements Specification as follows:
- Business requirement (from Phase B): REQ-B-001: The routing optimization service must process all planned routes for the following day within the daily logistics planning window of 18:00–22:00
- Acceptance criterion: The routing engine processes a full day's route schedule (up to 15,000 individual routes) in under 3 hours with 99.95% accuracy
- Data requirement (from Phase C): REQ-D-015: All vehicle telematics data must be available in the central operations platform within 30 seconds of generation at the vehicle
- Technology constraint: CON-T-004: All data processing must occur within AWS EU-West-1 and EU-West-2 regions to comply with UK data residency requirements
- Phase G compliance: Before sign-off on the new routing system, a compliance review checks that REQ-B-001 has been achieved by running a simulated full day's load and measuring processing time
Summary
The Architecture Requirements Specification is the formal, measurable description of what the architecture must achieve. It:
- Accumulates requirements from every ADM phase, covering all four architectural domains
- Includes success measures, formal requirements, service contracts, and hard constraints
- Acts as the design target during Phases B–D
- Acts as the compliance baseline during Phase G
- Acts as the long-term performance benchmark during Phase H
In the final post of Module 2, we cover ADM Iteration and Scoping — how the ADM cycle is applied at different scales and how architects scope and iterate the method to fit both large enterprise transformations and smaller, targeted capability projects.
For prerequisite reading on what feeds into the specification, see Requirements Management and Architecture Principles and Governance.