Короткий ответ саркастичному bamalip.

Самые лучшие спецификации я видел там, где их с нуля писали ведущие инженеры и руководители групп. Причём, они были в обычных вордовских файлах.

Незамутнённый "специалист по требованиям" в лучшем случае может откопать информацию и верифицировать её при перекрёстном сравнении. Для валидации нужны специалисты в предметной области.

Мой уникальный скил в requirements engineering - это умение найти лажу в сложных многосвязных информационных структурах.

То есть, я могу выяснить, что инженеры-электрики на самом деле ещё не определились с типом коннектора в требовании XXX.NNN, пять требований из спецификации по безопасности повисли и на самом деле никак не тестируются, а в техзадании на подсистему X требование XXX.XXX.N выведено не из требований пользователя, а из протокола тестирования, и похоже, это не ошибка с неправильно направленной стрелкой, а непонимание иерархии документов.

То, что я мог на приемлемом уровне говорить с инженерами-механиками или со страховыми математиками, - это не результат моих знаний в теории и практике requirements engineering, а честное изучение предмета по внутрифирменной документации и банальным учебникам. Иногда в объёмах полновесного университетского курса.

Программисты никогда не умели писать нормальные требования, потому что мыслят языками программирования. Сертификации и курсы только ухудшили ситуацию, укрепив самомнение и убедив в совершенно ошибочной формуле "Спросите заказчика - он расскажет".

Популярность agile связана во многом с девизом "Всё равно техзадание никто написать не сумеет, потому будем делать как получится, а заказчики потом скажут, что им не нравится."