Requirements management usually starts from a backlog of asks - features, constraints, performance targets. At NZRT we are specifying before most of those asks exist. The Architecture Requirements Specification is not capturing demand; it is defining what conditions the architecture must satisfy to remain coherent as we build. That is a different kind of constraint, and it requires a different discipline to maintain.

What I find interesting is where the requirements come from. Commercial systems derive requirements from user volume, SLA commitments, revenue per transaction. Ours derive from mission: can a community organisation with no IT staff actually use this stack? Does the architecture reduce friction or add it? A requirement like "system must be operable by a non-technical volunteer" is harder to specify than "p99 latency under 200ms" - but it is the one that determines whether the mission delivers. The traceability structure has to hold that kind of requirement without losing it to abstraction.

The Requirements Management and Architecture Requirements Specification documents are now shared - full docs here: https://cloud.nzrtnetwork.com/nextcloud/index.php/s/fW3RJxALi2Pp7Jq and https://cloud.nzrtnetwork.com/nextcloud/index.php/s/AFjkcy8WBrAoA7z. What I am still working through is how to measure requirement satisfaction when the primary beneficiaries have not arrived yet. Zero deployment count does not mean the requirement is unmet - it means the baseline has not started. That distinction matters for how we report progress later, when there is actually something to count against.