Требования: по ту сторону баррикад

На страницах блогов тестировщиков и других онлайн-ресурсов , посвященных тестированию ПО и вообще качеству ПО , часто затрагивается тема требований к ПО. Большинство специалистов по тестированию предпочитают работать с четкими требованиями к ПО для того, чтобы иметь возможность также четко организовывать свою деятельность и выдавать продукт максимально удовлетворяющий чаяниям заказчика. Но при этом познания многих тестировщиков о процессе составления требований заканчиваются содержимым соответствующей страницы в Wikipedia.
Желающим немного приоткрыть завесу того, что из себя представляет процесс создания требований к ПО и управления ими , могу посоветовать недавно перечитанную мной книгу, которая стала классикой для многих аналитиков и системных архитекторов

"ПРИНЦИПЫ РАБОТЫ С ТРЕБОВАНИЯМИ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ" (Дин Леффингуэлл, Дон Уидриг)

Книга написана в 2002 году и за это время условия рынка разработки ПО ужесточились, но многие принципы работы с требованиями по-прежнему остаются актуальными. Например, описанные техники выявления всех явных и скрытых пожеланий заказчика ( о которых он и сам с трудом пока еще догадывается ) , считаю, могут действительно помочь сэкономить кучу сил и времени.

Тестирование требований

Перечитываю старую добрую кингу Альфреда Дастина (Elfreide Dusting) "Автоматизированное тестирование программного обеспечения" (Automated Software Testing). Читал ее когда-то очень давно, не имея реального шанса проверить на практике советы и предположения, которые делает автор в своей книге. Сейчас, став чуть более опытным, многое из прочитанного становится более понятным, подтверждающим полученный опыт и "набитые шишки". Особенно понравилась следуюшая мысль (которая для кого-то может показаться банальной):
Программа, в основе которой лежат неточные требования, не будет удовлетворять заказчика или конечного пользователя независимо от качества описания архитектуры или программного кода, составляющего модули приложения (выделил жирным , по-моему , главную фразу предложения:)
Тысячу раз СОГЛАСЕН - так оно зачастую и происходит...
В качестве мер по предотвращению дефектов и проблем с конечным пользователем автор предлагает привлекать тестировщиков (высокой квалификации) с самых ранних стадий разработки ПО. В частности, со стадии составления спецификаций требований. Это мне также кажется верной стратегией, но ее соблюдение требует дополнительных трудозатрат со стороны тестирования. Кроме того, есть и психологический момент - не все разработчики, сисарки, менеджеры видят в тестировщиках людей, способных влиять на архитектурные решения до начала кодирования.
Интересно было бы узнать, насколько распространена практика привлечения сотрудников группы(сектора,отдела) тестирования к фазе составления требований к программному продукту и , соответственно, насколько она эффективна?
Если у кого есть желание поделиться своим опытом и мнением на этот счет, то буду признателен за соответствующие комментарии.