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

Функциональные требования отвечают на вопрос «что?»

Функциональные требования описывают действия, которые система должна уметь выполнять с точки зрения пользователя, другой системы или бизнес-процесса. Они не говорят, насколько быстро это происходит и сколько пользователей выдержит сервис — они фиксируют саму функцию.

Для сервиса коротких ссылок базовый набор может выглядеть так:

• пользователь может создать короткую ссылку для длинного URL;
• по короткому адресу система перенаправляет на исходный URL;
• ссылка может иметь срок действия;
• владелец может удалить свою ссылку.

Требование лучше формулировать как наблюдаемое поведение

Фраза «нужна таблица ссылок в PostgreSQL» — не функциональное требование. Это уже один из вариантов реализации. Настоящее требование должно оставаться верным, даже если завтра мы полностью поменяем внутреннюю архитектуру.

Bad:  Store links in PostgreSQL.
Good: After a short link is created, it must redirect to the saved original URL.

Такое разделение важно: когда мы слишком рано превращаем требование в конкретную технологию, мы сами сокращаем пространство возможных решений.

Основные и дополнительные сценарии

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

Например, для мессенджера отправка и получение сообщений — ядро системы. Поиск по истории, реакции и редактирование сообщений тоже важны, но их можно обсуждать после того, как понятен основной поток данных.

Не забывай о действиях других участников

Система взаимодействует не только с конечным пользователем. Функциональные требования могут описывать работу администратора, фоновой задачи, платёжного провайдера или другого сервиса. Если такой участник влияет на ключевой сценарий, его действия тоже должны попасть в список требований.