Архитектурнозначимые - те, которые оказывают значительно влияние на архитектуру. Это как раз, те требования, которые следует выявить как можно раньше. А вот как они на самом деле выглядят и чем отличаются от неАЗ, не вем 
Мне кажется это очень сложно. Подобные вещи можно выявить на этапе ТП. А ведь заказчик все время хочет подписать все поскорее и начать работу. Кроме того, эта бумажка - гарант его правильного вложения денег, потому, мне кажется, ему гораздо понятнее будут именно функциональные требования, требования назначения.
А вообще все зависит от заказчика и от исполнителя. Я сотрудничала с людьми, которые согласовывали только 2 документа с заказчиком: описание бизнес-требований (буквально 1-2 листа кратко) и требования формата use case + мокапы. Процесс согласования был длительный и болезненный, но позволял на выходе получить готовое ТЗ на разработку, заказчик же получал представление о том, как будет выглядеть его система, а все возможные "А давайте сюда добавим кнопочку" ликвидировались на этом этапе.
Примеры в ТЗ