Пример ТЗ для ПО: готовый образец структуры, требований и приёмки

Заказчик пишет в ТЗ: «нужен сервис для заявок, удобный и быстрый». Разработчик делает минимально рабочую систему, а через месяц выясняется: не учтены роли, не согласованы статусы, уведомления уходят не тем людям, отчёт не сходится с Excel, а нагрузка в 50 пользователей роняет сервер. Формально ПО есть, фактически — не решает задачу. В разработке программного обеспечения цена размытого ТЗ особенно высока: код переписывать дороже, чем картинку или текст. Разбираем на готовом примере, как составить ТЗ для ПО так, чтобы разработчик, тестировщик и заказчик одинаково понимали, что именно нужно сделать и когда работу можно принять.

Что такое ТЗ для ПО и когда оно спасает

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

Особенно ТЗ для ПО спасает в следующих ситуациях:

• Когда система встраивается в существующий процесс. Нужно не «сделать приложение», а заменить Excel, почту, бумажные заявки или старый модуль. Без описания текущего процесса новая система может оказаться неудобнее только на бумаге.
• Когда есть интеграции. CRM, 1С, ERP, платежный шлюз, LDAP, мессенджеры, email, складская программа — каждая связь требует формата данных, частоты обмена, обработки ошибок и прав доступа.
• Когда важна не только функциональность, но и нагрузка. «Быстрый интерфейс» без цифр не является требованием. В ПО нужны измеримые параметры: время ответа, одновременные пользователи, доступность, объём данных, резервные копии.
• Когда проект делают несколько специалистов. Аналитик, архитектор, backend, frontend, тестировщик, DevOps, дизайнер — без ТЗ каждый понимает задачу по-своему.
• Когда нужно защитить права и безопасность. Персональные данные, коммерческая тайна, лицензии, исходный код, доступы, аудит действий — всё это должно быть зафиксировано до старта, а не после инцидента.

Хорошее ТЗ для ПО отвечает не на вопрос «что нарисовать», а на вопрос «как система должна вести себя в реальных сценариях, при нагрузке, ошибках и передаче данных между ролями».

Простой тест: если по ТЗ можно написать тест-кейсы, оценить срок, собрать архитектуру и принять релиз без серии уточняющих звонков — документ рабочий. Если остаётся вопрос «а кто может удалять заявку?», «а где хранятся файлы?», «а что делать, если 1С недоступна?» — ТЗ нужно дополнять. Для общей постановки задачи полезна статья ТЗ для разработки ПО, а для чтения задачи глазами исполнителя — ТЗ для разработчика.

Специфика ниши ПО: 5 особенностей, которые влияют на ТЗ

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

1. Функциональные требования без сценариев не работают

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

Хороший приём — писать требования в формате: «Если пользователь X выполняет действие Y при условии Z, система делает A, отображает B и сохраняет C». Такой стиль снижает число трактовок.

2. Нефункциональные требования часто важнее кнопок

Многие заказчики подробно описывают интерфейс, но забывают про скорость, надёжность, безопасность, масштабируемость, логирование, бэкапы и восстановление. В результате система может быть красивой, но падать при нагрузке, терять данные или не проходить проверку ИБ.

В ТЗ для ПО нужно задавать измеримые параметры: время отклика, доступность, количество одновременных пользователей, объём хранения, RTO/RPO, требования к шифрованию, журналированию и резервному копированию. Без цифр приёмка превращается в спор «мне кажется, тормозит».

3. Интеграции — зона максимального риска

Почти любое корпоративное ПО связано с внешними системами. И каждая интеграция имеет свои нюансы: протокол, формат, частота, обработка дублей, ошибки сети, права, тестовые контуры, документация API. Если в ТЗ написано просто «интеграция с 1С», разработчик не знает, какие объекты передавать, в каком направлении, как часто и что делать при конфликте данных.

В ТЗ нужно указывать: источник истины, маппинг полей, триггеры обмена, обработку ошибок, логирование, тестовые данные и ответственного за доступы. Иначе интеграция станет отдельным проектом внутри проекта.

4. Данные и миграция决定 срок не меньше, чем код

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

В ТЗ стоит зафиксировать: какие данные переносим, из каких источников, в каком формате, кто отвечает за качество, сколько итераций проверки, нужен ли откат, как сопоставлять дубли и что делать с архивом. Для старых систем это часто критичнее, чем новый интерфейс.

