ADM Architecture Requirements Management

The continuous hub of the ADM: identify, store, and feed requirements into and out of every phase.

About this phase

Requirements Management sits at the center of the ADM cycle diagram because it is not a phase you pass through once — it is a continuous process that operates throughout the whole cycle. Every ADM phase both draws requirements from it and generates new or changed requirements into it.

Its job is to manage the flow: identify requirements, baseline them, store them in the Requirements Repository, and coordinate how changed requirements are assessed and fed into the relevant phases. Importantly, Requirements Management itself does not dispose of, address, or prioritize requirements — that is done in the relevant ADM phase.

Dealing with changing requirements is central to the ADM's design: architecture deals with uncertainty by definition, and requirements are expected to change. The Requirements Impact Assessment is the key artifact for working out what a changed requirement means for the architecture and which phases must be revisited.

Objectives

Ensure that the Requirements Management process is sustained and operates for all relevant ADM phases.
Manage architecture requirements identified during any execution of the ADM cycle or a phase.
Ensure that relevant architecture requirements are available for use by each phase as the phase is executed.

Steps in this phase

0/9 · 0%

1.Identify/document requirements (within an ADM phase)Requirements are first identified inside the relevant ADM phase — e.g., using business scenarios in Phase A — and documented.
2.Baseline requirementsDetermine priorities with the phase, confirm stakeholder buy-in, and record the baselined requirements in the Requirements Repository.
3.Monitor baseline requirementsContinuously watch the baseline for changes arising anywhere in the cycle.
4.Identify changed requirements and record prioritiesCapture new, removed, or modified requirements; record changed priorities; resolve conflicts — while the ADM phase remains responsible for decisions.
5.Assess the impact of changed requirementsAssess impact on current and previous phases (Requirements Impact Assessment), and decide whether to implement the change now or defer it to a later cycle.
6.Implement requirements arising from Phase HFeed change-management-driven requirements into the process so the architecture can be updated or a new cycle triggered.
7.Update the Requirements RepositoryRecord the changed requirements information, keeping the repository the single source of requirement truth.
8.Implement change in the current phaseApply agreed requirement changes within the phase currently being executed.
9.Assess and revise gap analysis for past phasesWhere changes affect completed phases, revisit their gap analyses so the end architecture remains complete and consistent.

Key inputs

The inputs to the Requirements Management process are the requirements-related outputs of every ADM phase
The first high-level requirements are produced as part of the Architecture Vision (Phase A)
Each architecture domain phase (B, C, D) generates detailed requirements and modifies existing ones
Requirements arising from implementation (Phase G) and change management (Phase H)

Key outputs

Changed requirements and a record of them (Requirements Repository updates)
Requirements Impact Assessment — identifying the phases that need to be revisited and forming the basis of a new Statement of Architecture Work if changes are significant
Updated Architecture Requirements Specification, if changes arise

Worked example — Meridian Retail Group

Generated sample documents for a fictional company, showing what this phase consumes and produces. They are illustrative study aids, not templates from the standard.

Example inputs

PFrom Preliminary Phase

AFrom Phase A: Architecture Vision

BFrom Phase B: Business Architecture

CFrom Phase C: Information Systems Architectures

DFrom Phase D: Technology Architecture

EFrom Phase E: Opportunities and Solutions

FFrom Phase F: Migration Planning

GFrom Phase G: Implementation Governance

HFrom Phase H: Architecture Change Management

Prepared for this phase

example inputDeliverablefrom PreliminaryThe document from the sponsoring organization that triggers an ADM cycle — the key handoff from the Preliminary Phase into Phase A.

Request for Architecture Work

Sponsoring organization: Meridian Retail Group — Office of the COO Date: 2 April 2026 Reference: RAW-2026-001 Addressed to: Architecture Board (submitted via the Lead Architect)

Organization sponsors

Chief Operating Officer (business sponsor); Chief Information Officer (executive sponsor for architecture).

Mission statement

Deliver the "One Meridian" unified customer experience: any customer, recognized in any channel, served from a single view of orders, inventory, and preferences.

Business goals and changes

Increase repeat-purchase rate from 31% to 40% within 24 months
Enable buy-online-pickup-in-store (BOPIS) in all 240 stores
Consolidate 4 customer databases into a governed single customer view
Reduce integration spend by 20%

Strategic plans

Responds to the One Meridian strategy (FY26–FY28) and Board Directive 26-04. Goals map to drivers DRV-01 to DRV-04 in the Driver/Goal/Objective catalog.

Time limits

Architecture definition (Target Architecture and roadmap) approved before the 1 Nov 2026 peak trading freeze
First Transition Architecture in production before the FY27 peak freeze

Changes in the business environment

Competitors now offer click-and-collect as standard; digital revenue at 26% and rising; POS v9 reaches end of life in 2027.

Organizational constraints

Peak trading freeze: no production change 1 Nov – 15 Jan
Franchise stores operate their own POS until contract renewal (FY27)

Financial constraints

Indicative program envelope of $18M over 2 years, subject to Investment Committee approval per tranche.

External and business constraints

GDPR and PCI-DSS compliance mandatory
3PL logistics contract fixes EDI message formats until 2027

Current business system description

Channel-based operating model: Digital Commerce, Store Operations, and Customer Care each run their own customer processes and service standards.

