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

Почему список страниц ещё не техническое задание

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

Начните документ с задачи посетителя и компании. Например, условному производителю нужен запрос комплектации с приложенным чертежом. Тогда важны ограничения файлов, маршрут обращения и подтверждение приёма. Для записи на консультацию нужен другой сценарий. Это учебные примеры, а не выполненные проекты Webexlab.

Соберите пять связанных разделов

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

Опишите сценарий до последнего состояния

Для заявки укажите обязательные поля, допустимые значения, проверку на клиенте и сервере, сообщение при ошибке и результат успешной отправки. «Кнопка отправляет письмо» оставляет без ответа вопросы о недоступности почты, повторном нажатии и потере обращения. Определите, что считается принятым обращением, независимо от доставки уведомления.

Пример проверяемого требования: после успешного сохранения обращения посетитель видит подтверждение; при ошибке сохранения форма показывает понятное сообщение и сохраняет введённый текст. Подтверждение не появляется только от нажатия кнопки. Если предусмотрен номер обращения, укажите, где он создаётся и можно ли по нему найти запись.

Рекомендации W3C по формам помогают проверить подписи, инструкции и обратную связь. Но они не определяют ваш процесс продажи: кто перезванивает, в какие часы и что делать с неполным запросом, решает владелец бизнеса. Эти условия тоже должны быть доступны автору текстов.

Зафиксируйте данные и ответственность

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

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

Как описать дизайн без бесконечных правок

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

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

Разберите неизвестное до утверждения

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

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

Пример приложения к ТЗ: требование F-01

Для условной формы запроса проекта можно оформить отдельную карточку F-01. В ней указан вход со страницы услуги, контакт для ответа, необязательное описание и идентификатор направления. Успех означает создание записи обращения; доставка уведомления контролируется отдельно. Проверяющий получает тестовый пример и способ найти запись, не обращаясь к разработчику за каждым подтверждением.

Карточка ссылается на текст подтверждения и описание обработки ошибки. В ней также зафиксировано, что недоступность аналитики не мешает принять обращение. Если вложения не входят в первую версию, это прямо указано в границах, чтобы позже не спорить о том, подразумевались ли они словом «форма».

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

На согласовании попросите заказчика пройти карточку словами посетителя и сотрудника. Первый объясняет, что отправляет и чего ждёт; второй — что получает и как продолжает работу. Если эти рассказы расходятся, техническая формулировка ещё не готова. После согласования ссылка на F-01 используется в макете, задаче разработки и протоколе приёмки, сохраняя одну точку определения результата.

Пример требования к редактированию и публикации

Фраза «все тексты меняются в админке» оставляет слишком много неопределённости. Для учебного требования R-02 возьмём изменение описания услуги. В примере редактор готовит черновик, а ответственный за публикацию выпускает согласованную версию. Конкретные роли нужно выбрать для своего проекта.

Укажите состав редактируемых полей, обязательность, допустимые блоки и порядок обработки отсутствующих значений. Отдельно решите, меняется ли URL при переименовании услуги. Это не должно происходить случайно вместе с правкой заголовка. Переходы со старых адресов и поведение кеша описывают, если они входят в изменение.

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

R-02 связывает макет редактора, задачу разработки и проверку результата. Такая запись позволяет принять конкретное поведение вместо спора о том, считается ли наличие текстового поля полноценным управлением сайтом.