5. AI ускоряет разработку, но не снимает ответственность за архитектуру

В 2026 году AI-инструменты активно помогают генерировать код, писать тесты, объяснять чужой код, предлагать варианты API и ускорять рутину. Это сокращает время на черновые задачи. Но AI не отвечает за бизнес-логику, безопасность, лицензии открытых библиотек, соответствие GDPR/152-ФЗ, производительность на реальных данных и поддержку кода.

Если в проекте используются AI-ассистенты, в ТЗ нужно отдельно указать: какие задачи допустимо автоматизировать, кто проверяет сгенерированный код, как контролировать лицензионную чистоту зависимостей, можно ли передавать исходники и данные заказчика в сторонние сервисы. Полезная рамка для таких задач — ТЗ для ИИ.

Структура ТЗ для ПО

Ниже — рабочая структура, которую можно адаптировать под веб-сервис, мобильное приложение, внутреннюю систему, API или доработку existing продукта. Главное — не ограничиваться списком функций.

1. Цель: какую бизнес-проблему решает ПО

Цель должна быть сформулирована не как «сделать программу», а как измеримое изменение процесса. Например: «сократить время согласования заявки с 3 дней до 4 часов», «исключить ручной перенос данных из Excel в CRM», «обеспечить обработку 200 заказов в час без участия менеджера».

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

2. Требования: функциональные, нефункциональные, интеграционные

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

Важно разделять must have, should have и nice to have. Для MVP достаточно закрыть核心 сценарий, а сложные отчёты, гибкие настройки и редкие интеграции вынести на второй этап. Это снижает срок и стоимость без потери главной бизнес-ценности.

3. Объём: что входит в первую версию и что не входит

В ТЗ для ПО нужен явный список границ. Например: «Входит: веб-версия, 4 роли, 12 полей заявки, маршрут согласования, email-уведомления, базовый отчёт. Не входит: мобильное приложение, офлайн-режим, интеграция с бухгалтерией, multi-tenant, AI-ассистент, миграция архива за 5 лет».

Без блока «не входит» заказчик может считать, что в стоимость включено всё похожее, а исполнитель — только явно описанное. Это одна из самых частых причин конфликтов в IT-проектах.

4. Сроки: этапы, зависимости и точки согласования

Разработка ПО почти никогда не идёт линейно. Есть зависимости: доступы к тестовым средам, согласование макетов, подготовка данных, документация API, безопасность, пилот. В ТЗ нужно зафиксировать этапы и артефакты каждого этапа: прототип, технический дизайн, MVP, тестовый контур, пилот, продуктив.

Отдельно укажите, кто и в какой срок согласует результаты. Если заказчик обязуется ответить на вопросы по маршрутам согласования в течение одного рабочего дня, это должно быть в плане. Иначе срок разработки будет зависеть от пауз на стороне бизнеса.

5. Критерии приёмки: как понять, что ПО готово

Критерии приёмки в ПО должны быть сценарными и измеримыми. Не «работает стабильно», а: «пользователь с ролью менеджер создаёт заявку, система сохраняет её, отправляет уведомление руководителю в течение 1 минуты, руководитель согласует, статус меняется, данные попадают в отчёт». Для нефункциональных требований: «при 100 одновременных пользователях 95% запросов отвечают быстрее 2 секунд».

Хорошая практика — прикладывать таблицу тест-кейсов: сценарий, ожидаемый результат, статус. Тогда приёмка становится проверкой, а не субъективной оценкой.

6. Формат передачи: что заказчик получает после разработки

ПО нельзя принять, если не переданы активы. В ТЗ нужно указать состав передачи: исходный код или репозиторий, доступы к серверам и базам, документация по архитектуре, описание API, инструкции по развёртыванию, список зависимостей и лицензий, учётные записи администраторов, резервные копии, результаты тестирования, акт приёмки.

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

7. Правки: что считается доработкой, а что новой задачей

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

На Workink такие договорённости удобно фиксировать в чате заказа: переписка имеет силу ТЗ и помогает отделить правку от расширения объёма без долгых юридических согласований.

Разделы ТЗ для ПО: что писать и где чаще ошибаются

Готовый пример ТЗ

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

Проект: внутренний веб-сервис «Заявки и согласования» для производственной компании.

Цель: заменить переписку в почте и таблицы Excel, сократить время согласования заявки с 3 дней до 4 часов и дать руководителю отчёт по статусам в реальном времени.

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

