10 эффективных методов сбора требований в IT: от интервью до Event Storming

Методы сбора требований делятся на два класса. Коллективные (интервью, мозговой штурм, Event Storming) предполагают активное участие стейкхолдеров — заказчика, пользователей, разработчиков. Независимые (анализ документации, наблюдение) аналитик выполняет самостоятельно, без прямого взаимодействия. Согласно стандарту BABOK 3.0, ни один метод не даёт полной картины в одиночку: оптимальный результат — комбинация подходов под тип и стадию проекта.

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

Коллективные и независимые методы: сводная таблица

Прежде чем выбирать конкретный инструмент, полезно понять его место в общей классификации. Коллективные методы работают там, где нужно извлечь знания из головы людей — они формируют бизнес-требования (BRQ, business requirements) и пользовательские требования (URQ, user requirements). Независимые дают базу для подготовки и помогают детализировать функциональные требования (FRQ, functional requirements) без живых встреч.

Общая иерархия выглядит так: BRQ декомпозируются в URQ, те — в FRQ. Параллельно существуют нефункциональные требования (NFRQ, non-functional requirements) — производительность, безопасность, масштабируемость, — влияющие на все уровни. Итоговый документ — спецификация требований к программному обеспечению (SRS, software requirements specification) по стандарту ISO/IEC/IEEE 29148:2011.

№1 «Системный аналитик: с нуля до проектирования систем» — профессиональное обучение всем методам

Разобраться в методологиях сбора требований по статьям — один вариант. Применить их в рамках реального учебного проекта под руководством практиков — принципиально другой. Именно для этого в линейке федерального проекта «Активные меры содействия занятости» (нацпроект «Кадры») есть программа «Системный аналитик: с нуля до проектирования систем» (72 ч, онлайн).

Что внутри: полный цикл работы с требованиями — от интервью со стейкхолдерами до формализации Use Case и написания спецификации. Всё на реальном проектном кейсе, без абстрактных упражнений.

Формат и условия: онлайн, занятия 1–2 раза в неделю в удобное время. Полная стоимость — 120 000 ₽; для участников программы бесплатно за счёт государственного финансирования. Документ по окончании — удостоверение о повышении квалификации установленного образца.

Зарплата выпускников: от 130 000 ₽ — максимальный показатель среди всех программ проекта.

Кому подходит: начинающим бизнес-аналитикам (BA) и системным аналитикам (SA), специалистам по контролю качества (QA-инженерам), тест-менеджерам, разработчикам, которые хотят перейти в аналитику, и проджект-менеджерам.

Поддержка после обучения: Центр карьеры с 7 500+ актуальными вакансиями, биржа заказов, HR-консультации, карьерные марафоны и сертификат на 10 000 ₽ для обучения в Sigma Academy.

На момент публикации в группе 63 свободных места из 85 — записаться можно на странице для трудоустроенных специалистов.

№2 Интервью — основной метод сбора требований

Интервью — структурированный диалог аналитика с одним стейкхолдером или малой группой. По популярности среди техник сбора требований занимает первое место в практике BA и SA.

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

Как проводить:

• подготовить список вопросов заранее;
• начать с небольшого разговора на отвлечённую тему (small talk) для снятия напряжения;
• задавать открытые вопросы для развёрнутого ответа, закрытые — для подтверждения гипотез;
• фиксировать протокол и параллельно вести запись.

Продолжительность — не более часа: концентрация собеседника заметно снижается после 40 минут.

Инструменты: Zoom или Google Meet для удалённых встреч, Otter.ai для автоматической расшифровки, шаблон протокола в Notion.

Плюсы:

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

Минусы: значительные временные затраты при большом числе участников; результат зависит от квалификации аналитика.

№3 Мозговой штурм: коллективная генерация требований

Мозговой штурм — групповая встреча для свободной генерации идей без немедленной критики. Тип — коллективный. Метод незаменим там, где проект плохо изучен или требования разных стейкхолдеров открыто конфликтуют.

Ключевое условие: опытный модератор. Без управления встреча рассыпается в неорганизованный поток — формально много идей, по факту ни одного конкретного требования.

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

