Architecture Requirements Specification: [Architecture engagement name]
The Architecture Requirements Specification sets out the measurable
criteria that implementation must meet for the target architecture to be
realised: success measures, architecture requirements per domain,
interoperability requirements, business and application service
contracts, implementation guidelines and specifications, standards,
constraints and assumptions. It is a deliverable of The TOGAF Standard,
10th Edition (2025 release with Technical Corrigendum 1), developed alongside the Architecture
Definition Document in Phases B to D of the Architecture Development
Method (ADM), refined in Phases E and F, and maintained through
Requirements Management. Replace every [bracketed] value and every
row marked Example.
Document control
| Field | Value |
|---|
| Document ID | [ARS-ENG-001] |
| Engagement | [Architecture engagement name] |
| Accompanies | [ADD-ENG-001], Architecture Vision [AV-ENG-001] |
| Statement of Architecture Work | [SAW-YYYY-NN] |
| ADM phases | Phases B to D (developed), E and F (refined), Requirements Management (maintained) |
| Version | [0.1] |
| Status | [Draft / In review / Baselined / Superseded] |
| Requirements baseline | [ARS baseline B1, date] |
| Owner | [@lead-architect] |
| Requirements manager | [@requirements-owner] |
| Approvers / reviewers | [Architecture Board, sponsor, security architect, domain architects] |
| Classification | [Internal / Confidential] |
| Repository location | [Architecture Repository path or ID] |
| Last updated | YYYY-MM-DD |
Approvals
| Role | Name | Decision | Conditions | Date |
|---|
| Lead architect | [@lead-architect] | [Approved] | [Conditions] | YYYY-MM-DD |
| Security architect | [@security-architect] | [Approved / Approved with conditions] | [Conditions] | YYYY-MM-DD |
| Data protection officer | [@dpo] | [Decision] | [Conditions] | YYYY-MM-DD |
| Business owner | [@business-owner] | [Decision] | [Conditions] | YYYY-MM-DD |
| Architecture Board chair | [@chair] | [Baselined] | [Board outcome record] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@lead-architect] | Success measures and first requirements from the outline pass |
| 0.6 | YYYY-MM-DD | [@data-architect] | Example: Service contracts, standards and traceability added after the detailed pass |
| 1.0 | YYYY-MM-DD | [@lead-architect] | Example: Baseline B1 approved at gate 2 with the Architecture Definition Document |
| 1.1 | YYYY-MM-DD | [@requirements-owner] | Example: ARS-INT-04 added under change request ACR-2027-03 (interim change data capture) |
Contents
1. Introduction
1.1 Purpose and audience
This specification states what delivery teams, suppliers and platform
owners must achieve for their work to count as realising the target
architecture for [engagement]. It is written for solution architects and
designers who turn it into designs, for testers who verify it, for the
Architecture Board that checks compliance, and for procurement teams who
copy relevant requirements into supplier contracts.
1.2 Scope
Example: the target architecture for retail motor and home claims and
the customer domain, at the depth agreed in the Statement of Architecture
Work (architecture/statement-of-architecture-work) section 3: logical
level for all domains, physical level for integration and hosting.
1.3 Conventions
| Item | Convention |
|---|
| Requirement IDs | ARS-BUS-nn (business), ARS-DAT-nn (data), ARS-APP-nn (application), ARS-TEC-nn (technology), ARS-SEC-nn (security and privacy), ARS-INT-nn (interoperability) |
| Other IDs | SM-nn success measures, BSC-nn business service contracts, ASC-nn application service contracts, IG-nn guidelines, IS-nn specifications, STD-nn standards |
| Priority | Must (target not realised without it), Should (expected; deviation needs a dispensation), Could (desirable; may be deferred by the delivery team) |
| Status | Proposed, Agreed, Baselined, Implemented, Verified, Deferred, Withdrawn (section 15) |
| Verification methods | Inspection, Analysis, Demonstration, Test (section 14) |
| Rationale | One or more of BG-nn, DRV-nn, CNS-nn, principle IDs (BP, DP, AP, TP, SP), or a stakeholder concern CON-nn |
The same six prefixes are used in the Architecture Definition Document
(architecture/architecture-definition-document) section 9.
1.4 What makes a good architecture requirement
- It states an outcome or property, not a product or a design choice.
- It is measurable: a fit criterion with a number, a threshold or a
yes-or-no test.
- It traces to at least one goal, driver, constraint, principle or
concern; a requirement with no rationale is a candidate for removal.
- It applies to a named scope (all target applications, the customer
data hub, every partner interface) so a delivery team knows whether it
is bound by it.
- It is independent of the delivery method and stays valid if the
supplier changes.
- It is written once. Other documents reference the ID rather than
copying the text.
2. Success measures
| SM ID | Measure | KPI (vision 7.2) | Target at TA-1 | Target at TA-2 | Target at completion | Measurement method | Owner |
|---|
| SM-01 (Example) | Share of simple claims decided within 48 hours | KPI-01 | Not measured | 50% | 70% | Claims platform decision events, monthly | [@head-of-claims] |
| SM-02 (Example) | Customer records with a single golden ID | KPI-02 | 60% | 80% | 98% | Hub data quality dashboard | [@data-owner] |
| SM-03 (Example) | Operating cost per claim against the YYYY baseline | KPI-03 | No change | 12% lower | 20% lower | Finance cost model, quarterly | [@finance] |
| SM-04 (Example) | Critical third-party services with a tested exit plan | KPI-04 | 2 of 6 | 4 of 6 | 6 of 6 | Third-party register | [@risk-owner] |
| SM-05 (Example) | Point-to-point file transfers in the claims domain | None (architecture health) | 14 | 5 | 0 | Integration inventory | [@integration-lead] |
| [SM-nn] | [Measure] | [KPI-nn] | [Value] | [Value] | [Value] | [Method] | [@owner] |
Targets at each plateau come from the Architecture Roadmap
(architecture/architecture-roadmap-transition) section 5.2. If the
roadmap changes, update this table in the same change.
3. Architecture requirements by domain
3.1 Business architecture requirements
| Req ID | Requirement | Applies to | Rationale | Fit criterion | Verification | Priority |
|---|
| ARS-BUS-01 (Example) | Simple claims must be decidable without human touch when triage rules pass | Claims decision process | BG-01, GAP-B-01 | In a sample of 500 simple claims, every claim that passes all rules is decided with no manual step | Test with sample claims | Must |
| ARS-BUS-02 (Example) | A handler can override any automated decision, and every override records a reason code | Claims decision process | BG-01, CON-01, SH-06 concern | 100% of overrides in the test set carry a reason code; overrides reported monthly | Demonstration and inspection of reports | Must |
| ARS-BUS-03 (Example) | Approval limits follow the delegated authority matrix, not system defaults | Claims settlement | GAP-B-04 | Each limit in the matrix is enforced in a test case at, below and above the limit | Test | Must |
| ARS-BUS-04 (Example) | Partners can submit claims with structured loss data through a single channel | Partner claim intake | GAP-B-03, GAP-D-02 | Three pilot partners submit claims end to end without e-mail attachments | Demonstration | Should |
| [ARS-BUS-nn] | [Requirement] | [Scope] | [Rationale] | [Fit criterion] | [Method] | [Must / Should / Could] |
3.2 Data architecture requirements
| Req ID | Requirement | Applies to | Rationale | Fit criterion | Verification | Priority |
|---|
| ARS-DAT-01 (Example) | Each customer has exactly one golden identifier used by all target applications | All target applications | BG-02, DP-01, GAP-D-01 | Zero target applications hold a customer key not mapped to the golden ID; duplicate rate below 2% in the monthly report | Analysis of data quality report | Must |
| ARS-DAT-02 (Example) | Customer and claim data stored and processed only in EU regions | All components holding customer or claim data | CNS-02, DP-02 | Configuration of every data store and processing service shows an EU region; no replication outside the EU | Inspection of configuration | Must |
| ARS-DAT-03 (Example) | Matching of customer records reaches at least 95% precision before a source is mastered by the hub | Customer data hub | BG-02, architecture risk ARK-01 | Precision measured on a reviewed sample of 2,000 matched pairs per source | Analysis | Must |
| ARS-DAT-04 (Example) | Consent and its history are recorded for each customer and purpose | Customer data hub | GAP-D-03, DP-03 | Every consent change in the test set has purpose, timestamp, channel and actor | Test | Must |
| ARS-DAT-05 (Example) | Every data entity in the target has a named data owner and a retention period | Data catalogue | DP-01, DP-02 | Catalogue report shows zero entities without owner or retention | Inspection | Should |
| [ARS-DAT-nn] | [Requirement] | [Scope] | [Rationale] | [Fit criterion] | [Method] | [Priority] |
3.3 Application architecture requirements
| Req ID | Requirement | Applies to | Rationale | Fit criterion | Verification | Priority |
|---|
| ARS-APP-01 (Example) | Target applications expose functions only through published APIs | All target applications | AP-01 | Every integration in the inventory uses an interface listed in the API catalogue | Architecture compliance review | Must |
| ARS-APP-02 (Example) | A handler completes a simple claim in one workspace | Handler workspace | BG-01, GAP-A-03, CON-04 | In usability testing, a simple claim is completed without opening another application | Demonstration | Should |
| ARS-APP-03 (Example) | Retired applications leave a read-only, searchable archive for the retention period | Legacy CRM, old claims system | GAP-A-04, GAP-D-04 | Archive returns records for 20 sample customers within 10 seconds each | Test | Must |
| ARS-APP-04 (Example) | Each target application can be released independently of the others | Claims platform, portal, workspace, hub | AP-02 | A release of one component in pre-production needs no coordinated release of another | Demonstration | Should |
| [ARS-APP-nn] | [Requirement] | [Scope] | [Rationale] | [Fit criterion] | [Method] | [Priority] |
3.4 Technology architecture requirements
| Req ID | Requirement | Applies to | Rationale | Fit criterion | Verification | Priority |
|---|
| ARS-TEC-01 (Example) | Claims platform recovers within 4 hours with at most 15 minutes of data loss | Claims platform | BG-04 | Recovery test restores service in 4 hours or less with data loss of 15 minutes or less | Test (recovery exercise) | Must |
| ARS-TEC-02 (Example) | Target components are deployed on the approved cloud platform through the platform pipeline | All new components | TP-01, TP-02, GAP-T-02 | Deployment records show the platform pipeline for every production release | Inspection | Must |
| ARS-TEC-03 (Example) | Every target service sends logs, metrics and traces to central observability | All target services | TP-03, GAP-T-04 | Each service appears in the observability catalogue with all three signal types | Inspection | Should |
| ARS-TEC-04 (Example) | Connectivity between cloud and data centre has no single point of failure | Private connectivity | GAP-T-03, BG-04 | Failover test drops one link with no loss of claims transactions | Test | Must |
| [ARS-TEC-nn] | [Requirement] | [Scope] | [Rationale] | [Fit criterion] | [Method] | [Priority] |
3.5 Security and privacy requirements
| Req ID | Requirement | Applies to | Rationale | Fit criterion | Verification | Priority |
|---|
| ARS-SEC-01 (Example) | Staff and partner users authenticate through the enterprise identity provider with multi-factor authentication | All user-facing components | SP-01, SP-02 | No local user stores in production; MFA enforced in the identity provider policy | Inspection and test | Must |
| ARS-SEC-02 (Example) | Personal data is encrypted in transit and at rest with keys held in the platform key service | All components holding personal data | SP-01, DP-02 | Configuration review shows encryption and platform-managed keys for every store and link | Inspection | Must |
| ARS-SEC-03 (Example) | Each critical third-party service has a documented exit plan and a tested recovery | Claims package, hub service | BG-04, DRV-02 | Exit plan approved and recovery tested within the last 12 months | Inspection of evidence | Must |
| ARS-SEC-04 (Example) | Access to customer data is logged and the logs are retained for [n] months | Hub, claims platform, workspace | CON-02 | Sample of 50 access events retrievable with user, purpose and time | Test | Should |
| [ARS-SEC-nn] | [Requirement] | [Scope] | [Rationale] | [Fit criterion] | [Method] | [Priority] |
Detail quality attribute scenarios (stimulus, environment, response,
measure) with the quality attributes template
(requirements/quality-attributes) when a requirement needs more than
one line to be testable.
4. Interoperability requirements
| Req ID | Level | Requirement | Rationale | Fit criterion | Verification | Priority |
|---|
| ARS-INT-01 (Example) | Information | All events carry the golden customer ID and a schema version | BG-02 | Contract tests reject events without either field | Test (contract) | Should |
| ARS-INT-02 (Example) | Technical | No new point-to-point file transfer is introduced in the claims domain | AP-01, SM-05 | Integration inventory shows no new file interface after TA-1 | Inspection | Must |
| ARS-INT-03 (Example) | Technical | Published APIs are versioned and a breaking change is announced at least [6] months ahead | AP-02 | Each API in the catalogue has a version and a deprecation date policy | Inspection | Must |
| ARS-INT-04 (Example) | Information | During the interim period, changes captured from policy system A are published as the same customer events as the target API would produce | ACR-2027-03 | Consumers pass the same contract tests against both sources | Test (contract) | Must |
| ARS-INT-05 (Example) | Business | Each partner interface is covered by a signed partner agreement that names service levels and data use | GAP-B-03 | Agreement on file for every live partner | Inspection | Must |
| [ARS-INT-nn] | [Business / Information / Technical] | [Requirement] | [Rationale] | [Fit criterion] | [Method] | [Priority] |
4.1 Interface inventory
| Interface | Provider | Consumers | Style | Specification | Requirements |
|---|
| Example: Customer API | Customer data hub | Claims platform, portal, workspace | REST | IS-01 | ARS-APP-01, ARS-INT-03 |
| Example: Customer changed event | Customer data hub | Claims platform, distribution segment | Events | IS-02 | ARS-INT-01 |
| Example: Claim decided event | Claims platform | Finance, portal | Events | IS-03 | ARS-INT-01 |
| Example: Partner claim submission | API gateway | Repair partners | REST | IS-04 | ARS-BUS-04, ARS-INT-05 |
| [Interface] | [Provider] | [Consumers] | [Style] | [IS-nn] | [ARS IDs] |
5. Business service contracts
| BSC ID | Business service | Provider | Consumers | Outcome delivered | Service levels | Hours | Measure and owner |
|---|
| BSC-01 (Example) | Simple claim decision | Claims operations | Policyholders, partners | Decision and payment instruction on a simple claim | 70% within 48 hours; 95% within 5 days | 24x7 intake; decisions on business days | SM-01, [@head-of-claims] |
| BSC-02 (Example) | Customer identity resolution | Customer operations | All business units | One trusted customer record and contact details | New customer resolved within 1 hour; merge disputes resolved within 5 days | Business hours | SM-02, [@data-owner] |
| BSC-03 (Example) | Partner claim intake | Partner management | Repair partners | Acknowledged submission with claim reference | Acknowledgement within 15 minutes | 24x7 | [@partner-manager] |
| [BSC-nn] | [Service] | [Provider] | [Consumers] | [Outcome] | [Levels] | [Hours] | [Measure, @owner] |
6. Application service contracts
| ASC ID | Application service | Provider | Interface | Availability | Latency (p95) | Throughput | RTO / RPO | Support hours | Supports |
|---|
| ASC-01 (Example) | Customer lookup | Customer data hub | IS-01 | 99.9% monthly | 300 ms | 50 requests per second peak | 2 h / 5 min | 24x7 | BSC-01, BSC-02 |
| ASC-02 (Example) | Claim triage and decision | Claims platform | Internal | 99.9% monthly | 5 s per decision | 2,000 claims per hour peak | 4 h / 15 min | 24x7 | BSC-01 |
| ASC-03 (Example) | Customer change events | Customer data hub | IS-02 | 99.5% monthly | Published within 60 s of change | 20 events per second | 4 h / 15 min | Business hours, on call out of hours | BSC-02 |
| ASC-04 (Example) | Partner submission | API gateway | IS-04 | 99.5% monthly | 2 s | 10 requests per second | 8 h / 1 h | Business hours | BSC-03 |
| [ASC-nn] | [Service] | [Provider] | [IS-nn] | [%] | [Time] | [Rate] | [RTO / RPO] | [Hours] | [BSC-nn] |
Example check: 140,000 claims a year over roughly 2,000 business hours
is about 70 claims per hour on average. A winter storm can bring about 15
times that rate, roughly 1,050 per hour, so the 2,000 per hour in ASC-02
leaves close to double the expected peak. Keep the margin explicit so the
capacity tests in section 14 have a target, and revisit it if ASM-05 fails.
7. Implementation guidelines
| IG ID | Guideline | Reason | Applies to |
|---|
| IG-01 (Example) | Migrate customers source by source, starting with the cleanest, and master a source only after ARS-DAT-03 is met | Limits the blast radius of matching errors | WP-02 |
| IG-02 (Example) | Configure the claims package before customising it; record each customisation as an ADR | Keeps upgrade cost low (BP-02) | WP-03 |
| IG-03 (Example) | Run old and new claims decisions in parallel for four weeks before switching | Builds handler trust in automated decisions | WP-03, WP-06 |
| IG-04 (Example) | Retire each file transfer in the same release that introduces its API or event replacement | Avoids dual running costs and drift | WP-01 to WP-04 |
| IG-05 (Example) | Use the platform golden path for new services (architecture/platform-golden-path) | Meets ARS-TEC-02 and ARS-TEC-03 by default | All new services |
| [IG-nn] | [Guideline] | [Reason] | [Scope] |
8. Implementation specifications
| IS ID | Specification | Type | Owner | Version | Location | Linked requirements |
|---|
| IS-01 (Example) | Customer API | REST API specification (architecture/rest-api-specification) | [@data-architect] | [x.y] | [Path] | ARS-APP-01, ARS-INT-03 |
| IS-02 (Example) | Customer changed event | Event API specification (architecture/event-api-specification) | [@data-architect] | [x.y] | [Path] | ARS-INT-01, ARS-INT-04 |
| IS-03 (Example) | Claim decided event | Event API specification | [@application-architect] | [x.y] | [Path] | ARS-INT-01 |
| IS-04 (Example) | Partner claim submission | REST API specification | [@application-architect] | [x.y] | [Path] | ARS-BUS-04 |
| IS-05 (Example) | Customer canonical data model | Logical data model (architecture/data-dictionary) | [@data-architect] | [x.y] | [Path] | ARS-DAT-01, ARS-DAT-05 |
| IS-06 (Example) | Cloud hosting baseline for the claims domain | Configuration baseline (architecture/landing-zone-design) | [@technology-architect] | [x.y] | [Path] | ARS-DAT-02, ARS-TEC-02, ARS-SEC-02 |
| [IS-nn] | [Specification] | [Type] | [@owner] | [x.y] | [Path] | [ARS IDs] |
For interfaces with external parties, use an interface control document
(architecture/interface-control-document).
9. Standards
| STD ID | Standard | Version | Status | Applies to | Source |
|---|
| STD-01 (Example) | Enterprise API design guidelines (architecture/api-design-guidelines) | [x.y] | Mandatory | All published APIs | Enterprise standards base |
| STD-02 (Example) | OpenAPI Specification for REST interface descriptions | [Version set in STD-01] | Mandatory | IS-01, IS-04 | Enterprise standards base |
| STD-03 (Example) | AsyncAPI for event interface descriptions | 3.1.0 | Mandatory | IS-02, IS-03 | Enterprise standards base |
| STD-04 (Example) | CloudEvents envelope for events | 1.0.2 | Mandatory | All events | Enterprise standards base |
| STD-05 (Example) | TLS for all network traffic | 1.2 minimum, 1.3 preferred | Mandatory | All links | Security standard |
| STD-06 (Example) | ISO 8601 dates and times in UTC on interfaces | Current | Mandatory | All interfaces | Enterprise standards base |
| STD-07 (Example) | API deprecation policy (architecture/api-deprecation-policy) | [x.y] | Mandatory | All published APIs | Enterprise standards base |
| [STD-nn] | [Standard] | [Version] | [Mandatory / Recommended / Emerging / Retiring] | [Scope] | [Source] |
Check external standard versions against their publishers before each
baseline; the versions above are examples.
10. Constraints
| ID | Constraint | Source | Resulting requirements | Review date |
|---|
| CNS-01 (Example) | Capital for the change is capped at USD 2.5 million | Vision 3.3 | IG-02 (configure before customise) | Each funding gate |
| CNS-02 (Example) | Customer personal data must remain in the EU | Vision 3.3 | ARS-DAT-02, IS-06 | Annually |
| CNS-03 (Example) | Policy administration contract renews on YYYY-MM-DD | Vision 3.3 | ARS-INT-04 (interim path) | Contract date |
| CNS-04 (Example) | No cut-overs during the year-end claims peak | Vision 3.3 | Release calendar in the roadmap | Annually |
| [CNS-nn] | [Constraint] | [Source] | [ARS IDs] | YYYY-MM-DD |
11. Assumptions
| ID | Assumption | Requirements affected | Owner | Confirm by | If false |
|---|
| ASM-01 (Example) | The cloud landing zone is approved for confidential data | ARS-TEC-02, ARS-DAT-02 | [@platform-lead] | YYYY-MM-DD | Add a hosting option; revisit IS-06 |
| ASM-04 (Example) | The claims package supports external rules for triage | ARS-BUS-01, ARS-BUS-03 | [@application-architect] | Proof of concept end | Build triage as a separate service |
| ASM-05 (Example) | Peak volume stays below 1,500 claims per hour | ASC-02 | [@head-of-claims] | Annually | Re-size ASC-02 and repeat capacity tests |
| [ASM-nn] | [Assumption] | [ARS IDs] | [@owner] | YYYY-MM-DD | [Consequence] |
12. Gap analysis results
| Gap ID | Gap (from the definition document) | Type | Requirements that verify closure |
|---|
| GAP-B-01 (Example) | Single claims path to triage with simple and complex paths | Replaced | ARS-BUS-01, ARS-BUS-02 |
| GAP-B-03 (Example) | Partner claim submission | New | ARS-BUS-04, ARS-INT-05 |
| GAP-B-04 (Example) | Two manual approvals to risk-based approval | Enhanced | ARS-BUS-03 |
| GAP-D-01 (Example) | Four customer stores to hub as master | Replaced | ARS-DAT-01, ARS-DAT-03 |
| GAP-D-03 (Example) | Consent entity in the hub | New | ARS-DAT-04 |
| GAP-A-03 (Example) | Handler workspace | New | ARS-APP-02 |
| GAP-A-04 (Example) | Legacy CRM eliminated | Eliminated | ARS-APP-03 |
| GAP-T-01 (Example) | File transfer to API gateway and events | Replaced | ARS-APP-01, ARS-INT-01, ARS-INT-02 |
| GAP-T-02 (Example) | Hosting move to cloud container platform | Replaced | ARS-TEC-02, ARS-DAT-02 |
| GAP-T-03 (Example) | Private connectivity | New | ARS-TEC-04 |
| GAP-T-04 (Example) | Central observability | Enhanced | ARS-TEC-03 |
| [GAP-x-nn] | [Gap] | [Type] | [ARS IDs] |
Gaps without a row (in the example GAP-B-02, GAP-B-05, GAP-D-02,
GAP-D-04, GAP-A-01, GAP-A-02, GAP-A-05) must either receive a requirement
before the baseline or be marked "verified by work package acceptance
only" with the board's agreement.
13. Traceability
| Req ID | Goal / driver / constraint | Gaps | Work package | Contract | Gate or plateau | Status |
|---|
| ARS-BUS-01 (Example) | BG-01 | GAP-B-01 | WP-03 | AC-03 | Pre-production, TA-2 | Baselined |
| ARS-DAT-01 (Example) | BG-02 | GAP-D-01 | WP-02 | AC-02 | TA-1 | Baselined |
| ARS-DAT-02 (Example) | CNS-02 | GAP-T-02 | WP-01 | AC-01 | Design, pre-production | Baselined |
| ARS-APP-01 (Example) | BG-01 (via AP-01) | GAP-T-01 | WP-03 | AC-03 | Design, TA-2 | Baselined |
| ARS-TEC-01 (Example) | BG-04 | GAP-T-02 | WP-01 | AC-01 | Pre-production | Baselined |
| ARS-INT-01 (Example) | BG-02 | GAP-T-01 | WP-02 | AC-02 | TA-1 | Baselined |
| ARS-INT-04 (Example) | CNS-03, vision risk RSK-01 | GAP-D-01 | WP-02 | AC-02 (amended) | TA-1 | Agreed |
| ARS-SEC-03 (Example) | BG-04, DRV-02 | None | WP-02, WP-03 | AC-02, AC-03 | Before go-live of each | Baselined |
| [ARS-xxx-nn] | [BG / DRV / CNS] | [GAP IDs] | [WP-nn] | [AC-nn] | [Gate] | [Status] |
The requirement-level matrix for projects lives in the requirements
traceability matrix (requirements/traceability-matrix); this table
covers architecture requirements only.
14. Verification and acceptance
14.1 Verification methods
| Method | Meaning in this specification | Typical evidence |
|---|
| Inspection | Examine a design, configuration or document against the fit criterion | Review record, configuration export |
| Analysis | Derive the result from data, models or calculation | Data quality report, capacity model |
| Demonstration | Show the behaviour in a controlled run without detailed measurement | Recorded demo, witness sign-off |
| Test | Execute defined cases and measure the result | Test report with pass or fail per case |
14.2 Verification points
| Point | Requirements checked | Evidence owner | Accepted by |
|---|
| Design review of each work package | All Must requirements by inspection or analysis | Delivery team architect | Domain architect |
| Pre-production | Test and demonstration requirements in the contract | Delivery team test lead | Lead architect |
| Plateau exit | Success measures SM-01 to SM-05 for that plateau | Measure owners | Architecture Board |
| Compliance review | Full evidence pack for the contract | Delivery team | Architecture Board (architecture/architecture-compliance-assessment) |
A Must requirement that fails verification blocks acceptance unless the
board grants a time-limited dispensation under its charter. A Should
requirement that fails needs a dispensation or a recorded reason accepted
by the lead architect.
15. Requirements change management
- Anyone may propose a new or changed requirement to the requirements
manager, with the reason and the affected IDs.
- The requirements manager assesses impact on gaps, work packages,
contracts, specifications and success measures within [five] working
days.
- Changes to Proposed or Agreed requirements are decided by the lead
architect.
- Changes to Baselined requirements go to the Architecture Board through
an Architecture Change Request (
architecture/architecture-change-request);
the board classifies the change and decides.
- Approved changes produce a new minor version of this specification, an
updated traceability table and, where a contract is affected, a
contract amendment.
The wider requirements process (elicitation, prioritisation, tooling) can
be set out in a requirements management plan
(requirements/requirements-management-plan).
16. Glossary and references
16.1 Glossary
| Term | Meaning in this document |
|---|
| Architecture requirement | A measurable condition that any implementation must satisfy to realise the target architecture |
| Fit criterion | The test that decides whether a requirement is met |
| Success measure | A measurable indicator that the realised architecture delivers the intended value |
| Business service contract | An agreement on the outcome and service levels a business service delivers to its consumers |
| Application service contract | An agreement on the interface, capacity, availability, recovery and support of an application service |
| Interoperability | The ability of organisations and systems to exchange and use information and services correctly |
| Implementation guideline | Advice on how to implement in line with the architecture, departures from which need a recorded reason |
| Implementation specification | A binding detailed description, such as an interface or schema, that implementers build against |
| Baseline (of requirements) | An approved, versioned set of requirements that contracts reference |
| [Term] | [Meaning] |
16.2 References
| ID | Reference | Version / date |
|---|
| REF-01 | The TOGAF Standard, 10th Edition (The Open Group, catalogue C220), incorporating Technical Corrigendum 1 (U254, 15 May 2025) | 19 May 2025 |
| REF-02 | Architecture Definition Document (architecture/architecture-definition-document) | [x.y] |
| REF-03 | Architecture Vision (architecture/togaf-architecture-vision) | [x.y] |
| REF-04 | Architecture Roadmap and Transition Architectures (architecture/architecture-roadmap-transition) | [x.y] |
| REF-05 | Architecture Principles Catalogue (architecture/architecture-principles) | [x.y] |
| REF-06 | Architecture Contract (architecture/architecture-contract) | [AC-nn] |
| REF-07 | Non-functional requirements catalogue (requirements/nfr-catalogue) | [x.y] |
| REF-08 | AsyncAPI Specification 3.1.0; CloudEvents 1.0.2 (examples in section 9) | Check current versions at asyncapi.com and cloudevents.io |
Standard and licence note
Structure aligned with The TOGAF Standard, 10th Edition (2025 release with Technical Corrigendum 1),
published by The Open Group: the Architecture Requirements Specification
deliverable, developed with the Architecture Definition Document in
Phases B to D of the Architecture Development Method, refined in Phases E
and F and maintained through Requirements Management. TOGAF and ArchiMate
are registered trademarks of The Open Group. This template uses only the
names of phases and deliverables; all text is original. It was written
from general professional practice, without reading, quoting,
paraphrasing or summarising the text of the standard. It uses the
deliverable's content headings by name only and reproduces no
definitions, tables or descriptive text from it. The ID scheme, priority scale,
verification methods, status lifecycle and example values are suggestions
of this template, not requirements of the standard. Check the current
edition and any technical corrigenda at opengroup.org, and the versions of
any external standards you list, before each baseline.
Template licence: MIT.