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

Техническое задание (ТЗ) — структура и содержание

Техническое задание (Specification, Technical Requirements Document) — это формальный документ, который описывает все требования к разработке системы или её компонента. Это основной документ, на основе которого разработчик начинает писать код.

Определение и назначение ТЗ

Что такое ТЗ: Это договор между аналитиком (заказчиком требований) и разработчиком, который определяет ЧТО должно быть сделано, но не КАК это делать.

Для чего нужно:

• Единое понимание требований между бизнесом и техникой
• Основа для оценки сроков и стоимости
• Контроль качества (можно проверить, выполнено ли всё)
• Юридическое обоснование в случае споров
• База для тестирования

Структура технического задания

1. Титульный лист

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

Название проекта: Система управления складом
Версия: 1.0
Дата: 28.03.2025
Автор: Иван Сидоров (System Analyst)
Утверждено: Петр Петров (Project Manager)
Статус: Approved

2. История изменений (Change Log)

Отслеживание версий документа

3. Обзор проекта (Overview)

Краткое описание (2-3 абзаца):

Система управления складом предназначена для учёта товарно-материальных ценностей на складе. Система должна отслеживать приход и расход товара, рассчитывать остатки, управлять заказами поставщикам и уведомлять о дефиците.

Бизнес-контекст:

• Компания имеет 5 складов в разных городах
• Текущая система — Excel таблицы (не масштабируется)
• Ежедневно обрабатывается 500+ операций
• Частые ошибки в подсчёте (потери для компании 2-3% товара)

Цели проекта:

• Автоматизировать учёт товара
• Снизить потери с 2-3% до 0.1%
• Обеспечить видимость товара в режиме real-time
• Интегрировать с системой ERP (SAP)

4. Область применения (Scope)

Что входит в ТЗ:

• Учёт товара на складе
• Управление заказами поставщикам
• Отчётность по остаткам
• Интеграция с SAP

Что НЕ входит:

• Учёт финансов (работает отдельная система)
• Логистика и маршруты доставки
• Управление поставщиками (CRM система)
• Анализ продаж по регионам

5. Определения и сокращения (Glossary)

6. Функциональные требования (Functional Requirements)

Требование 1: Приём товара

ID: FR-001
Название: Приём товара на склад
Приоритет: Высокий
Статус: Approved

Описание:
При поступлении товара система должна:
1. Отсканировать штрих-код товара
2. Проверить соответствие поставки с заказом
3. Создать приходный ордер
4. Обновить остатки
5. Отправить уведомление в SAP

Предусловие: Заказ существует в системе
Постусловие: Остатки обновлены, документ создан

Acceptance Criteria:
- Приём должен быть завершён за < 5 минут
- Ошибка при сканировании < 0.1%
- Синхронизация с SAP за < 1 минуту

Примечание: Если товар не совпадает с заказом, отправить alert на email старшему менеджеру

Требование 2: Управление остатками

ID: FR-002
Название: Отслеживание остатков товара

Описание:
Система должна отслеживать:
- Физические остатки (что на полке)
- Резервы (товар, зарезервированный для заказов)
- Доступные остатки (физическое - резервы)
- Товар в пути (заказано, но не получено)

Уровни детализации:
- По складу
- По секции на складе
- По индивидуальному товару
- По лоту (для товаров с датой годности)

Требование 3: Отчётность

ID: FR-003
Название: Отчёты по остаткам и движению товара

Отчёты:
1. Остатки по складам (ежедневно в 18:00)
2. Товар ниже минимума (реал-тайм alert)
3. Просрочка товара (по дате)
4. Перемещения между складами (дневной отчёт)
5. Расхождение физических и учётных остатков

Формат: PDF, Excel, экспорт в SAP

7. Нефункциональные требования (Non-Functional Requirements)

Производительность:

• Время ответа: < 2 сек на операции
• Пропускная способность: 100+ операций/минуту
• Данные обновляются каждые 30 секунд

Надёжность:

• Uptime: 99.5% (макс 3.5 часа простоя в месяц)
• Recovery Time (RTO): 1 час
• Recovery Point (RPO): 5 минут
• Backup: ежедневно в 02:00

Безопасность:

• Аутентификация: LDAP
• Авторизация: роли (Admin, Manager, Operator, Viewer)
• Шифрование: TLS 1.2 для передачи данных
• Логирование: все операции в audit log
• PII: не хранится в системе

Масштабируемость:

• Поддержка от 100 до 10 000 SKU
• От 10 до 500 одновременных пользователей
• Архив данных > 1 года

Совместимость:

• Браузеры: Chrome, Firefox, Safari последних 2 версий
• ОС: Windows 10+, macOS 10.15+
• Мобильность: iOS 13+, Android 10+

Локализация:

• Язык: русский, английский
• Часовой пояс: UTC+3 (Moscow Time)
• Формат чисел: 1 234,56 (europena)

8. Диаграммы и визуализация

Use Case диаграмма:

┌──────────────┐
│  Оператор    │
└────┬─────────┘
     │
     ├─→ Приём товара (UC-001)
     ├─→ Выборка товара (UC-002)
     ├─→ Просмотр остатков (UC-003)
     └─→ Создание отчёта (UC-004)
     
┌──────────────┐
│   Менеджер   │
└────┬─────────┘
     │
     ├─→ Анализ остатков (UC-005)
     ├─→ Управление складом (UC-006)
     └─→ Заказ товара (UC-007)

