Составление технического задания на разработку сайта
Техническое задание — документ, который фиксирует что именно будет разработано, в каком виде, и как это будет проверяться. Плохое ТЗ — источник споров о том, кто прав. Хорошее ТЗ — инструмент коммуникации между заказчиком, разработчиками и тестировщиками.
Основная ошибка при написании ТЗ: описывать интерфейс вместо поведения. «Кнопка синего цвета в правом углу» — не ТЗ. «При нажатии на кнопку "Оформить заказ" система создаёт заказ со статусом draft, резервирует товар на складе, отправляет email подтверждения и перенаправляет пользователя на страницу /orders/{id}» — ТЗ.
Структура технического задания
1. Назначение и цели системы
Описывает контекст: для кого создаётся, какую бизнес-задачу решает, каковы критерии успеха (не «удобный сайт», а «конверсия в заявку не менее 3%», «время загрузки главной страницы до 2 секунд»).
2. Пользовательские роли и права
Роли:
- Гость (неаутентифицированный пользователь)
- Покупатель (зарегистрированный пользователь)
- Менеджер (сотрудник компании)
- Администратор
Матрица доступа:
| Действие | Гость | Покупатель | Менеджер | Админ |
|-----------------------|-------|-----------|---------|-------|
| Просмотр каталога | ✓ | ✓ | ✓ | ✓ |
| Добавление в корзину | ✓ | ✓ | — | — |
| Оформление заказа | ✗ | ✓ | — | — |
| Управление заказами | ✗ | свои | все | все |
| Управление товарами | ✗ | ✗ | ✓ | ✓ |
| Управление пользоват. | ✗ | ✗ | ✗ | ✓ |
3. Функциональные требования
Каждое требование в формате: идентификатор, описание, предусловия, результат, исключения.
FR-001: Регистрация пользователя
Предусловия:
- Пользователь не аутентифицирован
- Email не зарегистрирован в системе
Основной сценарий:
1. Пользователь вводит email, пароль, имя
2. Система валидирует данные (email формат, пароль ≥ 8 символов)
3. Система создаёт учётную запись со статусом "не подтверждён"
4. Система отправляет письмо с ссылкой подтверждения (TTL 24 часа)
5. Пользователь получает сообщение "Проверьте email"
Исключения:
- Email уже используется → ошибка "Этот email уже зарегистрирован"
- Невалидный email → ошибка валидации
- Ошибка отправки email → задача ставится в повторную очередь,
пользователю показывается сообщение "Письмо придёт в течение нескольких минут"
Результат: запись в таблице users, запись в очереди email
4. Нефункциональные требования
Производительность:
- Время ответа API: 95-й перцентиль < 300ms при нагрузке 100 rps
- Страница каталога: FCP < 1.5s, LCP < 2.5s (Core Web Vitals)
- Размер начального JS-бандла: < 150KB gzip
Надёжность:
- Uptime: 99.5% (плановые простои по расписанию в нерабочее время)
- Время восстановления после сбоя: < 15 минут
- Резервное копирование БД: ежедневно, хранение 30 дней
Безопасность:
- Аутентификация: JWT с TTL 1 час + refresh token 30 дней
- Хеширование паролей: bcrypt, cost factor 12
- Rate limiting: 5 неудачных попыток входа → блокировка на 15 минут
- HTTPS везде, HSTS header
- SQL-инъекции: только параметризованные запросы, ORM
- XSS: Content Security Policy, sanitize пользовательский ввод
5. Интеграции
Внешние сервисы:
- Оплата: ЮKassa (API v3)
- Методы: банковская карта, СБП, ЮMoney
- Webhook: POST /api/payments/webhook (HMAC-SHA256 подпись)
- Доставка: СДЭК API v2
- Расчёт стоимости при оформлении заказа
- Создание накладной при подтверждении заказа
- Трекинг через webhook или polling (каждые 4 часа)
- Email: SendGrid (transactional)
- Подтверждение регистрации
- Восстановление пароля
- Статусы заказа
- Аналитика: Яндекс.Метрика + GA4
- Электронная торговля (просмотр товара, добавление в корзину, покупка)
6. Схема данных
Не полная ERD-диаграмма, но ключевые сущности и их отношения:
users (1) ─── (N) orders
orders (1) ─── (N) order_items
order_items (N) ─── (1) products
products (N) ─── (1) categories
products (1) ─── (N) product_images
users (1) ─── (1) carts
carts (1) ─── (N) cart_items
7. Среды и деплой
Среды:
- development: локально (Docker Compose)
- staging: https://staging.example.com — для тестирования перед релизом
- production: https://example.com
CI/CD:
- Ветка develop → автодеплой на staging
- Ветка main → деплой на production (ручное подтверждение)
- Прогон тестов обязателен перед деплоем
Мониторинг:
- Uptime: UptimeRobot (проверка каждую минуту)
- Ошибки: Sentry
- Метрики: Grafana + Prometheus
8. Приёмочные критерии
Чёткие условия, при которых работа считается выполненной:
Модуль "Каталог":
☐ Список товаров с пагинацией (20 товаров на страницу)
☐ Фильтрация по категории, цене, наличию
☐ Сортировка по цене, новизне, популярности
☐ Поиск работает (полнотекстовый, от 3 символов)
☐ Карточка товара: фото, описание, цена, кнопка "В корзину"
☐ Breadcrumbs с микроразметкой BreadcrumbList
☐ LCP карточки товара < 2.5s на мобильном (Lighthouse)
☐ Тест: добавление несуществующего товара возвращает 404
Формат документа
ТЗ живёт в Git вместе с кодом. Markdown + PlantUML для диаграмм. Версионируется, проходит ревью через PR. Изменения требований — через PR с обсуждением, не через Telegram.
Объём разумного ТЗ для сайта средней сложности: 30–80 страниц. Меньше — недостаточная детализация. Больше — ТЗ ради ТЗ, которое никто не читает.
Сроки
Составление ТЗ для интернет-магазина среднего размера (50–100 экранов) — две-три недели с учётом итераций с заказчиком. Это включает: аналитические интервью с stakeholders, прописывание сценариев использования, согласование нефункциональных требований, ревью с технической командой. Экономия на ТЗ обычно оборачивается переделками, которые стоят в 3–5 раз дороже.