Техническое задание (ТЗ/SRS) на разработку приложения: пример и структура

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

Фиксация объёма (scope). ТЗ превращает расплывчатое «хочу приложение для заказов» в конкретный перечень: столько-то экранов, такие-то роли, эти интеграции. Только зафиксированный объём делает возможной честную смету и реальный срок. Пока объём не описан, любая названная цифра — гадание, а любое «мы думали, это входит» — законный повод для конфликта.

База для приёмки. По ТЗ заказчик принимает работу. Требование «пользователь оплачивает заказ картой» либо выполнено, либо нет — проверяемо. Без документа приёмка сводится к «нравится / не нравится», а это дорога к бесконечным доработкам за ваш счёт.

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

Отсюда практический вывод: экономия на этапе аналитики и ТЗ — самая дорогая экономия в проекте. Ошибка в требовании, найденная на старте, стоит часа работы аналитика; та же ошибка после релиза — переписанного модуля и сорванного срока. Дефекты требований многолетне держатся в числе главных причин провала IT-проектов — по данным исследований PMI и Standish Group.

Вокруг ТЗ роится десяток похожих терминов, и их постоянно путают. Разведём по местам — это сэкономит нервы на переговорах.

Бриф — короткий документ на входе, свободной формы: что за бизнес, какая задача, зачем нужен продукт, примеры-референсы. Бриф отвечает на «зачем и в общих чертах что». Это ещё не ТЗ, а сырьё для него.

ТЗ (техническое задание) — детальный структурированный документ: что система делает, какой должна быть, как принимается. Российская традиция, кодифицированная в ГОСТах. Отвечает на «что именно и с какими требованиями».

SRS (Software Requirements Specification) — по сути тот же документ в западной традиции. Устанавливает соглашение между заказчиком и исполнителем о том, что продукт должен делать. Практически SRS и ТЗ — близнецы одного назначения; разница в стандартах, по которым их пишут (у нас ГОСТ, на Западе — линейка IEEE/ISO).

Функциональные требования (ФТ) и user story — это уже части ТЗ, а не альтернатива ему. ФТ — формулировки «система делает то-то». User story — гибкая форма того же требования от лица пользователя. Оба живут внутри ТЗ, просто в разных форматах записи.

Вокруг стандартов много мифов — от «ТЗ обязательно по ГОСТу» до «ГОСТы давно неактуальны». Реальная картина спокойнее.

ГОСТ 34.602-2020 — «Техническое задание на создание автоматизированной системы». Действует с 1 января 2022 года, заменил редакцию 1989 года. Регулирует ТЗ на автоматизированные системы: добавлен раздел о порядке разработки, из требований убрали устаревшую терминологию, а сами требования по стандарту должны быть «единичными, непротиворечивыми, актуальными, выполнимыми, проверяемыми и однозначными» — фактически это и есть критерии хорошего требования.

ГОСТ 19.201-78 (ЕСПД) — «Техническое задание. Требования к содержанию и оформлению». Регулирует ТЗ на программу независимо от назначения. Стандарт формально действует, но морально устарел — введён ещё в 1980 году.

IEEE 830 — западная классика, «рекомендуемая практика для SRS». Важный нюанс, который упускают почти все русскоязычные статьи: стандарт IEEE 830-1998 отменён и заменён на ISO/IEC/IEEE 29148 (действующая редакция — 29148:2018). Если подрядчик ссылается на IEEE 830 как на живой документ — это признак, что он давно не заглядывал в первоисточник.

Когда стандарт обязателен? ГОСТ 34.602-2020 обязателен для государственных и крупных корпоративных информационных систем — там, где действуют 44-ФЗ, 223-ФЗ и требования регуляторов. В обычной коммерческой разработке мобильного или веб-приложения формальный ГОСТ по умолчанию не нужен — стандарт применяют добровольно или если это прописано в договоре. Чаще ТЗ пишут в свободной структурированной форме или, при гибкой разработке, в виде набора user stories.

Независимо от того, пишете вы по ГОСТу или в свободной форме, скелет качественного ТЗ на приложение одинаков. Меняется степень формальности, а не состав.

1. Цели и бизнес-задачи. Зачем продукт нужен бизнесу и какую проблему решает. Без этого раздела команда делает функции, не понимая приоритетов.

2. Роли пользователей. Кто пользуется продуктом: гость, зарегистрированный пользователь, администратор, оператор. У каждой роли — свои права и сценарии.

3. Функциональные требования и сценарии. Ядро документа: что система делает. Здесь же — пользовательские сценарии («пользователь оформляет заказ»), разложенные по шагам.

4. Структура и экраны. Карта экранов и логика переходов: какая кнопка что открывает, что происходит после действия. Часто сопровождается прототипами.

5. Интеграции. С чем продукт связывается: платёжные системы, 1С/ERP, карты, аналитика, внешние API. Раздел, который забывают чаще всего, — и который потом рушит сроки.

6. Нефункциональные требования. Каким продукт должен быть: платформы (iOS, Android, минимальные версии), скорость, нагрузка, безопасность, поведение офлайн.

7. Требования к аналитике. Какие события трекаем, какие метрики важны — чтобы после запуска понимать, что происходит.

8. Критерии приёмки. По каким признакам заказчик считает работу выполненной. Именно этот раздел превращает ТЗ из описания в инструмент контроля.

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

Два типа требований, которые нельзя смешивать, потому что они про разное и проверяются по-разному.

