ТЗ и спецификация: в чём разница между документами

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

Техническое задание

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

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

Спецификация

Спецификация требований — детальное описание того, как именно система должна себя вести. В ней каждое требование имеет номер, точную формулировку, приоритет, источник и критерий проверки. Отдельно могут существовать спецификация API (адреса, методы, поля запросов и ответов), спецификация данных, спецификация интерфейсов.

Читатели спецификации — разработчики, тестировщики, аналитики. Язык — точный, местами формальный.

Главные различия

Как они связаны

Удобная схема: ТЗ задаёт рамки, а спецификации раскрывают каждую функцию. Например, в ТЗ написано: «система принимает оплату через Payme и Click». В спецификации интеграции будет описано, какие запросы отправляются, какие статусы оплаты бывают, что происходит при отмене и как система сверяет платежи. Требования спецификации должны ссылаться на пункты ТЗ, чтобы было видно, откуда они взялись.

Когда хватает одного документа

Для небольшого проекта — сайт компании, простой бот, лендинг — достаточно одного подробного ТЗ. Отдельная спецификация появится, если есть интеграции с внешними системами: их описание удобнее держать отдельно.

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

Признаки, что вы получили не то

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

Практические советы

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

Пример фрагментов обоих документов

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

Итог

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