Инструменты: Miro или FigJam для онлайн-досок, Confluence для протокола.

Плюсы:

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

Минусы: сложно организовать в географически распределённых командах; эффективность напрямую зависит от мотивации участников.

№4 Event Storming — современный метод для сложных доменов

Event Storming — визуальная коллективная методика из Domain-Driven Design (DDD, проектирование, ориентированное на предметную область). В отличие от мозгового штурма, фокус здесь не на идеях, а на конкретных бизнес-событиях (domain events) — тех, что запускают процессы в системе. Метод разработал Альберто Брандолини, сегодня он применяется как при старте новых продуктов, так и при архитектурном рефакторинге.

Как проводить: серия итеративных встреч → участники — разработчики, бизнес-эксперты и ключевые стейкхолдеры → на стикерах или в Miro фиксируются события (оранжевые), команды (синие), агрегаты (жёлтые) → опытный модератор ведёт весь процесс.

Когда применять: при старте сложного продукта, архитектурном рефакторинге, поиске узких мест в модели.

Инструменты: стикеры Post-it, Miro, Mural.

Плюсы:

• объединяет IT и бизнес в одной рабочей сессии;
• ускоряет принятие архитектурных решений;
• выявляет слабые места модели ещё до начала разработки.

Ограничения: требует подготовленных участников; без опытного модератора сессия теряет фокус.

№5 Воркшоп: групповое согласование требований

Воркшоп — структурированная встреча с заранее определённой повесткой и конкретным ожидаемым результатом. Отличие от мозгового штурма принципиальное: цель не генерация, а согласование. Воркшоп применяют именно тогда, когда у разных участников проекта накопились противоположные взгляды на требования.

Состав: представители противоборствующих позиций + модератор + секретарь. Без модератора встреча рискует превратиться в дискуссию без итога.

Инструменты: Confluence для фиксации решений, Miro для схем и диаграмм, Google Slides для презентации материалов.

Плюсы:

• детализирует и приоритизирует требования;
• вскрывает скрытые потребности, которые не поднимались в индивидуальных интервью.

Минусы: сложно организовать при географической распределённости команды; консенсус не гарантирован — может потребоваться участие спонсора проекта.

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

№6 Анкетирование: масштабный опрос стейкхолдеров

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

Когда использовать: нужно подтвердить или детализировать уже известные требования у аудитории более 10 человек; важна анонимность для честных ответов; нет возможности провести интервью с каждым участником.

Инструменты: Google Forms, SurveyMonkey, Typeform.

Практические советы:

• не превышать 15 вопросов — иначе падает процент завершения;
• даже к открытым вопросам предлагать варианты ответов как подсказки;
• перед запуском протестировать на малой группе (5–7 человек).

Плюсы:

• скорость и масштабируемость;
• анонимность повышает честность ответов;
• один опросник можно повторно использовать как бриф.

Минусы: не выявляет скрытые и неявные требования; задать уточняющий вопрос в процессе невозможно.

Анкетирование хорошо работает в связке с интервью: сначала глубинные беседы с ключевыми стейкхолдерами— затем широкий опрос для проверки гипотез у большой группы.

№7 Прототипирование: сбор требований через модель ожидаемого продукта

Сбор требований путём предоставления модели ожидаемого продукта — это и есть прототипирование. Человек значительно лучше формулирует потребности, когда видит конкретный макет, а не описывает систему в абстрактных словах.

Метод существует в трёх уровнях точности:

• Низкая: бумага, флипчарт, Paint — быстро и бесплатно, для самых ранних стадий;
• Средняя: Miro, Balsamiq, Excel — схемы без интерактивности; оптимальны для учётных систем;
• Высокая: Figma, Proto.io — интерактивные кликабельные прототипы с реалистичным UX.

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

Для аналитиков, работающих с учётными системами, как правило достаточно средней точности — дизайнер на этом этапе не нужен.

Плюсы:

• быстрая проверка гипотез;
• снижает недопонимание между заказчиком и командой;
• позволяет согласовать видение без длинных текстовых описаний.

Минусы: риск «влюбиться» в прототип и начать защищать его, а не требования; высокая точность требует значительных трудозатрат.