Функциональные требования (ФТ) описывают, что система делает — конкретные функции и действия. «Пользователь регистрируется по номеру телефона». «Администратор видит список заявок и меняет их статус». «Приложение отправляет push-уведомление при смене статуса заказа». Формула ФТ — «что делать».

Нефункциональные требования (NFR) описывают, насколько хорошо система это делает — её качества. «Экран списка заказов открывается быстрее двух секунд при 10 тысячах записей». «Приложение работает на iOS 15+ и Android 10+». «Персональные данные хранятся в соответствии с 152-ФЗ». Формула NFR — «как хорошо».

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

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

Функция: Оформление заявки на услугу

Роль: авторизованный пользователь.

Пользовательский сценарий:

• 1. Пользователь на экране каталога выбирает услугу и нажимает «Оформить заявку».
• 2. Открывается форма заявки: адрес, дата и время, комментарий.
• 3. Пользователь заполняет обязательные поля и нажимает «Отправить».
• 4. Система проверяет заполнение, создаёт заявку, показывает экран подтверждения с номером.
• 5. Пользователю приходит push-уведомление о принятии заявки.

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

• ФТ-1. Кнопка «Оформить заявку» доступна только авторизованному пользователю; гостя система ведёт на экран входа.
• ФТ-2. Поля «адрес» и «дата/время» обязательны; при незаполнении кнопка «Отправить» неактивна.
• ФТ-3. Дату нельзя выбрать в прошлом; доступны слоты на 14 дней вперёд.
• ФТ-4. После создания заявки система присваивает ей уникальный номер и статус «Новая».
• ФТ-5. Push о смене статуса приходит в течение 1 минуты после изменения на сервере.

Нефункциональные требования:

• NFR-1. Экран формы открывается быстрее 1,5 секунды при стабильном соединении.
• NFR-2. Поддержка iOS 15+ и Android 10+.
• NFR-3. При отсутствии сети введённые данные сохраняются локально и отправляются при восстановлении связи.

Критерии приёмки:

• Заявка создаётся с корректным номером и статусом «Новая», видна в личном кабинете.
• Незаполненные обязательные поля блокируют отправку и подсвечиваются.
• Push о принятии заявки приходит на устройство пользователя.

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

Разница между ТЗ, которое защищает, и ТЗ, которое порождает споры, — в качестве отдельных формулировок. Хорошее требование проходит проверку на несколько свойств.

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

Проверяемость. Должно быть ясно, как убедиться, что требование выполнено. Если проверить нельзя — это не требование, а пожелание.

Атомарность. Одно требование — одна мысль. «Пользователь регистрируется и оплачивает подписку» надо разбить: это две функции, которые тестируются отдельно.

Достижимость. Требование выполнимо в рамках технологий и бюджета проекта, а не взято из фантазий.

Эти свойства перекликаются с известной формулой SMART (конкретное, измеримое, достижимое, релевантное, ограниченное по времени) и, что показательно, почти дословно повторяют формулировку ГОСТ 34.602-2020: требования должны быть единичными, непротиворечивыми, проверяемыми и однозначными. Стандарты разные — принцип один.

В гибкой разработке те же требования записывают в форме user story: «Как <роль>, я хочу <действие>, чтобы <ценность>». Например: «Как администратор, я хочу выгружать отчёт в PDF, чтобы отправлять его руководству». К истории прикладывают критерии приёмки — часто в формате «Дано <контекст>, когда <действие>, тогда <результат>». Это то же функциональное требование плюс критерий приёмки, только человеческим языком.

Когда уместна гибкая форма, а когда классический документ, зависит от выбранного процесса — разбирали это в материале про методологии разработки и в статье про жизненный цикл разработки ПО.

Два вопроса, на которых заказчики спотыкаются чаще всего.

Кто пишет ТЗ. На подрядном проекте документ обычно составляет аналитик или проджект-менеджер исполнителя — в тесной связке с заказчиком. Это правильно: заказчик приносит бизнес-задачу и знание предметной области, подрядчик превращает её в проверяемые требования.

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

Про деньги на этом шаге. У нас оценка проекта по вашим вводным бесплатная и автоматизированная, поэтому смету и план мы возвращаем быстро, а не через две недели. Разработка полноценного ТЗ как отдельная услуга начинается от 300 тыс. ₽, сама заказная разработка продукта — от 1,7 млн ₽.

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

Нужно ли ТЗ в Agile. Да, но в другой форме. Гибкая разработка не отменяет фиксацию требований — она меняет её формат: вместо толстого документа, написанного один раз и целиком, требования живут как приоритизированный список user stories с критериями приёмки, который уточняется по ходу. Суть та же — зафиксировать, что и как принимаем.

Отличается лишь то, что при Agile объём осознанно оставляют подвижным, а при классическом ТЗ фиксируют целиком заранее. Выбор формы прямо связан с моделью работы и оплаты проекта.

Расплывчатые формулировки. «Удобно», «быстро», «современно», «как у конкурента» — под такие слова можно сдать что угодно. Каждое требование должно быть проверяемым числом или фактом, иначе приёмка превратится в спор о вкусах.

Забытые нефункциональные требования и интеграции. Функции описали, а про нагрузку, безопасность и связь с 1С забыли. Эти разделы всплывают в середине разработки и рушат и сроки, и архитектуру. Их место — в ТЗ, а не в панике на середине проекта.

ТЗ как формальность для галочки. Документ написали, подписали и убрали в стол, а разработку ведут «по здравому смыслу». Тогда ТЗ не защищает никого: при споре важно не наличие документа, а то, что реально по нему работали и по нему принимали.