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

Техническое задание на сайт — приложение к договору, которое определяет границу работ и порядок приёмки. Ниже приведён состав документа по разделам и требования к формулировкам в каждом из них.

1. Общие сведения

1.1. Наименование проекта и адрес размещения (домен). 1.2. Стороны: заказчик, исполнитель, реквизиты, контактные лица с правом принимать решения по проекту. 1.3. Дата составления и номер редакции документа. 1.4. Перечень документов, к которым ТЗ является приложением.

2. Назначение и границы работ

2.1. Назначение сайта одним предложением, без оценочных слов. 2.2. Перечень работ, входящих в объём. 2.3. Перечень работ, не входящих в объём. Раздел обязателен. Типовое содержание: наполнение контентом, фотосъёмка, тексты, поисковое продвижение, реклама, ведение после сдачи. 2.4. Указание на то, что работы, не перечисленные в пункте 2.2, выполняются по отдельному согласованию.

3. Структура сайта

3.1. Перечень страниц с указанием уровня вложенности. 3.2. Для каждой страницы: назначение, перечень блоков сверху вниз, наличие форм. 3.3. Перечень шаблонов страниц, создаваемых один раз и используемых многократно (карточка товара, статья блога, страница услуги). 3.4. Указание количества страниц по каждому шаблону, входящих в объём наполнения, если наполнение входит в объём.

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

4.1. Каждое требование формулируется как проверяемое действие системы. Проверяемая формулировка содержит субъект, действие и результат.

Проверяемо: «При отправке формы заявки система сохраняет запись в базе, отправляет письмо на адрес, указанный в настройках, и показывает пользователю страницу подтверждения».

Не проверяемо: «Формы работают удобно и быстро».

4.2. Для форм: перечень полей, обязательность каждого поля, правила проверки, текст сообщения об ошибке, адрес получателя, действие после отправки. 4.3. Для расчётов и калькуляторов: формула, перечень входных параметров, диапазоны допустимых значений, правило округления. 4.4. Для оплаты: наименование платёжного сервиса, перечень способов оплаты, порядок формирования чека, действия системы при успешной и неуспешной оплате. 4.5. Для интеграций: наименование внешней системы, направление обмена, состав передаваемых полей, периодичность, поведение при недоступности внешней системы.

5. Роли и права доступа

5.1. Перечень ролей. 5.2. Матрица прав: по строкам разделы системы, по столбцам роли, в ячейках — просмотр, изменение, отсутствие доступа. 5.3. Раздел обязателен для проектов с админкой. В большинстве проектов он выглядит так: сборщик видит заказы, но не видит суммы и себестоимость; менеджер видит клиентов и заказы, но не видит настройки и не создаёт пользователей; владелец видит всё.

6. Требования к контенту

6.1. Сторона, предоставляющая тексты, изображения, логотип, документы. 6.2. Срок предоставления материалов. 6.3. Форматы файлов и требования к исходникам. 6.4. Последствия непредоставления материалов в срок: сдвиг срока работ на количество дней задержки.

7. Технические требования

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

8. Хостинг, домен, доступы

8.1. Домен регистрируется на заказчика. 8.2. Хостинг оформляется на заказчика. 8.3. Перечень доступов, передаваемых заказчику при сдаче. 8.4. Порядок передачи доступов и срок.

9. Порядок приёмки

9.1. Исполнитель уведомляет заказчика о готовности к приёмке. 9.2. Заказчик в течение согласованного числа рабочих дней проверяет соответствие результата разделам 3–7 и направляет перечень замечаний либо подписывает акт. 9.3. Замечание принимается к исполнению, если оно ссылается на пункт настоящего ТЗ. 9.4. Пожелание, не основанное на пункте ТЗ, оформляется как изменение по разделу 10. 9.5. Исключительные права на код переходят заказчику по акту.

10. Порядок изменений

10.1. Изменение оформляется письменно с указанием даты, состава изменения, влияния на срок и стоимость. 10.2. Изменение вступает в силу после подтверждения обеими сторонами. 10.3. До подтверждения работы выполняются по действующей редакции ТЗ.

11. Гарантия

11.1. Гарантийный срок — три месяца с даты подписания акта. 11.2. В гарантию входит устранение ошибок исполнителя. 11.3. В гарантию не входят изменения требований, новые функции, последствия правок, внесённых третьими лицами, и сбои на стороне внешних сервисов.

12. Типовые формулировки

12.1. Ниже приведены примеры замены непроверяемых формулировок на проверяемые.

12.2. Формулировка считается проверяемой, если по ней можно составить действие и однозначно зафиксировать результат.

13. Приложения к документу

13.1. Схема структуры сайта. 13.2. Макеты экранов либо ссылки на них, с указанием версии и даты. 13.3. Матрица прав по пункту 5.2. 13.4. Перечень внешних сервисов с указанием стороны, оплачивающей их использование. 13.5. Перечень материалов, предоставляемых заказчиком, со сроками.

Объём документа по типам проектов

Для лендинга достаточно разделов 1, 2, 3, 4.2, 6, 9. Объём — две-три страницы. Требовать матрицу прав для одной страницы с формой избыточно.

Для сайта с админкой добавляются разделы 5, 7, 8, 10. Объём — от шести страниц.

Для платформы и SaaS документ включает все разделы, а раздел 4 детализируется до отдельных сценариев с описанием состояний. Сроки и стоимость по типам проектов приведены на странице услуг.

Коротко

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