Ниже приведены полезные рекомендации по проверке требований:

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

Ниже перечислены роли, которые должны принимать участие в проверках:

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

Кроме того, на собрания рекомендуется приглашать следующие роли (в особенности на ключевых вехах):

• Заинтересованные лица - заказчики и пользователи (Если возможно)
• Менеджер по управлению изменениями (Если рассматриваются запросы изменений)
• Проектировщик тестов (Необязательно)
• Архитектор программного обеспечения (Необязательно; как правило, на ранних этапах жизненного цикла программного обеспечения в ходе разработки архитектуры)
• Руководитель проекта (Необязательно; как правило, на ранних этапах жизненного цикла или в случае проверки значительных изменений)

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

Как правило, проверка разделяется на следующие собрания:

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

Обратите внимание, что даже если вы сможете проверить все интересующие вас моменты в рамках одного собрания, то для утверждения всех решений может потребоваться несколько собраний. Будьте готовы к тому, что дополнительные собрания могут потребоваться для рассмотрения каждой новой версии требований рабочих продуктов.

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

Литература

См. главу 11 [BIT03].