Очень часто в IT-проектах эти два документа путают. Но это разные вещи. Разбираем на примерах, в чём разница и почему их важно разделять. 📝 Техническое задание (ТЗ) Это договор между заказчиком и исполнителем. Фиксирует что нужно сделать, для кого и зачем, но без деталей реализации. 👥 Аудитория: заказчик, менеджер проекта, аналитик. 🎯 Цель: согласовать объём работ и требования к результату. Основные разделы ТЗ (по ГОСТ 34.602-2020): Общие сведения: название проекта, заказчик, сроки. Назначение разработки: бизнес-цели (например: «увеличить конверсию на 20%»). Требования: • функциональные — «Пользователь может фильтровать товары по цене»; • нефункциональные — «Страница загружается ≤ 2 секунд». Контроль и приёмка: критерии тестирования и сдачи. Этапы и сроки разработки. 📌 Пример требования в ТЗ: «Система должна позволять пользователю восстановить пароль через email». ⚙️ Техническая спецификация (ТС / SRS) Это инструкция для разработчиков. Отвечает на вопрос: «Как именно это будет работать?». 👥 Аудитория: разработчики, тестировщики, архитекторы. 🎯 Цель: снять двусмысленности и описать реализацию детально. Что включает ТС: Архитектура: схемы компонентов, выбор технологий (Django + React). Подробное описание функций: алгоритмы, API, форматы JSON. Модели данных: ER-диаграммы БД. Макеты UI/UX: экраны, пользовательские сценарии. Бизнес-правила: логика расчётов и условий. 📌 Пример из ТС (детализация требования из ТЗ): POST /api/v1/auth/password-reset Входные данные: { "email": "string" } Логика: Проверить пользователя в БД. Сгенерировать токен (срок — 1 час). Отправить письмо со ссылкой вида site.com/reset?token=abc123. Записать токен в таблицу password_reset_tokens. 🚦 ТЗ vs. ТС: в чём разница? Вопрос: ТЗ: Что и зачем? ТС: Как именно? Аудитория: ТЗ: Заказчик, бизнес. ТС: Разработчики, QA. Уровень детализации: ТЗ: Бизнес-логика, цели. ТС: Тех. детали, API, схемы. Пример: ТЗ: «Регистрация через соцсети». ТС: «OAuth2.0 Google API, схема таблицы users». Статус: ТЗ: Юридический документ. ТС: Внутренний. документ. Изменения: ТЗ: Только через заказчика. ТС: Управляются внутри команды. 💡 Почему это критично важно? Заказчику проще проверять результат: он не тонет в технических деталях. Разработчики исключают двусмысленности: всё расписано в спецификации. Проект выигрывает: согласование быстрее, реализация чище. ❌ Ошибка: включать в ТЗ низкоуровневые детали (например, структуру БД). ✅ Правильно: в ТЗ — поведение системы, в ТС — реализация. 📚 Если хотите глубже копнуть: Карл Вигерс, «Разработка требований к ПО» — настольная книга аналитиков. #ТЗ #SRS #ТехническаяДокументация #BusinessAnalysis #РазработкаПО