№8 Анализ документации — независимый метод без участников

Анализ документации — единственный метод, где аналитик не взаимодействует со стейкхолдерами напрямую. Тип — независимый. Изучение документов даёт базу для подготовки к коллективным методам: из регламентов и спецификаций сразу видно, что уже задокументировано, а где — пробелы.

Источники:

• Внутренние: регламенты, инструкции, отчётность, спецификации продукта, описания бизнес-процессов;
• Внешние: ГОСТы, федеральные законы, отраслевые стандарты, лучшие практики, публичные кейсы.

Лучшая практика: запускать анализ документации первым, ещё до интервью. Это позволяет прийти на встречу с конкретными вопросами и заметить «забытые» требования, которые стейкхолдер не вспомнит устно.

Плюсы:

• не зависит от доступности участников;
• хорошая подготовка к следующим коллективным методам;
• выявляет устаревшие или противоречивые регламенты.

Минусы: документация может быть устаревшей или неполной; большой объём материалов требует значительного времени на обработку.

№9 Наблюдение: работа «в поле» и Гемба

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

Форматы:

• Теневое наблюдение — аналитик находится рядом с пользователем, молча фиксирует действия;
• Гемба (от яп. «реальное место») — посещение рабочего места сотрудника в реальных условиях;
• Удалённое — видеозапись рабочего процесса для последующего разбора.

Инструменты: диаграмма спагетти (карта перемещений по рабочему месту), датчики движения, видеозапись.

Плюсы:

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

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

№10 Варианты использования (Use Case) — структурный метод описания требований

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

Отличие от пользовательской истории (User Story): Use Case — полный сценарий со всеми основными и альтернативными путями, предусловиями и постусловиями. Пользовательская история — краткое описание потребности в формате «Как [роль], я хочу [действие], чтобы [цель]».

Кто использует: прежде всего системный аналитик на уровне FRQ; далее — архитектор, разработчики и специалист по контролю качества (QA-инженер). Для QA варианты использования становятся прямой основой для тест-кейсов.

Плюсы:

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

Минусы: не подходит для нефункциональных требований; трудоёмкое описание при большом количестве функций.

Как работают с требованиями бизнес-аналитик и системный аналитик

Оба специалиста задействуют техники выявления требований, но на разных уровнях иерархии. Бизнес-аналитик работает с бизнес-стороной — целями и потребностями; системный аналитик переводит их в техническую реализацию. Точка разделения — граница между пользовательскими и функциональными требованиями.

Бизнес-аналитик: методы на уровне BRQ и URQ

Зона ответственности бизнес-аналитика — бизнес-требования (BRQ) и пользовательские требования (URQ). Для их выявления BA применяет интервью, мозговой штурм, Event Storming, воркшоп и анализ документации. Стандарт профессии — BABOK 3.0; профессиональная сертификация — REQB. Артефакты на выходе: документ концепции и границ системы, документ пользовательских требований, которые затем передаются системному аналитику.

Системный аналитик: методы на уровне FRQ

Системный аналитик работает с функциональными требованиями (FRQ) и занимается анализом системных интерфейсов и интеграций. Основные техники выявления требований SA: Use Case, анализ интерфейсов и API, прототипирование, интервью с разработчиками и архитектором. Отличие от BA принципиальное: SA отвечает на вопрос «как система реализует потребность», BA — «что нужно бизнесу». Стейкхолдеры системного аналитика — архитектор, разработчики, QA-инженер.

Как выбрать методы сбора требований для своего проекта

По BABOK 3.0, ни один из путей выявления требований не является универсальным. Правильный подход — комбинация, подобранная под контекст: масштаб проекта, доступность стейкхолдеров, стадию жизненного цикла и тип требований — BRQ, URQ или FRQ.

Практический алгоритм для большинства проектов:

1. Анализ документации — база, с которой начинается любой сбор: регламенты, ГОСТы, спецификации;
2. Интервью — детальные беседы с ключевыми стейкхолдерами по приоритетным процессам;
3. Мозговой штурм или Event Storming — генерация идей и моделирование событий для сложных доменов;
4. Прототипирование — уточнение концепции через макеты, когда словами описать сложно;
5. Воркшоп — финальное согласование спорных требований с противоборствующими сторонами.

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

