Стив Макконнелл, в его книге «Быстрая разработка», подробно описывает как пользователи могут препятствовать сбору требований:

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

Это может привести к ситуации, где пользовательские требования продолжают изменяться, даже когда система или разработка новой продукции были начаты.

Проблемы инженеров / разработчиков

Возможные проблемы, вызванные инженерами и разработчиками во время анализа требований:

  • У технического персонала и конечных пользователей могут быть различные мнения. Следовательно, они могут неправильно полагать, что они находятся во взаимопонимании, пока готовое изделие не будет отправлено.
  • Инженеры и разработчики могут попытаться подкорректировать требования чтобы они соответствовали существующей системе или модели, вместо того, чтобы разработать систему, соответствующую потребностям клиента.
  • Анализ может часто выполняться инженерами или программистами, а не персоналом с навыками работы с людьми и знаниями проблемной области.

Решения проблем

Одно из решений проблемы общения состояло в том, чтобы нанять специалистов в деловом или системном анализе.

Методики, введённые в 1990-х — прототипирование, унифицированный язык моделирования (UML), сценарии использования и гибкая методология разработки, — также предназначены для решения описанных выше проблем.