Когда я был джуном, все эти типы требований казались мне бюрократией. В вузе нас учили писать их по ГОСТам — после такого сложно поверить, что требования могут быть полезными. Всё изменилось, когда я начал работать с дизайнером: мы долго не могли найти общий подход, пока не поняли, что ему нужны расписанные use case'ы — без них он проектировал интерфейс вслепую. Так функциональные требования перестали быть для меня формальностью.
Структура функционального требования
В каждом артефакте я стараюсь держать структуру минимальной. У Стива Круга в «Не заставляйте меня думать» есть мысль: если что-то является коротким, у него больше шансов быть использованным. Он говорил про интерфейсы, но к документации это применимо один в один.
Моя структура функционального требования:
Ссылка на пользовательское требование
Связь с критериями приёмки
Описание
Логика (Use Case)
Связанные требования (бизнес-правила, требования к данным, системным интерфейсам, графическим интерфейсам)
Use Case
Сердце функционального требования — логика использования фичи. У одного функционала может быть много сценариев, часть из которых фиксируется в критериях приёмки.
Каждое функциональное требование содержит ровно один use case. Я описываю, с чего начинает пользователь, к какой цели он идёт и чего достигает. Признак хорошего use case — его легко превратить в блок-схему или BPMN-диаграмму.
Разберу на реальном примере. На одном из проектов мы разрабатывали календарь курсов — страницу, где пользователь подбирает курс и записывается на него.
Пользователь заходит на портал
Цель — записаться на курс
Переходит на страницу «Календарь курсов»
Задаёт нужные фильтры
ЕСЛИ подходящих курсов не нашлось — отображается пустой календарь
Выбирает курс на подходящие даты
Кликает на курс и попадает на его страницу
Нажимает «Записаться»
Заполняет заявку и отправляет
Служба поддержки связывается с пользователем и принимает заявку
Пользователь записан на курс
Я специально не стал раскрывать пункт «Описание» раньше — это выжимка use case'а в одно-два предложения. Нужно, чтобы быстро ориентироваться в документации, не вчитываясь в логику целиком. Для нашего примера:
Требование описывает логику записи на курс пользователем при использовании календаря курсов
На том же проекте с дизайнером мы начали тестировать интерфейс на реальных пользователях, чтобы лучше понимать их приоритеты и мысли. Заказчик считал это пустой тратой времени — пока после пары сессий не убедился, что это действительно важно для сотрудников.
Кажется, что при описании use case'а ты покрываешь все сценарии. Но в ходе тестирования мы увидели, что пользователь вместо яркой кнопки кликает на меню слева. Каждый такой сценарий — это новое функциональное требование.
Тест-кейсы из use case'ов
Я спросил тестировщика в команде, как он работает с функциональными требованиями. Ответ был простой: он берёт логику из use case'а и формирует из неё шаги и ожидаемый результат для тест-кейсов. Не только из ФТ — но ФТ помогает.
К нефункциональным требованиям он тоже обращается и старается проверять их по возможности.
Трассируемость
Функциональные требования не висят в воздухе. Вверх они связаны с пользовательским требованием через критерии приёмки. Вниз — с требованиями к данным, системным интерфейсам и графическим интерфейсам, которые описывают реализацию.
Я придерживаюсь двух правил:
Каждое функциональное требование должно покрывать один или несколько критериев приёмки. Каждый критерий приёмки может быть покрыт одним или несколькими функциональными требованиями
Требования к данным, системным интерфейсам и графическим интерфейсам должны быть связаны с функциональными требованиями. Но не наоборот — ФТ не обязано иметь связанные ТД, СИ или ГИ
Вернёмся к примеру с календарём курсов. Критерии приёмки могут выглядеть так:
Дано | Когда | Тогда | |
|---|---|---|---|
КП-1 | Пользователь выбирает параметры в фильтрах | Есть подходящие курсы | Система отображает курсы |
КП-2 | Пользователь на странице Календаря курсов | Кликает на курс | Система отображает страницу курса |
Оба критерия покрываются нашим функциональным требованием. Это не все КП, которые оно покрывает, но для примера достаточно. Уточнение: те же критерии могут покрываться и другими ФТ.
«Нижняя» трассировка важна для документации: по ней видно, что задачи действительно покрывают весь функционал. И наоборот — что не появилось лишних задач, не связанных с фичей.
Добавим в наш пример нижние требования. ФТ может быть связано сразу с тремя типами, а может — ни с одним:
[СИ-5] GET /courses — получение информации по доступным курсам и датам их проведения
[ГИ-3] Отображение курсов в календаре
[ТД-2] Добавление временных промежутков проведения курсов
[ТД-3] Миграция данных курсов
Когда у ФТ нет связанных требований? Например, когда нужно зафиксировать существующее поведение системы. В нашем кейсе страница со списком курсов уже существовала — календарь лишь новое представление. Старый список никуда не девается, мы добавляем вид, а не заменяем. Новых запросов, изменений данных и правок интерфейса не требуется — но ФТ на это всё равно нужно.
Отдельно в функциональном требовании я указываю связанные бизнес-правила. Подробно о них я писал в статье — здесь лишь отмечу, что они живут в пользовательском требовании, а в ФТ только ссылаются.
Шаблон функционального требования
# [ФТ-XX] Название функционального требования > **Пользовательское требование:** ПТ-XX > > **Критерии приёмки:** КП-X, КП-X ## Описание Краткое описание сути требования в 1-2 предложениях. ### Логика 1. Шаг 2. Шаг 3. **Если** условие → результат 4. **Если** иное условие → результат ## Бизнес-правила * БП-XX ## Связанные требования ### Требования к данным * ТД-XX ### Требования к интерфейсам * СИ-XX * ГИ-XX
Как выглядит на практике
[ФТ-1] Запись на курс через календарь курсов
Пользовательское требование: ПТ-1
Критерии приёмки: КП-1, КП-2
Описание
Требование описывает логику записи на курс пользователем при использовании календаря курсов.
Логика
Пользователь заходит на портал
Цель — записаться на курс
Переходит на страницу «Календарь курсов»
Задаёт нужные фильтры
Если подходящих курсов не нашлось — отображается пустой календарь
Выбирает курс на подходящие даты
Кликает на курс и попадает на его страницу
Нажимает «Записаться»
Заполняет заявку и отправляет
Служба поддержки связывается с пользователем и принимает заявку
Пользователь записан на курс
Бизнес-правила
—
Связанные требования
Требования к данным
Требования к интерфейсам
Нефункциональное требование
Большинство нефункциональных требований при разработке документации — вещи, которые подразумеваются по умолчанию. Понятно, что действия доступны только определённым ролям, что эндпоинт отрабатывает за разумное время, а миграция данных выполняется в одной транзакции.
Поэтому я фиксирую только то, что критично для конкретной фичи. В случае с календарём курсов не так важна надёжность, как скорость загрузки и удобство: в один день может быть семьдесят и больше курсов — нужно отобразить все, не перегрузив интерфейс.
Структура НФТ у меня проще, чем у функционального требования.
Шаблон нефункционального требования
# [НФТ-XX] Название нефункционального требования > **Пользовательское требование:** ПТ-XX ## Категория Категория НФТ (например: Производительность, Надёжность, Удобство использования) ### Метрика и целевые значения * **Метрика:** Что измеряем * **Целевое значение:** Конкретное значение или условие ## Обоснование Почему это требование важно для фичи.
Как выглядит на практике
[НФТ-1] Календарь курсов должен оставаться читаемым при большом количестве курсов в один день
Пользовательское требование: ПТ-1
Категория
Удобство использования
Метрика и целевые значения
Метрика: Читаемость календаря при максимальной загрузке
Целевое значение: При отображении 70+ курсов в один день календарь остаётся читаемым и помещается максимум в 2 экрана
Обоснование
В каталоге бывают дни с 70+ курсами. Без ограничений на отображение пользователь вынужден скроллить длинный список, теряя контекст дат и рискуя пропустить подходящий курс.
Итог
Структура документации — не статичная штука. Она развивается вместе с командой и её потребностями. Моя структура ФТ сейчас закрывает запросы тестировщика, дизайнера и разработчиков — но через полгода всё может измениться.
Для чего ваша команда использует функциональные требования? Являются ли они формальностью или действительно рабочим инструментом?
