Требование это зафиксированная потребность, которую должно удовлетворить решение. Требования бывают разного уровня, и путаница уровней одна из главных причин провалов: команда делает функции, но бизнес-цель не достигается.
Уровни требований
По BABOK:
- Бизнес-требования: зачем организации изменение. Цели, задачи, ожидаемые результаты. «Сократить срок рассмотрения заявки с 5 до 2 дней к концу года».
- Требования стейкхолдеров: что нужно конкретной группе, чтобы цель была достигнута. «Кредитному специалисту нужно видеть кредитную историю клиента без запроса в другой отдел».
- Требования к решению:
- функциональные: что система или процесс делает («система автоматически запрашивает кредитную историю при создании заявки»);
- нефункциональные: с каким качеством (скорость, доступность, безопасность, удобство).
- Переходные требования: временные, на период перехода. Миграция данных, обучение, параллельная работа.
В классификации Вигерса (популярна в РФ) похоже: бизнес-требования, пользовательские, функциональные плюс нефункциональные и бизнес-правила.
Бизнес-цели по SMART
Цель без цифры не проверить. SMART:
- S (Specific): конкретно, что меняем;
- M (Measurable): метрика и значение;
- A (Achievable): достижимо;
- R (Relevant): связано со стратегией;
- T (Time-bound): срок.
Плохо: «Повысить удовлетворённость клиентов». Хорошо: «Поднять CSAT поддержки с 3,9 до 4,3 к 1 июля, при той же численности операторов».
Ценность
Ценность это польза для стейкхолдера относительно затрат. Источники ценности для бизнеса обычно такие: рост выручки, снижение затрат, снижение рисков (штрафы, потери), соответствие требованиям закона, улучшение клиентского опыта. Если для требования нельзя назвать ценность, это сигнал спросить, зачем оно.
Бизнес-правила
Правило это политика или ограничение бизнеса, которое не зависит от системы: «Скидка больше 15% требует согласования руководителя», «Возврат возможен в течение 14 дней». Правила выносят отдельно: они меняются чаще, чем функции, и на них ссылается много требований.
Свойства хорошего требования
Однозначное, проверяемое, необходимое (связано с целью), реализуемое, непротиворечивое, атомарное (одно требование, а не три через «и»), трассируемое.
Слова-маркеры плохих требований: «удобный», «быстрый», «при необходимости», «и т.д.», «как минимум», «оптимальный».
Трассировка
Трассировка связывает требования между уровнями и с артефактами: бизнес-цель → требование стейкхолдера → функциональное требование → задача, тест-кейс. Зачем:
- видно, что каждая цель покрыта, а каждое требование нужно (нет висящих «хотелок»);
- при изменении цели понятно, какие требования и тесты затронуты (анализ влияния);
- для регулируемых отраслей это доказательство для аудита.
Ведут в матрице трассировки (таблица) или связями в Jira/Confluence. Важно не превратить трассировку в бюрократию: детализацию выбирают по рискам проекта.
Верификация и валидация
- Верификация: требование записано правильно (однозначно, полно, проверяемо). «Правильно ли мы описали?»
- Валидация: требование действительно ведёт к цели и нужно стейкхолдеру. «То ли мы описали?»
Частые ошибки
- Цель без метрики и срока.
- Требования к решению без связи с бизнес-целью.
- Бизнес-правила, зашитые в текст функций.
- Неизмеримые слова.
- Трассировка, которую никто не обновляет.
Что спросят на собесе
- Какие уровни требований существуют, примеры каждого.
- Чем бизнес-требование отличается от функционального.
- Что такое SMART, переформулируйте плохую цель.
- Что такое трассировка и зачем она нужна.
- Чем верификация отличается от валидации.