ER диаграмма (упрощённая):

Warehouse (id, name, location)
    |
    1-* Shelf (id, warehouse_id, number)
         |
         1-* Product (sku, name, category)
              |
              1-* Inventory (id, product_id, warehouse_id, quantity)

Процесс приёма товара (BPMN):

Start → Сканирование товара → Проверка заказа → 
  Если ОК: Создание ордера → Обновление остатков → SAP sync → End
  Если ошибка: Alert менеджеру → Manual Review

9. Интеграции (Integration)

Система 1: SAP ERP

• Синхронизация остатков в реал-тайм
• Два раза в день (10:00, 18:00) — полная синхронизация
• API: SOAP (web service)
• Формат: XML
• Обработка ошибок: retry 3 раза с exponential backoff

Система 2: Email система

• Отправка уведомлений при дефиците
• SMTP протокол
• Шаблоны писем на русском и английском

Система 3: 1С:Бухгалтерия

• Синхронизация документов (приходные ордера)
• CSV экспорт один раз в день
• FTP на сервер 1С

10. Интерфейс (UI/UX)

Главный экран:

• Dashboard с основными метриками (общие остатки, товар ниже минимума)
• Быстрый доступ к основным функциям
• График движения товара за неделю

Экран приёма товара:

• Поле для сканирования штрих-кода
• Таблица ожидаемого товара
• Поля для ввода фактического количества
• Кнопка "Завершить приём"

Отчёты:

• Фильтры по складам, датам, товарам
• Экспорт в PDF/Excel
• Сохранение избранных отчётов

11. Критерии приёма (Acceptance Criteria)

На завершение каждого требования:

FR-001 (Приём товара):
✓ Может добавить товар через сканирование
✓ Система проверяет наличие в заказе
✓ Приходный ордер генерируется в PDF
✓ Остатки обновляются в реал-тайм
✓ Данные синхронизируются с SAP
✓ При ошибке — alert отправляется менеджеру
✓ Операция занимает < 5 минут

12. Ограничения и риски

Ограничения:

• Максимум 50 000 SKU в системе
• Макс 10 складов
• Архив доступен только за последние 2 года

Риски и их снижение:

13. План тестирования (Test Plan)

Unit тесты:

• Каждая функция должна иметь тесты
• Coverage > 80%

Integration тесты:

• Проверка синхронизации с SAP
• Проверка уведомлений по email
• Проверка экспорта в 1С

UAT (User Acceptance Testing):

• 5 дней тестирования с операторами
• Минимум 20 тест-кейсов
• Все дефекты критичного уровня должны быть закрыты

Load тестирование:

• Эмуляция 500+ операций в минуту
• Проверка времени ответа < 2 сек

14. График разработки (Timeline)

Период разработки: 4 месяца (1 апреля - 31 июля 2025)

Фаза 1 (Апрель): Архитектура, БД дизайн (4 недели)
Фаза 2 (Май): Основные функции (4 недели)
Фаза 3 (Июнь): Интеграции, отчёты (4 недели)
Фаза 4 (Июль): Тестирование, исправление, UAT (4 недели)
Милестон 1: Внутреннее тестирование - 15 июня
Милестон 2: Интеграция с SAP - 30 июня
Милестон 3: Production готово - 31 июля

15. Ресурсы и бюджет

Команда разработки:

• 1 System Architect
• 2 Backend разработчика
• 1 Frontend разработчик
• 1 Database Administrator
• 1 QA Engineer

Инфраструктура:

• Dev окружение
• Staging окружение
• Production окружение

Бюджет: 500K руб. (распределение на 4 месяца)

16. Приложения

Приложение A: Детальные диаграммы баз данных Приложение B: API спецификация (OpenAPI) Приложение C: Макеты интерфейсов (Figma ссылка) Приложение D: Примеры интеграции с SAP Приложение E: Список стейкхолдеров и контакты

Best Practices при написании ТЗ

1. Будь конкретен: Не пиши "быстрая система", напиши "время ответа < 2 сек"
2. Используй метрики: Цифры вместо общих фраз
3. Охватывай исключения: Что происходит при ошибке?
4. Диаграммы лучше слов: Используй UML, BPMN, ER диаграммы
5. Версионирование: Отслеживай изменения (Change Log)
6. Одобрение: Получи подписи от stakeholder'ов
7. Обновления: ТЗ может меняться, документируй changes
8. Реалистичность: Проверь с архитектором — выполнимо ли?
9. Тестируемость: Каждое требование должно быть проверяемым
10. Читаемость: Используй заголовки, списки, таблицы

Частые ошибки

• Расплывчатые требования ("система должна быть красивой")
• Требования, зависящие друг от друга, не связанные ссылками
• Отсутствие Acceptance Criteria
• Забывчивость нефункциональных требований
• Игнорирование интеграций
• Слишком амбициозный scope
• Отсутствие плана тестирования
• Недостаточная коммуникация с разработчиками

Заключение

Техническое задание — это основной артефакт, который превращает идею в конкретный план работы. Хорошее ТЗ:

• Понятно бизнесу и технике
• Содержит все необходимые детали
• Реалистично в плане сроков и бюджета
• Включает критерии приёма (как проверить готовность)
• Документирует риски и ограничения

Время, потраченное на хорошее ТЗ, экономит недели разработки и баг-фиксов.