Current systems description

4 customer databases, 3 order management systems, in-store POS (v9, EOL 2027), monolithic e-commerce platform, nightly-batch warehouse integration.

Developing organization and resources available

Meridian EA team (Lead Architect plus 4 domain architects), working under the Tailored Architecture Framework v1.0 and Architecture Principles v1.0. Business subject-matter experts released for up to 2 days per week during Phases B–D.

Success criteria

An approved Target Architecture and Implementation and Migration Plan for the One Meridian program, with the first Transition Architecture delivered before the FY27 peak trading freeze.

Submitted by: COO, 2 April 2026 · Accepted for Phase A: Architecture Board, 9 April 2026

Example outputs

example outputDeliverableThe key Requirements Management output: what a changed requirement means, and which phases must be revisited.

Requirements Impact Assessment — REQ-NEW-038 (Right to erasure)

Reference: RIA-2026-09 · Date: 22 Jul 2026 · Status: Approved by Architecture Board Prepared by: Requirements Management with the Phase C architects (R. Mehta, S. Cho) · Decision owner: Phase C, endorsed by the Board

Requirement summary

Erasure propagation ≤ 30 days to all profile-data consumers, with audit trail.

Requirements affected

ID	Effect	Before	After
REQ-NEW-038	New	—	Baselined as REQ-D-03
REQ-B-014	Modified (conflict)	Retain purchase history 5 years for cohorts	REQ-B-014v2: cohorts on anonymized data
REQ-D-02	Clarified	Consent migrated with lineage	Lineage also required for erasure evidence
REQ-T-07	Constrained	RTO ≤ 1h, RPO ≤ 5min	Restores must re-apply erasures (Phase D to specify)

Phases affected

Phase	Impact	Action
C — Data Architecture (current)	Canonical model needs erasure-event entity; lineage metadata mandatory for profile-derived data	Incorporate now (current phase — step 8)
C — Application Architecture (current)	All profile consumers must implement an erasure-event handler; analytics store needs purge capability	Incorporate now
B — Business Architecture (completed)	New business process "Erasure request handling" + Care team responsibility	Revisit gap analysis (limited scope)
D — Technology (upcoming)	Event streaming must support compacted erasure topics; backup/restore policy impact	Carry as requirement into Phase D

Building blocks and candidate work packages affected

Building block	Change	Candidate work package
Customer Profile Service (ABB)	Emits erasure event, holds completion log	WP-04
Order Hub, WebShop, StorePOS, CareDesk	Erasure-event handler in each consumer	WP-05, WP-07
Marketing analytics store	Purge of profile-linked records	WP-04
Integration layer	Erasure events replace manual purge scripts	WP-06

Options considered

Option	Benefit	Cost / risk
A. Implement in current cycle	Compliant at TA-1 go-live; designed in once	~12 extra architecture days; 2-week extension to Phase C
B. Defer to next cycle	No schedule change now	Profile service would go live without propagation; regulatory exposure; costly retrofit to every consumer

Conflict resolution

Conflict with REQ-B-014 (5-year cohort analytics): resolved in-phase — analytics retains anonymized aggregates only; profile-linked records purged. Both requirements updated in the repository (v2 of each). Marketing (requirement owner) and the DPO signed the resolution on 20 Jul 2026.

Disposition

Implement in current cycle. Impact is contained to in-flight phases plus a bounded revisit of Phase B gap analysis; deferral would create regulatory risk at TA-1 (profile service go-live).

Statement of Architecture Work: the change is not significant enough to need a new Statement of Architecture Work. SAW-2026-001 stands; the Phase C end date moves by two weeks within the May–August window.

Repository updates

REQ-NEW-038 baselined as REQ-D-03 (must-have)
REQ-B-014 modified → REQ-B-014v2 (anonymized analytics)
Architecture Requirements Specification draft updated (§4.2)
Phase B gap analysis revisit logged as action RM-A-11 (owner T. Lindqvist, due 5 Aug 2026)

Study notes

Produced in: Step 5: Assess the impact of changed requirements · Step 9: Assess and revise gap analysis for past phases

The phase table is the heart of the document: it shows which completed, current and future phases are touched. Completed phases get a gap-analysis revisit (step 9), the current phase absorbs the change (step 8), and future phases receive it as an input.
The 'implement now or defer' decision is the classic outcome of step 5. Deferral would place the requirement in the repository for a later cycle rather than drop it.
A significant change would trigger a new Statement of Architecture Work. Here the assessment records explicitly that SAW-2026-001 is unaffected, which is a common exam angle.
The conflict with REQ-B-014 was resolved by the phase and its stakeholders. Requirements Management recorded the outcome; it did not make the trade-off.

Study tips & key concepts

Requirements Management manages the flow of requirements — it does not dispose of, address, or prioritize them. That always happens within the relevant ADM phase.
It is a continuous process operating across the whole cycle — hence its position at the center of the ADM diagram, connected to every phase.
Key artifacts: the Requirements Repository (stores requirements) and the Requirements Impact Assessment (what a change means and which phases to revisit).
The Architecture Requirements Specification is a different thing: a phase deliverable (a set of quantitative statements the implementation must meet) — the repository holds requirements; the specification is a contract-style deliverable.
Remember the two-way arrows in the diagram: every phase both consumes requirements from and contributes requirements to the central process.