Сбор и анализ требований: как не упустить важное
Требования — это фундамент IT-проекта. Если они собраны неполно или неточно, весь проект рискует провалиться. Собрать все требования — искусство, которому нужно учиться.
В этой статье — как правильно собирать требования, какие техники использовать, как не упустить важное. Если хотите передать сбор требований нам — обращайтесь.
Виды требований
Требования делятся на несколько категорий:
Бизнес-требования
Описывают цели бизнеса: что хочет достичь компания. Формулируются на языке бизнеса, без технических деталей.
Пример: «Увеличить продажи на 20% через автоматизацию обработки заказов».
Пользовательские требования
Описывают, что нужно пользователям системы. Часто формулируются как сценарии использования или user stories.
Пример: «Менеджер должен иметь возможность создать заказ за 1 минуту».
Функциональные требования
Описывают, что система должна делать: функции, операции, действия.
Пример: «Система должна отправлять email-уведомление клиенту после оформления заказа».
Нефункциональные требования
Описывают, КАК система должна работать: производительность, безопасность, масштабируемость, удобство.
Пример: «Время загрузки страницы не должно превышать 2 секунды».
Источники требований
Откуда берутся требования:
- Заказчик: бизнес-цели, ожидания, ограничения;
- Пользователи: как они работают сейчас, что хотят улучшить;
- Документация: существующие регламенты, инструкции, ТЗ;
- Существующие системы: как работают текущие решения;
- Конкуренты: что делают аналогичные продукты;
- Законодательство: требования нормативов (152-ФЗ, ГОСТ);
- Технические ограничения: что возможно на выбранном стеке;
- Аналитика: данные о поведении пользователей.
Техники сбора требований
1. Интервью
Личная беседа с одним или несколькими стейкхолдерами. Позволяет глубоко разобраться в задаче.
Плюсы: глубина, можно уточнить на ходу. Минусы: трудоёмко, зависит от навыков интервьюера.
2. Воркшопы
Групповая работа, где все стейкхолдеры вместе обсуждают задачу и договариваются.
Плюсы: согласование в реальном времени. Минусы: сложно организовать, могут быть конфликты.
3. Анкетирование
Письменные опросы для большого числа пользователей.
Плюсы: охват. Минусы: поверхностно, нельзя уточнить.
4. Наблюдение
Наблюдение за тем, как пользователи работают с системой.
Плюсы: реальная картина, можно увидеть боли. Минусы: трудоёмко.
5. Анализ документов
Изучение существующей документации, регламентов, инструкций.
Плюсы: быстро, если документы есть. Минусы: документы могут устареть.
6. Прототипирование
Создание прототипов интерфейса для уточнения требований.
Плюсы: наглядно, быстро уточняются детали. Минусы: требует времени.
Анализ требований
После сбора требований их нужно проанализировать. Что важно проверить:
- Полнота: все ли функции описаны? Нет ли пропусков?
- Непротиворечивость: нет ли требований, которые противоречат друг другу?
- Однозначность: можно ли понять требование только одним способом?
- Реализуемость: технически возможно ли это реализовать?
- Приоритет: что важно, что можно отложить?
- Проверяемость: можно ли проверить, выполнено ли требование?
- Трассируемость: можно ли связать требование с бизнес-целью?
Если требование не проходит хотя бы по одному из пунктов — его нужно доработать.
Приоритизация требований
Когда требований много, их нужно приоритизировать. Самый популярный метод — MoSCoW:
Must have
Обязательные требования. Без них проект не имеет смысла
Should have
Важные, но не критичные. Можно отложить на следующую версию
Could have
Желательные. Приятные бонусы, если есть время и бюджет
Won't have
Не будем делать в этой версии. Возможно, в будущем
💡 Важно
Если все требования «Must have» — значит, приоритизация не сделана. В любом проекте есть требования, которые можно отложить. Это нормально и позволяет уложиться в бюджет.
Типичные ошибки при сборе требований
1. Не учли всех стейкхолдеров
Забыли про какого-то пользователя или отдел. Потом выясняется, что для них система не подходит.
2. Собирали требования только с заказчика
Заказчик не знает всех деталей работы. Нужно общаться с реальными пользователями.
3. Размытые формулировки
«Удобный интерфейс», «быстрый поиск» — что это значит? Нужны конкретные метрики и критерии.
4. Не приоритизировали
Все требования «важные». В итоге проект раздувается, бюджет превышается, сроки срываются.
5. Пропустили нефункциональные требования
Производительность, безопасность, масштабируемость — это тоже важно. Их часто забывают.
6. Не проверили требования
Собрали и сразу передали в разработку, не проверив на противоречия и полноту.
7. Не документировали
«Мы всё обсудили в чате» — потом никто не может вспомнить, о чём договорились.
8. Не учли ограничения
Технические, бюджетные, временные. Потом выясняется, что требование невозможно реализовать.
Наши рекомендации
Как мы собираем требования
- Интервью с заказчиком: понимаем бизнес-цели и ожидания;
- Воркшопы с пользователями: обсуждаем реальные сценарии работы;
- Анализ документации: изучаем существующие регламенты;
- Прототипирование: показываем будущий интерфейс для уточнения;
- Проверка требований: на полноту, непротиворечивость, реализуемость;
- Приоритизация: MoSCoW — что критично, что можно отложить.
📌 Итоговый вывод
Сбор требований — ключевой этап IT-проекта, от которого зависит его успех.
Что нужно знать:
- Виды требований: бизнес, пользовательские, функциональные, нефункциональные;
- Источники: заказчик, пользователи, документация, аналитика, ограничения;
- Техники: интервью, воркшопы, анкеты, наблюдение, документы, прототипы;
- Анализ: полнота, непротиворечивость, однозначность, реализуемость;
- Приоритизация: MoSCoW — Must, Should, Could, Won't;
- Ошибки: неучтённые стейкхолдеры, размытые формулировки, отсутствие приоритетов.
Также рекомендуем: что такое бизнес-анализ, BPMN-моделирование, методы анализа, документация, ошибки, все статьи о бизнес-анализе.