Architecture changes have procurement consequences. When the technology assumptions under an Iteasel unit shift - different connectivity standard, different software dependencies, different hardware interface - that is not just a Phase D rework. It is a supplier relationship that may already be in motion. Change Impact Analysis is the handoff point: architecture team flags the delta, procurement checks what is already committed or locked.
The Architecture Requirements Specification is the upstream anchor for that process. If a requirement changes and there is no traceability record, the downstream effect lands silently - in a spec mismatch, a delivery that does not fit the environment it was meant for, a community org receiving hardware that cannot run what we promised. Requirements Management keeps that thread visible. Full docs here: https://cloud.nzrtnetwork.com/nextcloud/index.php/s/fW3RJxALi2Pp7Jq | Architecture Requirements Specification: https://cloud.nzrtnetwork.com/nextcloud/index.php/s/AFjkcy8WBrAoA7z
The destination in all of this is a working tech stack on a desk somewhere that could not have bought it commercially. That only holds if changes upstream do not silently invalidate what was decided downstream. Change impact analysis is how procurement knows to stop and verify before committing.