• Функционал MVP: создание заявки с обязательными полями, прикрепление файлов до 20 МБ, маршрут согласования, уведомления, история изменений, фильтр по статусам и подразделению, отчёт «за день / за месяц», экспорт в XLSX.
• Правила бизнес-логики: заявка без подписанного приложения не отправляется на согласование; руководитель может вернуть заявку с комментарием; после отклонения сотрудник может отредактировать и отправить повторно; история изменений не удаляется.
• Интеграции: корпоративная почта для уведомлений, Active Directory/LDAP для входа и справочника сотрудников, Telegram для пуш-уведомлений, 1С в режиме read-only для проверки лимитов подразделения.
• Нефункциональные требования: время открытия списка заявок до 2 секунд при 100 одновременных пользователях; доступность 99,5% в рабочее время; хранение логов действий 180 дней; резервные копии каждые 24 часа с хранением 30 дней; HTTPS; разграничение прав; защита от перебора паролей.
• Данные и миграция: перенос активных заявок из Excel за текущий квартал; справочники подразделений и сотрудников синхронизируются раз в сутки; дубли проверяются по табельному номеру.
• Этапы: прототип и маршруты согласования — 5 рабочих дней; MVP на тестовом контуре — 15 дней; пилот на одном отделе — 10 дней; доработки по обратной связи — 5 дней; вывод в продуктив и обучение — 3 дня.
• Критерии приёмки: все роли проходят сценарные тесты; уведомление приходит в течение 1 минуты; отчёт сходится с ручной выборкой по 20 заявкам; при нагрузке 100 пользователей нет ошибок 5xx; доступы, документация и репозиторий переданы.
• Передача: репозиторий с историей коммитов, инструкция по развёртыванию, описание API, список использованных библиотек и лицензий, доступы к тестовому и продуктивному контуру, учётные записи администраторов, акт приёмки.
• Не входит в MVP: мобильное приложение, офлайн-режим, сложная BI-аналитика, интеграция с электронной подписью, миграция архива за предыдущие годы.

Такой пример можно взять за основу и заменить предметную область: вместо заявок — заказы, вместо согласований — подбор персонала, вместо 1С — WMS или CRM. Структура останется рабочей, если сохранить баланс между бизнес-целью, поведением системы и проверяемыми критериями. Заготовки под другие ниши смотрите в шаблонах ТЗ, а общий порядок составления документа — в материале как написать ТЗ.

Критерии приёмки результата разработки ПО

ПО можно принимать, если выполнены измеримые условия. Ниже — базовый набор критериев, который подходит для большинства бизнес-систем.

• Все ключевые сценарии работают без обхода системы. Создание, редактирование, согласование, отклонение, удаление или архивация объектов проходят по согласованным правилам. Нет ситуаций, когда процесс продолжается в почте или Excel.
• Роли и права соответствуют ТЗ. Пользователь видит только разрешённые данные и операции. Административные функции недоступны обычным ролям. Журнал действий фиксирует критичные операции.
• Интеграции обмениваются данными корректно. Заявки, пользователи, справочники, статусы и файлы передаются в согласованном формате. Ошибки сети или недоступность внешней системы обрабатываются явно: есть повтор, лог, уведомление, очередь.
• Нефункциональные показатели достигнуты. Время ответа, нагрузка, доступность, объём хранения, бэкапы и восстановление соответствуют цифрам из ТЗ. Проверяются на тестовом контуре, приближенном к продуктивному.
• Безопасность обеспечена. HTTPS, аутентификация, защита паролей, ограничение попыток входа, проверка загружаемых файлов, отсутствие открытых уязвимостей в зависимостях, соответствие требованиям по персональным данным.
• Миграция данных выполнена и проверена. Перенесённые записи читаются, статусы корректны, дубли обработаны, выборочная сверка прошла. Есть отчёт о количестве перенесённых и отклонённых записей.
• Тестирование пройдено. Есть список тест-кейсов, результаты прогона, перечень устранённых дефектов и согласованный список некритичных ошибок, если они остались.
• Документация и обучение переданы. Инструкция для пользователей, руководство администратора, описание архитектуры, API, развёртывания и восстановления. Персонал прошёл обучение или получил видео/презентацию.
• Активы переданы заказчику. Исходный код, доступы, лицензии, ключи, сертификаты, настройки окружения, контакты поддержки. Заказчик может развивать систему без зависимости от конкретного исполнителя.
• Гарантийные условия зафиксированы. Срок гарантии, что считается гарантийным случаем, как подавать обращения, в какой срок устраняются критичные дефекты.

