Функциональные требования

От желаний к действиям

Представьте, что вы пришли в кафе и сказали официанту: “Я хочу поесть”. Это ваше пользовательское требование. Официант кивнул и ушел. Вернется ли он с едой? Скорее всего, нет, потому что вы не сказали ничего конкретного.

Теперь представьте другой сценарий. Вы говорите: “Я хочу съесть тарелку горячего борща с мясом и сметаной, чтобы согреться и наесться”. Это все еще пользовательское требование – есть роль (я), действие (съесть борщ) и ценность (согреться и наесться).

Но официанту этого мало. Ему нужно передать задачу на кухню. И тут начинаются функциональные требования:

• Повар должен взять кастрюлю с бульоном.
• Повар должен налить бульон в тарелку объемом 300 мл.
• Повар должен добавить 100 грамм вареного мяса.
• Повар должен добавить ложку сметаны.
• Повар должен проверить температуру - борщ должен быть горячим (не менее 60 градусов).
• Официант должен принести тарелку в течение 10 минут.

Вот это уже похоже на функциональные требования – четкие, конкретные, проверяемые указания, что должна сделать система (или повар).

Функциональные требования – это описание конкретного поведения системы, ее функций и реакций на действия пользователя. Они отвечают на вопрос “ЧТО КОНКРЕТНО должна делать система?”.

Что такое функциональные требования (ФТ/FR)

Функциональные требования – это детализация пользовательских требований до уровня, понятного разработчику. Если пользовательское требование говорит “что хочет пользователь”, то функциональное говорит “что должна сделать система, чтобы пользователь это получил”.

Основные признаки функциональных требований:

• Они описывают поведение системы.
• Они обычно начинаются с глагола: “система должна отправить”, “система должна рассчитать”, “система должна отобразить”.
• Они конкретны и не допускают двойного толкования.
• Их можно проверить – выполняется требование или нет.

Плохой пример функционального требования: “Система должна быстро обрабатывать заказы”. (Что значит “быстро”? Как проверить?)

Хороший пример: “Система должна обрабатывать заказ от момента нажатия кнопки “Оформить” до присвоения номера заказа не дольше 2 секунд”. (Конкретно, измеримо, проверяемо.)

Из чего состоят функциональные требования

Хорошее функциональное требование должно содержать несколько ключевых элементов.

Действие (Action)

Что именно делает система. Всегда глагол.

Примеры: сохраняет, отправляет, рассчитывает, отображает, проверяет.

Объект (Object)

Над чем или с чем производится действие.

Примеры: заказ, пользователь, отчет, платеж, файл.

Условие (Condition)

При каких обстоятельствах действие выполняется.

Примеры: “Если сумма заказа больше 5000 рублей…”, “После успешной авторизации…”, “При отсутствии товара на складе…”.

Результат (Result)

Что получается в итоге.

Примеры: “номер заказа присваивается”, “письмо отправляется”, “ошибка выводится на экран”.

Полный пример: “Система должна отправлять письмо с подтверждением на email пользователя после того, как заказ получил статус “Оплачен””.

Уровни детализации функциональных требований

Функциональные требования можно писать с разной степенью детализации. Это зависит от методологии проекта и стадии разработки.

Крупные функции (Features)

Это крупные блоки функциональности. Обычно их используют для планирования релизов и дорожных карт.

Примеры:

• “Регистрация и авторизация пользователей”.
• “Каталог товаров с поиском и фильтрацией”.
• “Корзина и оформление заказа”.
• “Личный кабинет покупателя”.

Детальные требования (Detailed Requirements)

Это уже конкретные указания для разработчика. Обычно они группируются внутри крупных функций.

Пример детализации для функции “Регистрация пользователей”:

1. Система должна предоставлять форму регистрации с полями: Имя, Email, Пароль, Подтверждение пароля.
2. Система должна проверять, что email не зарегистрирован ранее.
3. Система должна проверять, что пароль содержит не менее 8 символов, включая цифры и буквы.
4. Система должна проверять, что пароль и подтверждение пароля совпадают.
5. При успешной регистрации система должна отправлять приветственное письмо на указанный email.
6. При ошибках валидации система должна подсвечивать проблемные поля и показывать понятные сообщения об ошибке.

Откуда берутся функциональные требования

Пользовательские требования (User Stories / Use Cases)

Это основной источник. Вы берете пользовательскую историю и раскладываете ее на конкретные функции.

• User Story: “Как покупатель, я хочу восстановить пароль, если забыл его”.
• Функциональные требования:
  • Система должна отображать ссылку “Забыли пароль?” на форме входа.
  • При клике на ссылку система должна открывать форму ввода email.
  • Система должна проверять, что email есть в базе.
  • Система должна генерировать уникальную ссылку для сброса пароля.
  • Система должна отправлять эту ссылку на email пользователя.
  • Ссылка должна действовать 24 часа.

Бизнес-правила

Иногда функциональные требования напрямую вытекают из бизнес-правил.

• Бизнес-правило: “При сумме заказа более 5000 рублей доставка бесплатна”.
• Функциональные требования:
  • Система должна рассчитывать сумму заказа.
  • Если сумма заказа больше или равна 5000 рублей, система должна устанавливать стоимость доставки = 0.
  • Если сумма меньше 5000, система должна рассчитывать доставку по тарифу 300 рублей.

Законодательные и регуляторные требования

То, что требует закон.

• Закон: “Персональные данные должны храниться с соблюдением требований безопасности”.
• Функциональные требования:
  • Пароли пользователей должны храниться в базе в захэшированном виде.
  • Доступ к персональным данным должен логироваться.
  • Пользователь должен давать согласие на обработку персональных данных (чекбокс).

Анализ существующих систем

