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

Для полного понимания неполадок, нуждающихся в устранении, очень важно установить список заинтересованных лиц в концептуальном видении проекта. Ключевые заинтересованные лица должны быть вовлечены в сбор информации о желаемых функциях. Сбор информации можно организовать в форме семинара по требованиям. Функциям можно присвоить различные атрибуты, отражающие их обоснование, относительную ценность, приоритет, источник запроса и т.п., для управления зависимостями и рабочими планами.

Главный артефакт, применяемый для сбора информации в ходе анализа неполадок, - видение. Этот артефакт представляет собой высокоуровневое представление системы, которую предстоит создать (см. раздел разработка видения). В рамках видения начальные требования высокого уровня задают ключевые функции, наличие которых предполагается в разработанном продукте. Как правило, речь идет о наборе высокоуровневых функций, с помощью которых можно решить важнейшие задачи.   

Для определения начального содержания проекта нужно согласовать границы системы.   Аналитик создает перечень пользователей и систем, которые будут взаимодействовать с разрабатываемой системой.   Пользователи системы представлены в виде субъектов в модели вариантов (см. раздел Поиск субъектов и вариантов).

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

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