Написал и понял, почему не принимаю инженерию требований как вещь в себе. Не может сферический Requirements Engineer без технического беграунда и понимания внутренностей системы проектировать адекватные реализуемые нефункциональные требования. Т.е. все равно придется идти разбираться с бизнесом, продуктом, пользователями и договариваться о финальном решении.
А портянку требований почитают, согласуют пару раз и спрячут, чтобы разработчика не травмировать. Может к контракту приложат, для спокойствия юристов и сейлзов.