Если вы дорабатываете старую систему, смотрите, как там сделано. Что нужно изменить? Что добавить?

Мозговые штурмы с командой

Разработчики и тестировщики часто подсвечивают технические нюансы, которые заказчик мог не учесть.

Пример: Цепочка от бизнеса до функциональности

Давайте проследим полный путь от бизнес-требования до конкретных функций, чтобы увидеть картину целиком.

Уровень 1: Бизнес-требование

“Увеличить повторные продажи на 15% за счет удержания существующих клиентов”.

Уровень 2: Пользовательские требования

• “Как покупатель, я хочу получать персональные скидки, чтобы чувствовать, что меня ценят”.
• “Как покупатель, я хочу видеть историю своих заказов, чтобы легко повторить понравившийся заказ”.
• “Как маркетолог, я хочу отправлять письма с персональными предложениями, чтобы стимулировать повторные покупки”.

Уровень 3: Функциональные требования (фрагмент)

Для истории заказов:

1. В личном кабинете система должна отображать вкладку “История заказов”.
2. История должна отображать список всех заказов пользователя за все время.
3. Для каждого заказа должны показываться: дата, сумма, статус, список товаров.
4. Рядом с каждым заказом должна быть кнопка “Повторить заказ”.
5. При нажатии на “Повторить заказ” система должна добавлять все товары из того заказа в текущую корзину.

Для персональных скидок:

1. Система должна рассчитывать сумму всех покупок пользователя за последние 6 месяцев.
2. Если сумма больше 10 000 рублей, система должна присваивать пользователю статус “Постоянный клиент”.
3. Для статуса “Постоянный клиент” система должна автоматически применять скидку 5% ко всем заказам.
4. При оформлении заказа система должна отображать сообщение: “Вам предоставлена персональная скидка 5% как постоянному клиенту”.

Для email-рассылок:

1. Система должна отправлять письма с персональными предложениями раз в месяц.
2. Письмо должно формироваться автоматически на основе истории покупок пользователя.
3. В письме должны быть товары, похожие на те, что пользователь уже покупал.
4. Письмо должно содержать персональную ссылку на каталог с уже примененной скидкой.

Видите, как из абстрактного “увеличить продажи” выросли конкретные “кнопки”, “расчеты” и “письма”. Это и есть работа аналитика.

Как документировать функциональные требования

Способов много, выбор зависит от методологии и принятых в команде стандартов.

Вариант 1: Спецификация (SRS - Software Requirements Specification)

Классический подход, часто используется в Waterfall. Большой документ, где требования описаны структурированно, обычно по разделам.

Пример структуры:

1. Введение
2. Общее описание
3. Функциональные требования 3.1. Модуль регистрации 3.2. Модуль каталога 3.3. Модуль корзины 3.4. Модуль оплаты
4. Нефункциональные требования
5. Приложения

Вариант 2: User Story + Acceptance Criteria (Критерии приемки)

Подход Agile. В задаче (например, в Jira) написана User Story, а в комментариях или специальном поле - Acceptance Criteria, которые по сути и есть функциональные требования.

Пример задачи в Jira:

• Заголовок (User Story): Как покупатель, я хочу восстановить пароль, если забыл его.
• Acceptance Criteria:
  • На форме входа есть ссылка “Забыли пароль?”.
  • При клике открывается форма ввода email.
  • Если email есть в базе, система отправляет письмо со ссылкой для сброса.
  • Если email нет в базе, система показывает сообщение “Пользователь с таким email не найден”.
  • Ссылка для сброса действует 24 часа.
  • После перехода по ссылке открывается форма ввода нового пароля.

Вариант 3: Use Case + Flow (Сценарий использования + Поток событий)

Подходит для сложной логики с множеством ветвлений. Описывается основной сценарий и альтернативные потоки.

Вариант 4: Прототипы с аннотациями

Иногда проще нарисовать экран и подписать стрелочками, что должно происходить при клике на каждый элемент.

Типичные ошибки

Ошибка 1: Слишком общие формулировки

“Система должна быть удобной”. Это не функциональное требование. Функциональное требование: “Система должна запоминать последние 5 поисковых запросов пользователя и отображать их при клике в строку поиска”.

Ошибка 2: Описывать реализацию, а не поведение

“Система должна использовать базу данных PostgreSQL”. Это не функциональное, а скорее технологическое ограничение. Функциональное требование - что система делает, а не на чем это написано.

Ошибка 3: Забывать про альтернативные сценарии

Новички часто описывают только “счастливый путь” (happy path), когда все идет хорошо. А что будет, если пользователь ввел неправильные данные? Если сервер не отвечает? Если товара нет на складе?

Ошибка 4: Не проверяемость

Написали требование, а как проверить, выполнено оно или нет, непонятно. Критерий: если тестировщик не может написать тест-кейс на основе вашего требования - требование плохое.

Ошибка 5: Смешивать с пользовательскими требованиями

Писать “Пользователь хочет” внутри функциональных требований. Функциональное требование пишется от лица системы: “Система должна…”.

Резюме для системного аналитика

1. Функциональные требования – это “что делает система”. Это самый детальный уровень, по которому разработчик пишет код, а тестировщик проверяет результат.

2. Они вырастают из пользовательских требований. Сначала узнали, чего хочет пользователь, потом расписали, что система должна сделать.

3. Главные качества: конкретность и проверяемость. Если требование можно понять по-разному или нельзя проверить – оно плохое.

4. Не забывайте про исключения. Жизнь не состоит из одних идеальных сценариев. Ошибки, неверные данные, сбои – все это нужно описывать.

5. Документируйте так, как удобно команде. Формат может быть разным (спецификация, Acceptance Criteria, Use Cases), но суть одна - четкая инструкция для разработки.