4 of the 11 questions we have for this objective, shown with the answer and the reasoning.
How to manage architecture requirements
Fenwick Retail is in Phase D. A new regulation requires that customer payment data be stored only in-country, which changes a requirement already used to define the Phase C Data Architecture and the Phase B business service for online checkout. The Phase D team wants to apply the change only to the Technology Architecture and carry on.
Which two actions should the architect take under the Requirements Management process? Each correct answer presents part of the solution.
- AAssess the impact of the changed requirement on the current phase and on previous ADM phases, and decide whether to revisit Phases B and C or defer the change.Requirements Management includes assessing the impact of changed requirements on current and previous ADM phases, typically documented in a Requirements Impact Assessment.
- BRecord the changed requirement and its priority in the Requirements Repository after confirming stakeholder agreement.Changed requirements and their priorities are recorded in the Requirements Repository with stakeholder buy-in so that all phases work from the same baseline.
- CApply the change only to the Technology Architecture, because the current phase owns all requirement changes.A requirement that affects earlier phases cannot be resolved by changing only the current phase. That leaves the Data Architecture and business service inconsistent with the requirement.
- DHold the changed requirement until Phase H, because requirement changes are handled only after implementation.Requirements Management operates in every phase. A regulatory change discovered during Phase D must be assessed now, not deferred to after implementation.
- ERestart the engagement from the Preliminary Phase so that the Architecture Capability can be redefined.The Preliminary Phase establishes the Architecture Capability. A changed regulatory requirement does not call the capability into question.
Why: The TOGAF Standard (ADM, Architecture Requirements Management) defines steps for identifying changed requirements, recording priorities, and assessing the impact of changed requirements on current and previous ADM phases. The output is usually a Requirements Impact Assessment, which helps the team decide whether to revisit earlier phases or defer the change to a later cycle. Changes and their priorities are recorded in the Requirements Repository with stakeholder agreement. The scenario's trap is local fixing: the in-country rule touches the Data Architecture and a business service, so it must be assessed across phases, not just applied in Phase D.
How to manage architecture requirements
At Tidewell Shipping, Phase B has produced 60 business requirements from interviews and business scenarios. The requirements currently sit in workshop notes spread across several team members' folders. The architect must make them a stable reference for the rest of the cycle.
What should the architect do under the Requirements Management process?
- AWait until Phase F to collect and prioritise the requirements, when the work packages are known.Requirements must be baselined as they are identified. Waiting until Phase F leaves Phases C and D without an agreed reference.
- BCopy the requirements into the Architecture Vision and treat the vision as the requirements baseline.The Architecture Vision is a high-level description produced in Phase A. It is not the store for detailed requirements.
- CSend the requirements to the implementation projects so that they can start estimating.Implementation projects are mobilised after Phase F. Sending unbaselined requirements early creates rework.
- DBaseline the requirements by determining their priorities, confirming stakeholder agreement, and recording them in the Requirements Repository.Baselining requirements, with priorities and stakeholder buy-in recorded in the Requirements Repository, is a step of the Requirements Management process.
Why: The TOGAF Standard (ADM, Architecture Requirements Management) describes the Requirements Management steps that run alongside the ADM phases. Once requirements are identified in a phase, they are baselined: their priorities are determined, stakeholder agreement is confirmed, and they are recorded in the Requirements Repository. Later steps monitor the baseline and assess any changes. Scattered workshop notes provide no single, agreed reference, which is the problem baselining solves.
How to manage architecture requirements
Gannet Airlines is defining a shared flight-status service that five applications will consume. During Phase C, the application owners agree on the service's operations, response time, availability and support hours. The architect wants these agreements to bind the teams that later build and consume the service.
Where should the architect record these agreements?
- AIn the Architecture Vision, as a value proposition for the five application owners.The Architecture Vision describes the high-level target and its value. Detailed service agreements are far too specific for it.
- BAs an application service contract in the Architecture Requirements Specification.Application service contracts, together with business service contracts, are typical content of the Architecture Requirements Specification and define measurable service commitments.
- CIn the Communications Plan, so that each application owner is informed of the agreement.The Communications Plan schedules stakeholder communication. Recording the agreement there does not make it a requirement implementation must meet.
- DIn the Implementation Factor Assessment and Deduction Matrix.That matrix records factors that affect implementation and the deductions made from them. It is not where service contracts are specified.
Why: The TOGAF Standard (Architecture Content, Architecture Deliverables) lists business service contracts and application service contracts among the typical contents of the Architecture Requirements Specification. Because the specification provides the quantitative statements that implementation projects must meet to comply with the architecture, recording the flight-status agreements there makes them binding on later projects and Architecture Contracts. The distractors are real deliverables and techniques that serve vision, communication and planning rather than measurable requirements.
How to manage architecture requirements
Ottery Mutual's architect is finalising the Architecture Requirements Specification for a member-portal programme. Implementation projects must work within a fixed regulatory deadline and an approved list of hosting providers, and the plan assumes that a partner's identity API will be available by Q2. Project managers need to see these conditions alongside the measurable requirements.
Where should the architect record the deadline, the hosting restriction and the identity API dependency?
- AIn the Architecture Principles, as general rules that guide all future architecture work.Principles are enduring general rules and guidelines. A specific deadline and a dated dependency are not principles.
- BIn the Architecture Roadmap, as work packages.Work packages describe change to be delivered. Constraints and assumptions are conditions on that delivery, not work packages.
- CIn the Communications Plan, so that stakeholders are informed of them.The Communications Plan schedules communication with stakeholders. It is not where implementation conditions are specified.
- DIn the constraints and assumptions sections of the Architecture Requirements Specification.Constraints and assumptions are typical contents of the Architecture Requirements Specification, alongside the measurable requirements that implementation must meet.
Why: The TOGAF Standard (Architecture Content, Architecture Deliverables) lists constraints and assumptions among the typical contents of the Architecture Requirements Specification, together with success measures, architecture requirements, service contracts, implementation guidelines, specifications and standards, interoperability requirements and IT service management requirements. Recording the regulatory deadline and hosting restriction as constraints, and the identity API availability as an assumption, keeps them next to the requirements that projects must meet, and makes the assumption visible as a risk to monitor.