Кратко: Структура опирается на принятую для документов требований (IEEE 830 и ISO/IEC/IEEE 29148): введение и границы, общее описание, детальные требования и проверка. Мы добавили к ней три вещи, которых в реальных проектах не хватает чаще всего: таблицу ролей и прав, список того, что не входит, и критерии приёмки для каждого требования в проверяемой форме. ТЗ без критериев приёмки это описание намерений, а не спецификация.
Структура
| # | Раздел | Что в нём пишут |
|---|
| 1 | Цель и границы | Бизнес-задача в одном-двух предложениях, кто пользователи, что входит в эту версию и что не входит |
| 2 | Термины | Каждый бизнес-термин документа с одним определением. Если команда называет одно и то же двумя словами, здесь выбирают одно |
| 3 | Пользователи и роли | Таблица: роль, что видит, что меняет, что ей запрещено |
| 4 | Процессы | Основные бизнес-процессы по шагам, включая то, что происходит, когда что-то идёт не так |
| 5 | Функциональные требования | Пользовательская история на каждую возможность и к каждой истории критерии приёмки |
| 6 | Модель данных | Сущности, важные поля, связи и кто источник каждого поля |
| 7 | Интеграции | Внешние системы, что передаётся, в каком направлении и что происходит, когда они недоступны |
| 8 | Нефункциональные требования | Производительность, доступность, безопасность, приватность, доступность для людей с ограничениями, языки |
| 9 | Проверка | Как проверяется каждое требование: сценарии, тестовые данные, кто утверждает |
| 10 | Приложения | Примеры экранов, существующие отчёты, примеры файлов |
Раздел 1: что не входит
Список того, что не входит, важен не меньше списка того, что входит. Без него каждая сторона заполняет дыру своим ожиданием: заказчик думает, что будет приложение, разработчик думает, что только сайт. Короткий список «в этой версии нет» снимает большую часть споров в конце проекта.
Раздел 3: роли и права
Этот раздел чаще всего пропускают, и именно в нём рождаются уязвимости. Пример структуры:
| Роль | Видит | Меняет | Запрещено |
|---|
| Клиент | Свои заказы | Свои данные | Видеть заказы других клиентов |
| Сотрудник поддержки | Заказы своих клиентов | Статус заказа | Удалять заказ, менять цену |
| Менеджер | Всё | Всё, кроме истории платежей | Менять проведённый платёж |
Для каждой строки в столбце «запрещено» пишут сценарий проверки в разделе 9. Если сценария нет, нет и способа знать, что запрет действительно работает.
Раздел 5: требования, которые можно проверить
Каждое требование записывают как пользовательскую историю и как критерий приёмки. Распространённая форма: дано состояние, когда происходит действие, тогда система отвечает так.
Пример. Дан вошедший клиент с двумя открытыми заказами; когда он открывает список заказов, тогда он видит только свои два заказа, от нового к старому.
«Система должна быть удобной» это не требование, потому что его нельзя проверить. «Заказ отправляется не больше чем за три нажатия с главного экрана» это требование.
Раздел 8: что в Израиле забывают
- Иврит и письмо справа налево, включая поля, где смешаны иврит и английский, и числа внутри ивритского текста.
- Номер теудат зеут с контрольной цифрой и номер плательщика НДС.
- НДС и счета, включая номер распределения (מספר הקצאה) для счетов выше порога.
- Рабочая неделя с воскресенья по четверг и праздники, если в системе есть время, очереди или смены.
- Тиккун 13 к закону о защите приватности: какие персональные данные хранятся, кто к ним обращается и как это журналируется.
- Доступность для людей с ограничениями по израильскому стандарту, если система обращена к публике.
Как пользоваться шаблоном
- Начинают с разделов 1 и 3: что строим, что нет и кто что может делать.
- Процессы описывают раньше требований. Требования без процесса описывают экраны, а не работу.
- К каждому требованию критерий приёмки добавляют сразу, а не в конце.
- Модель данных сверяют с отчётами, которые нужны бизнесу: каждый отчёт должен вытекать из хранимых данных.
Если разработка идёт с AI-инструментами, тот же документ работает и как спецификация для инструмента. Нужно только следить, чтобы в нём было явно прописано всё, что человек обычно понимает из контекста.
Частые вопросы
Что должно быть в техническом задании?
Цель и границы, термины, пользователи и роли с правами, процессы, функциональные требования с критериями приёмки, модель данных, интеграции, нефункциональные требования и план проверки.
Чем ТЗ отличается от документа требований?
В повседневной практике это обычно один документ. Стандарты различают бизнес-требования, требования к системе и спецификацию ПО, но для проекта среднего размера достаточно одного упорядоченного документа.
Сколько страниц должно быть в ТЗ?
Столько, чтобы разработчик строил, не угадывая, а заказчик проверял, не споря. Число страниц важно меньше, чем то, что у каждого требования есть критерий приёмки и права записаны.
Какая самая частая ошибка в ТЗ?
Требования, которые нельзя проверить, отсутствие списка того, что не входит, и отсутствие таблицы прав. Все три всплывают только в конце проекта, когда исправлять дороже всего.
Можно ли использовать такое ТЗ с AI-инструментами разработки?
Да. Документ с границами, критериями приёмки, моделью данных и правами это ровно то, что нужно инструментам вроде Claude Code и Lovable, чтобы не заполнять дыры догадками.
С чего начать
Заполните сами разделы 1 и 3: что строим, что нет и кто что может делать. Пришлите мне, и мы продолжим оттуда к процессам и требованиям.
Написать мне
По теме: Разработка и внедрение CRM, Спецификация перед разработкой с AI, IT-консалтинг