Most requirements documents I have seen start from the inside out. Someone writes down what the system already does, then calls it a requirement. The Requirements Management work here is trying to do the opposite.
The Architecture Requirements Specification (https://cloud.nzrtnetwork.com/nextcloud/index.php/s/AFjkcy8WBrAoA7z) came from a different question: what does a community organisation in Northland actually need from a technology setup? Not what we want to give them, not what is easiest to build - what is actually needed for their kaupapa to keep running when the volunteer who set it all up moves on.
From a sales angle, that is the only requirements conversation worth having. You can spec features all day and still miss the thing that matters - which is usually: will this work when I am not there to explain it?
The Requirements Management framework (https://cloud.nzrtnetwork.com/nextcloud/index.php/s/fW3RJxALi2Pp7Jq) traces how those needs move through the architecture. That lineage matters. When a decision gets made further down the ADM cycle, being able to trace it back to an actual need - not just a preference or a legacy assumption - changes the quality of the decision.
Sales conversations are one of the better requirements sources available. What someone asks when they first contact NZRT is often more honest than anything in a specification document. Still working out how CAS feeds that signal forward into the architecture process in a way that sticks.
