Техническое задание на разработку программного обеспечения: как составить и что в нём должно быть

Компания заказывает систему для работы с дилерами. ТЗ занимает четыре страницы: «система должна быть удобной», «интеграция с 1С», «разграничение прав». Через полгода выясняется, что под интеграцией заказчик понимал обмен заказами каждые пять минут. А разработчик заложил выгрузку остатков раз в сутки. Каждый по-своему прав, и оба теряют месяцы на переделку.

Бывает и наоборот. ТЗ на двести страниц, аккуратно переписанное из ГОСТа. Его подписали, но целиком не прочитал никто, включая авторов. В итоге спорят так же, только с толстой папкой на столе.

Техническое задание на разработку программного обеспечения — это документ, в котором заказчик и разработчик записывают, что должна делать программа, кто ею пользуется, с какими системами она связана и как проверят результат. Ниже разберём, из чего оно состоит, нужен ли ГОСТ и как писать требования, которые нельзя понять двумя способами.

Сайт похож на витрину магазина. Важно, что на ней стоит, как подписаны товары и где касса. Программа для бизнеса больше похожа на склад за витриной. Там есть кладовщики с разными правами, правила приёмки и отгрузки, учёт, связь с бухгалтерией и поставщиками.

Поэтому в ТЗ на систему главное не страницы, а процессы. Кто что делает, в каком порядке, что происходит, если что-то пошло не так. Сайт можно описать картинками и списком разделов. Систему так не описать: самое важное в ней невидимо.

ТЗ решает три задачи:

• фиксирует границы. Что входит в работу, а что нет. Без этого любой спор о сроках превращается в спор о памяти;
• даёт основу для оценки. Разработчик не может честно назвать срок и бюджет, пока не понимает, сколько ролей, процессов и интеграций в системе;
• служит правилами приёмки. Готовую работу проверяют по пунктам ТЗ, а не по ощущениям.

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

Первый вопрос, который задают заказчики: составлять ли ТЗ по ГОСТу. Короткий ответ: не обязательно. Национальные стандарты в России по закону применяются добровольно. На практике ГОСТ становится обязательным, когда его прописали в договоре: тогда это уже условие сделки. Часто его требуют и в государственных закупках.

Чаще всего вспоминают два стандарта. ГОСТ 34.602-2020 описывает техническое задание на создание автоматизированной системы, то есть программы вместе с людьми и процессами вокруг неё. Он действует с 1 января 2022 года и заменил версию 1989 года. ГОСТ 19.201-78 из Единой системы программной документации описывает ТЗ на отдельную программу.

Даже если ГОСТ вам не нужен, одну идею из него стоит взять. В ГОСТ 34.602-2020 сказано, что требования должны быть единичными, непротиворечивыми, актуальными, выполнимыми, проверяемыми и однозначными. По-человечески: одно требование про одну вещь, без противоречий с другими пунктами, реальное и такое, что его можно проверить и понять только одним способом.

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

Структура зависит от задачи, но у большинства коммерческих систем набор разделов похожий. Вот рабочий шаблон, который подходит и для CRM, и для кабинета дилеров, и для складской программы.

Самые недооценённые разделы — «границы» и «перенос данных». Первый спасает от бесконечного «а ещё сделайте». Второй от сюрприза в последний месяц, когда выясняется, что двадцать тысяч клиентов в старой таблице записаны в пяти разных форматах.

Слабое ТЗ почти всегда выдают слова «удобно», «быстро», «гибко», «и т. д.». Каждый читает их по-своему. Хорошее требование можно проверить: открыть систему и сказать «да, работает так» или «нет».

Числа в правой колонке условные. Важно не их значение, а то, что они вообще есть. Когда в ТЗ записано «2 секунды», обе стороны знают, что проверять.

Хороший пример измеримого требования — кабинет дилеров MMB Russia. Лицензия в нём генерируется за секунду. А для защиты там работает контроль IP-адресов с автоматической блокировкой. Такие вещи невозможно сделать «примерно»: их либо описали правилом, либо нет.

Процессы удобно описывать сценариями. Сценарий — это короткая история: кто, что делает, что отвечает система. Если в процессе есть ветки, их описывают отдельно: что будет, если товара нет, если клиент отказался, если связь с 1С пропала.

Почти любая система для бизнеса обменивается данными с другими программами: 1С, CRM, платёжным сервисом, телефонией, сервисами поставщиков. И почти в любом проекте именно интеграции дают самые неприятные сюрпризы.

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

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

Вопрос «какая система главная» кажется формальным, но на нём ломается половина интеграций. Если цены можно поменять и в 1С, и в новой системе, через месяц никто не знает, какая цена правильная.

В том же кабинете дилеров MMB Russia интеграций несколько: обмен с сервисами DriveMods и HUMAX по API и оплата через АТОЛ Pay. API — это способ, которым программы автоматически обмениваются данными без участия человека. Для каждой такой связи в ТЗ нужен свой раздел. Как мы подходим к обмену с учётными системами, можно посмотреть на странице об интеграции с 1С и CRM.

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

Функция: оформление заказа дилером.

Кто: дилер с активным договором.

Основной сценарий:

1. Дилер открывает каталог и видит цены по своему договору и остатки на складе.
2. Добавляет товары в корзину и указывает адрес доставки из списка своих адресов.
3. Нажимает «Отправить заказ». Система проверяет остатки и кредитный лимит дилера.
4. Заказ получает номер и статус «На согласовании», менеджер дилера получает уведомление.
5. После подтверждения менеджером заказ уходит в 1С, статус меняется на «В работе».

Исключения: если товара не хватает, система предлагает отгрузить то, что есть, или поставить остаток в резерв. Если превышен кредитный лимит, заказ сохраняется, но не отправляется, а дилер видит причину.

Как проверить: оформить заказ тестовым дилером в трёх вариантах: товар в наличии, нехватка товара, превышен лимит. В каждом случае статус, уведомления и данные в 1С соответствуют описанию.

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

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

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

Для больших систем не стоит пытаться описать всё сразу. Пока вы пишете ТЗ на два года вперёд, процессы успеют поменяться. Лучше подробно описать первую версию, которая решает главную задачу, а остальное собрать в список следующих этапов. Как выбрать, что войдёт в первую версию, мы рассказывали в статье про MVP в разработке.

Так работают и при разработке ПО на заказ, и при внедрении больших систем вроде ERP. ERP — это программа, которая объединяет закупки, склад, производство и финансы в одном месте. Чем больше процессов, тем важнее делить проект на понятные этапы со своим ТЗ.

Перед подписанием пройдите по короткому списку.

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

Начните с целей и границ, опишите роли и процессы вместе с ошибками, отдельно разберите каждую интеграцию. И перечитайте документ с вопросом «как мы это проверим?». Если ответа нет, требование надо переписать.