Требование: условие или возможность, которой должна обладать система, чтобы решить задачу пользователя или бизнеса. Самая частая классификация на собесе: функциональные и нефункциональные.
Уровни требований (по Вигерсу)
- Бизнес-требования: зачем проект. «Сократить время обработки заявки с 2 дней до 4 часов».
- Пользовательские требования: что пользователь сможет делать. «Менеджер видит все заявки своего региона».
- Функциональные требования: что делает система. «Система фильтрует список заявок по региону менеджера».
Рядом стоят нефункциональные требования и ограничения (технологии, законы, бюджет).
Функциональные (FR)
Описывают поведение: что система делает в ответ на действия и события.
- Система отправляет клиенту SMS с кодом подтверждения при входе.
- Система не даёт оформить заказ при сумме меньше 500 рублей.
- Администратор может заблокировать пользователя.
Нефункциональные (NFR)
Описывают, насколько хорошо система это делает. Удобно держать в голове ISO/IEC 25010 (модель качества продукта):
| Атрибут | Пример требования |
|---|---|
| Производительность | 95% запросов поиска отвечают быстрее 300 мс при 200 RPS |
| Надёжность и доступность | доступность 99,9% в месяц, RPO 15 минут, RTO 1 час |
| Безопасность | пароли хранятся только как хеш, доступ к карточке клиента логируется |
| Удобство использования | новый оператор оформляет заявку без обучения за 3 минуты |
| Сопровождаемость | логи в JSON, трассировка запросов по correlation id |
| Переносимость и совместимость | работает в последних двух версиях Chrome, Safari, Яндекс Браузера |
| Масштабируемость | рост нагрузки в 3 раза без переписывания |
NFR без числа и условия измерения бесполезны. «Система должна быть быстрой» проверить нельзя, «95-й перцентиль ответа API заказов не более 500 мс при 100 RPS» можно.
Свойства хорошего требования
- Однозначное: одна трактовка. «Быстро», «удобно», «и т. д.», «по возможности» запрещены.
- Проверяемое: можно написать тест.
- Атомарное: одно требование, одна мысль, без «и» на две функции.
- Полное: есть исключения и граничные случаи.
- Непротиворечивое: не спорит с другими.
- Трассируемое: известно, откуда оно (бизнес-цель, закон) и где реализовано.
- Реализуемое: возможно в рамках сроков и технологий.
Часто это сводят к ISO/IEC/IEEE 29148, где перечислены эти характеристики.
Как переписать плохое требование
Плохо: «Система должна быстро загружать отчёт и выгружать его в удобном формате».
Хорошо:
- FR-12. Пользователь с ролью «Финансист» выгружает отчёт «Платежи за период» в XLSX.
- NFR-5. Формирование отчёта за месяц (до 100 000 строк) занимает не более 10 секунд.
Трассировка
Матрица трассировки связывает бизнес-цель → требование → user story → тест. Нужна, чтобы ответить на вопросы «зачем эта функция?» и «что сломается, если поменять требование?».
Частые ошибки
- Забыть NFR, и узнать о нагрузке на проде.
- Писать решение («сделать кнопку») вместо требования («пользователь может отменить заказ до сборки»).
- Смешивать в одном пункте несколько требований.
- Не согласовать NFR с эксплуатацией и безопасностью.
Что спросят на собесе
- Чем функциональное требование отличается от нефункционального? Приведи примеры.
- Как сформулировать проверяемое требование к производительности?
- Какие свойства у хорошего требования?
- Что такое матрица трассировки и зачем она?
- Как ты выявляешь NFR, если заказчик о них не говорит?