Системно освоить все способы выявления требований и сразу применить их в реальном учебном кейсе можно на программе «Системный аналитик: с нуля до проектирования систем» — она реализуется в рамках нацпроекта «Кадры», обучение для участников бесплатно.

Часто задаваемые вопросы

Что такое сбор требований в IT?

Итеративный процесс — Подготовка → Выявление → Утверждение, — в ходе которого бизнес-аналитик или системный аналитик получают от стейкхолдеров информацию о потребностях и ограничениях системы. По Ian Sommerville (1997), требования описывают поведение, свойства и атрибуты разрабатываемой системы. Тщательный сбор минимизирует риски и формирует чёткий базис для команды разработки.

Сколько методов сбора требований существует?

В профессиональной практике — 10–12 основных методов; стандарты REQB и BABOK 3.0 описывают около 30 техник. Делятся на коллективные (интервью, мозговой штурм, Event Storming) и независимые (анализ документации, наблюдение). Для большинства проектов достаточно комбинации из 3–5 методов.

Чем интервью отличается от анкетирования?

Интервью — живой диалог один на один, который выявляет скрытые требования и позволяет уточнять ответы в процессе; занимает не более часа. Анкетирование охватывает широкую аудиторию одновременно — анонимно и быстро, но задать уточняющий вопрос в процессе невозможно. Оптимальная схема: сначала интервью с ключевыми участниками, затем анкетирование для проверки гипотез у широкой группы.

Что такое Event Storming и когда применять?

Визуальная коллективная методика из Domain-Driven Design (DDD): разработчики и бизнес-эксперты совместно моделируют бизнес-события на стикерах офлайн или в Miro. Подходит для сложных доменов, новых систем и стартапов. Ключевое преимущество — объединяет IT и бизнес в одной сессии, позволяя быстро выстроить общую модель предметной области.

Что делать при конфликте требований разных стейкхолдеров?

Алгоритм: 1) провести воркшоп с ключевыми участниками для совместного обсуждения; 2) использовать анкетирование для выявления приоритетов широкой группы; 3) привлечь спонсора проекта для принятия финального решения. Результат зафиксировать в протоколе и направить участникам для письменного подтверждения.

Чем функциональные требования отличаются от нефункциональных?

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

Что такое «сбор требований путём модели ожидаемого продукта»?

Это прототипирование: пользователь видит макет системы — бумажный, цифровой или интерактивный — и формулирует требования относительно конкретного решения, а не абстрактного описания. Три уровня: бумага (быстро, бесплатно) → Miro/Balsamiq (средняя точность) → Figma/Proto.io (высокая точность). Применяется, когда словами сложно описать желаемый результат.

Как перейти от собранных требований к техническому заданию?

Алгоритм из шести шагов: 1) выявить стейкхолдеров → 2) провести сбор (интервью + документация + мозговой штурм) → 3) классифицировать по уровням: BRQ → URQ → FRQ + NFRQ → 4) разрешить конфликты через воркшоп → 5) утвердить с ответственными лицами → 6) консолидировать в SRS по стандарту ISO/IEC/IEEE 29148:2011. SRS и является основой для технического задания.

Что такое скрытые требования и как их выявить?

Потребности, которые стейкхолдеры не могут сформулировать словами, но критичны для системы. Выявляются через: наблюдение — метод Гемба фиксирует автоматизированные привычки пользователей; прототипирование — реакция на макет обнажает невысказанные ожидания; обучение у заказчика по принципу «учитель — ученик». Игнорирование скрытых требований — одна из частых причин провала IT-проектов.

Кто отвечает за сбор требований в Agile-проекте?

Ключевую роль играет представитель заказчика — владелец продукта (Product Owner), встроенный в команду разработки: обеспечивает быструю обратную связь и непрерывное уточнение требований. Бизнес-аналитик формализует и документирует; системный аналитик декомпозирует до функциональных требований. Основные коллективные методы в Agile — планирование спринта, ретроспективы и воркшопы.