Привет, друзья! 👋 Часто бывает так: заказчик говорит «сделайте красиво», аналитик пишет «должно работать», а разработчик потом три ночи не спит, пытаясь угадать, что же имелось в виду. Знакомая ситуация?
Чтобы такого не было, существуют Функциональные требования (ФТ). Это не просто скучный документ, а настоящая конституция вашего будущего продукта. 🇷🇺
Сегодня разберем, что обязательно должно быть в этом документе, чтобы команда работала как часы, а результат радовал всех. Погнали! 🚀
1. Контекст и действующие лица 🎭
Прежде чем писать, что система делает, объясните, кто ей будет пользоваться и при каких обстоятельствах.
- Акторы (роли): Кто взаимодействует с системой? (Например: «Авторизованный пользователь», «Администратор», «Гость»).
- Предусловия: Что должно случиться до начала? («Пользователь открыл приложение», «Админ вошел в панель управления»).
- Триггер: С чего все началось? («Юзер нажал кнопку "Купить"»).
2. Детальное описание поведения (Логика) 🧠
Это сердце документа. Пишите так, как будто объясняете роботу, который никогда не видел, как люди заказывают пиццу.
- Сценарии:
Основной сценарий (Happy Path): «Если все хорошо, то шаг 1 -> шаг 2 -> шаг 3». (Например: выбрал товар -> ввел адрес -> оплатил -> получил чек).
Альтернативный сценарий: «Если пользователь VIP, то предложить скидку».
Исключения (что, если...): «Если денег на карте нет, показать ошибку с кодом 402 и предложить другую карту».
3. Входные и выходные данные 📥📤
Система что-то принимает и что-то отдает. Это нужно описать предельно четко.
- Что входит (Input):
Поля ввода (с типами данных: число, строка, дата).
Загружаемые файлы (форматы: только .jpg или .pdf?).
Нажатия кнопок. - Что выходит (Output):
Что видит пользователь (изменился ли цвет кнопки? появилось ли всплывающее окно?).
Что система отправляет ему на почту.
Данные, которые уходят в базу данных.
4. Требования к интерфейсам (UI) 🎨
Функциональные требования тесно связаны с дизайном.
- Привязка к макетам: Ссылайтесь на конкретные экраны в Figma. («После шага 2 пользователь видит экран, как на макете "Корзина_02"»).
- Динамика: Опишите, что происходит с элементами интерфейса. («Если поле заполнено неверно, рамка становится красной и появляется иконка ⚠️»).
5. Правила и ограничения 🚧
Здесь живут математика и логика, которую нельзя нарушать.
- Бизнес-логика: «Нельзя купить товар, если на складе осталось 0 штук».
- Расчеты: «Итоговая цена = Цена товара + 20% НДС — Скидка».
- Лимиты: «В одном заказе не может быть больше 99 позиций».
6. Требования к интеграциям 🔌
Если ваша система разговаривает с внешним миром (банками, соцсетями, CRM), это отдельная песня.
- С кем связь: «Платежная система CloudPayments».
- Протокол: REST API, SOAP и т.д.
- Данные для обмена: Какие именно поля и в каком формате мы отправляем и получаем обратно.
❌ Чего писать НЕ НАДО
- Технические детали: «Использовать базу данных MySQL». (Это к архитектору системы).
- Дизайн-решения: «Кнопка должна быть круглой и переливаться». (Это к дизайнеру).
- Сроки: «Сделать до пятницы». (Это к проект-менеджеру).
Итог: Что получаем на выходе? 🏁
Хорошее функциональное требование — это ответ на вопрос: «Что должно произойти с системой и с пользователем, когда он совершит конкретное действие?»
Если, прочитав ваше требование, разработчик сразу понял, сколько времени займет задача, а тестировщик — где искать баги, — вы написали гениально! 💪
А у вас в компании пишут требования или всё делается «на словах»? Делитесь в комментариях! 👇
#аналитика #разработка #IT #бизнес #управление
Подпишись https://t.me/analist_analist_analist