Какие виды требований кроме бизнес-требований существуют
Что проверяют
Понимаете ли вы, откуда берутся задачи и как фронтендер влияет на требования, а не только получает макет. Следом обычно спрашивают, как проверить нефункциональное требование и кто его формулирует.
Как отвечать
Удобно опереться на классификацию Вигерса, где бизнес-требования это верхний уровень, ответ на вопрос «зачем продукт бизнесу». Под ними:
- пользовательские: что человек должен сделать в системе, в виде user story или сценария использования;
- функциональные: конкретное поведение интерфейса. Форма показывает ошибку под полем после потери фокуса, фильтр сохраняется в URL;
- нефункциональные (атрибуты качества): скорость, доступность, безопасность, совместимость, локализация;
- бизнес-правила: логика предметной области вне конкретного экрана, например скидка не суммируется с промокодом;
- ограничения: решения, которые заданы заранее: стек, поддерживаемые браузеры, сроки, закон о персональных данных;
- внешние интерфейсы: контракт с API, форматы данных, интеграции.
Для фронтенда главное показать, что нефункциональные требования измеримы:
- производительность: Core Web Vitals на 75-м перцентиле, LCP до 2,5 с, INP до 200 мс, CLS до 0,1, плюс бюджет на размер бандла в CI;
- доступность: уровень WCAG 2.2 AA, работа с клавиатуры, контраст, подписи для скринридеров;
- совместимость: список браузеров в
browserslist, минимальная ширина экрана; - безопасность: CSP, защита от XSS, место хранения токена.
Где спотыкаются
Называют только «функциональные и нефункциональные» и останавливаются. Ограничения и бизнес-правила выпадают, а именно они чаще всего ломают сроки.
Формулируют требование без критерия: «сайт должен быть быстрым». Такое нельзя проверить, и спор о готовности задачи становится спором вкусов.
Считают доступность и поддержку браузеров делом дизайнера. Если требование не записано до начала работы, его потом встраивают в готовые компоненты, и это обходится дороже всего.