Вопросы для уточнения до старта

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

• Какую бизнес-метрику должно улучшить ПО и к какому сроку?
• Кто основные пользователи и какие роли нужны в первой версии?
• Какой процесс automatisруем: полностью или только часть?
• Какие данные являются источником истины: новая система, Excel, 1С, CRM, ERP?
• Какие интеграции обязательны для MVP, а какие можно отложить?
• Есть ли доступы к тестовым контурам внешних систем и документация API?
• Какие объёмы данных и нагрузка ожидаются через 3, 6 и 12 месяцев?
• Требуются ли персональные данные, коммерческая тайна, аудит, шифрование, резервные копии?
• Где размещается решение: облако, on-premise, гибрид, сервер заказчика?
• Кто владеет доменом, сертификатами, платёжными системами и ключами доступа?
• Нужна ли миграция исторических данных и за какой период?
• Как будет проходить пилот: на каком отделе, сколько пользователей, какие критерии успеха?
• Сколько кругов согласования дизайна, прототипа и тестовых сценариев входит в проект?
• Что считается багом, а что изменением требований?
• Кто принимает финальное решение: владелец продукта, IT-директор, бухгалтерия, юристы?
• Нужны ли исходники, права на код и передача документации сторонним командам?

Если на часть вопросов нет ответа, это не всегда блокирует старт. Но такие места нужно пометить в ТЗ как «уточняется до этапа X» и не начинать зависимые работы. Например, нельзя обещать срок интеграции с 1С, пока не получены доступы, тестовая база и описание объектов.

Чек-лист готовности ТЗ

Перед публикацией заказа или стартом разработки пройдитесь по короткому чек-листу. Если хотя бы два пункта не закрыты, ТЗ лучше дополнить.

• Цель сформулирована через бизнес-метрику, а не через «сделать удобно».
• Описаны роли, пользовательские сценарии и правила бизнес-логики.
• Разделены functional, non-functional и integration requirements.
• Указаны источники данных, формат интеграций и обработка ошибок.
• Зафиксированы объём MVP и явный список «не входит».
• Есть этапы, зависимости, сроки и правила сдвига при задержках.
• Критерии приёмки оформлены как тест-кейсы или проверяемые сценарии.
• Определён состав передачи: код, доступы, документация, лицензии, обучение.
• Разведены правки, гарантийные случаи и новые задачи.
• Учтены безопасность, персональные данные и требования заказчика по ИБ.

Честно: идеальное ТЗ не заменяет живое общение с командой разработки. Но оно переводит проект из режима «догадываемся» в режим «проверяем соответствие». Когда цель, сценарии, интеграции, метрики и передача активов зафиксированы, обе стороны понимают, что считается результатом, а что — расширением задачи.

Как заказать разработку ПО на Workink

На Workink задача по разработке ПО публикуется в категории «Техническое задание (ТЗ)». Это удобно, когда нужно не просто найти программиста, а передать структурированное задание: цель, роли, функционал, интеграции, нефункциональные требования, этапы, критерии приёмки и состав передачи.

Платформа снижает типовые риски IT-заказов:

• Безопасная сделка: деньги находятся в резерве до приёмки работы. Вы платите за результат, а не за обещание сдать проект.
• Комиссия 11% за заказ и 0% за вывод: прозрачные условия без удержания при выводе средств.
• Доработки бесплатно до соответствия ТЗ: если ПО не соответствует согласованным требованиям, исполнитель дорабатывает результат.
• Договорённости в чате имеют силу ТЗ: всё, что вы обсудили по сценариям, интеграциям, срокам, правкам и передаче доступов, фиксируется в переписке и защищает обе стороны.

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

Найти исполнителя Разместить заказ Защита покупателей

Полезные материалы по теме

• ТЗ для разработки ПО: как поставить задачу — общая логика постановки задачи на программный продукт.
• ТЗ для разработчика: как читать и декомпозировать задачу — как исполнитель превращает ТЗ в технические задачи и оценку.
• ТЗ для ИИ: промт-задание и разработка AI-решения — если в ПО используются нейросети, генерация кода или AI-ассистенты.
• Шаблоны ТЗ: подборка готовых структур — готовые каркасы документов для разных ниш.
• Как написать ТЗ: пошаговая инструкция — порядок сбора требований и оформления документа.