Ответ.

Процесс сбора и анализа требований — это систематическое выявление, организация и документирование бизнес-потребностей заказчика для их дальнейшей реализации в IT-системах или бизнес-процессах. Основные этапы:

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

2. Сбор требований: использование техническных сессий (workshop), анкет, наблюдений, прототипирования. Важно обеспечить вовлечённость всех стейкхолдеров.

3. Анализ и категоризация: выявление противоречий, дублирующихся задач, классификация требований на бизнес/функциональные/не-функциональные.

4. Документирование: формализация в виде SRS (Specification Requirement Specification), user stories или сценариев.

5. Валидация и согласование: проведение обзоров с заказчиком, внесение корректировок, утверждение финальной версии требований.

Ключевые особенности:

• Глубокое понимание бизнес-процессов необходимо для верной интерпретации пожеланий заказчика.

• Постоянная коммуникация: сбор требований — итеративный процесс, связанный с изменениями по ходу проекта.

• Артефакты требований (диаграммы, модели, спецификации) — критически важны для дальнейшей работы команды.

Вопросы с подвохом.

Можно ли ограничиться только одним (например, бизнес- или функциональными) типом требований?

Нет, бизнес-аналитик обязан охватить все типы требований: бизнес, пользовательские, функциональные и нефункциональные. Иначе рискуете получить продукт, не соответствующий ожиданиям всех стейкхолдеров.

Всегда ли достаточно провести только одну сессию сбора требований?

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

Можно ли изменять утвержденные требования без формальных процедур?

Нет, любые изменения должны проходить процесс change management, иначе возникнет хаос, нестыковки и недопонимание между командами.

Типовые ошибки и анти-паттерны

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

Пример из жизни

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