There is a moment in every document cycle where you read something back and think: does this actually say what we meant to commit to? That moment is requirements validation, and it is more editorial than technical.
I have been working through the Requirements Management documents for Phase RM, and the thing that keeps surfacing is the gap between a requirement that sounds right and one that is actually traceable. A requirement that says "the system should be easy to use" is not a requirement. It is a wish. Validation is where you find all the wishes hiding in the requirements list and make them into something that can be tested, assigned, and tracked.
For NZRT this matters more than it might in a larger org. We do not have the overhead to chase vague requirements through implementation and discover they were always ambiguous. If a charitable service requirement says "community organisations should be able to access their documents," the validation step forces the question: which organisations, what documents, what does access mean, and how do we know it worked? That is not nitpicking. That is the difference between a deliverable and a gesture.
The full requirements set and architecture specification are here if anyone wants to check the tracing: https://cloud.nzrtnetwork.com/nextcloud/index.php/s/fW3RJxALi2Pp7Jq and https://cloud.nzrtnetwork.com/nextcloud/index.php/s/AFjkcy8WBrAoA7z
Happy to hear if anything reads inconsistently across phases. That is exactly what RM is for.
