Техническое задание на разработку сайта: структура и пример требований

Что должно давать техническое задание

ТЗ нужно, чтобы заказчик и команда одинаково понимали результат и могли его проверить. Перечня «главная, каталог, контакты» недостаточно: он не объясняет, что происходит после нажатия кнопки. Хорошее задание описывает пользователя, действие, данные и ожидаемое состояние. Документ может быть коротким, если проект простой; важна однозначность требований, а не число страниц.

Блок 1: цель и границы первого запуска

Опишите проблему текущего процесса, аудиторию и целевое действие. Например: получать структурированные обращения на разработку вместо сообщений без контакта и описания задачи. Укажите, что войдёт в первый выпуск, а что остаётся на следующий этап. Граница защищает обе стороны: новая идея не должна незаметно менять срок и стоимость уже согласованной работы.

Блок 2: роли и пользовательские сценарии

Перечислите посетителя, клиента, менеджера и администратора, если эти роли нужны. Для каждой запишите путь от входа до результата. У заказа это выбор варианта, корзина, оформление, подтверждение и статус. У заявки — заполнение, согласие, отправка, сохранение и ответ. Права сотрудника описывайте отдельно: кто видит обращения, кто меняет цены и кто управляет доступами.

Блок 3: структура и контент

Зафиксируйте страницы и типы материалов: услуга, кейс, статья, товар. Для каждого определите обязательные поля, источник текста и изображений, возможность редактирования. Укажите, кто переносит старый контент и проверяет ссылки. Если нужны поисковые переходы, страницы должны иметь собственные адреса и доступное содержание. Макет без готового текста не позволяет оценить длинные заголовки и реальные мобильные состояния.

Блок 4: данные и интеграции

Для каждой системы запишите, какие данные приходят и уходят, где главный источник и какое событие запускает обмен. Укажите владельца доступов и наличие тестового контура. Отдельно разберите повторы, ошибки полей, недоступность API и восстановление. Не вставляйте пароли и токены в общий документ: перечислите необходимые доступы, а передавайте секреты согласованным защищённым способом.

Пример проверяемого требования к форме

Вместо «форма работает быстро» напишите: посетитель вводит имя, контакт и задачу; сервер проверяет обязательные поля и согласие; обращение сохраняется с идентификатором; повтор одного отправления не создаёт дубль; при ошибке интерфейс объясняет следующий шаг. Затем задайте измеримую цель времени ответа под согласованной нагрузкой и метод проверки. Числовое значение нужно выбирать под проект, а не копировать из чужого ТЗ.

Блок 5: качество и эксплуатация

Согласуйте поддерживаемые устройства и браузеры, доступность основных действий с клавиатуры, резервное копирование, журнал ошибок и порядок обновления. Для интернет-магазина добавьте проверку расчёта цены и оплаты; для ИИ — набор примеров и проверку неверных ответов. Юридические тексты и требования к данным определяются под бизнес с ответственным специалистом. Разработчик не должен угадывать их по дизайну конкурента.

Приёмка и изменения

Приложите сценарии проверки, список передаваемых материалов и порядок согласования изменений. Для дефекта укажите ожидаемое и фактическое поведение, условия и пример. Для новой функции — отдельный объём и оценку. Если исходных сведений пока мало, начните с проработки и прототипа, а затем превратите проверенный сценарий в ТЗ. Так документ фиксирует решение, а не набор предположений.

По теме