Техническое задание и спецификация требований

Что входит в техническое задание и чем оно отличается от спецификации — вопрос, где легко утонуть в ГОСТах и потерять суть.

Техническое задание отвечает на вопрос «что и зачем делаем» и служит основанием для приёмки. Спецификация требований детализирует «как система себя ведёт» и служит рабочим документом команды.

Вопрос 1. Что должно быть в техническом задании?

Что проверяют. Умеете ли вы собрать документ, по которому можно принять работу. Заучивать разделы ГОСТ 34.602 наизусть не нужно — нужно назвать блоки и объяснить, зачем каждый.

• Основания и цели. Зачем проект существует и какую бизнес-задачу закрывает. Без этого раздела спор о любой фиче не имеет критерия разрешения.
• Термины и определения. Единый словарь. «Заказ», «сделка», «клиент» у трёх отделов означают разное — это надо зафиксировать до первого требования.
• Границы системы (scope). Что входит и — обязательно! — что явно не входит. Раздел «вне рамок» экономит месяцы споров.
• Роли и права. Кто работает в системе и что каждой роли доступно.
• Функциональные требования. Сгруппированные по подсистемам, пронумерованные, атомарные.
• Нефункциональные требования. Производительность, доступность, безопасность, совместимость — с метриками.
• Интеграции. С какими системами, в какую сторону, каким протоколом, кто владелец контракта.
• Данные. Ключевые сущности, объёмы, миграция, требования к хранению и архивации.
• Ограничения и допущения. Технологический стек, законодательство, инфраструктура, а также то, что мы приняли за истину без проверки.
• Порядок приёмки. Как проверяем, что работа сделана: этапы, состав испытаний, критерии.

Раздел «вне рамок» стоит проговорить отдельно — это признак опыта:

4.3. Вне рамок первого этапа

• мобильное приложение (только адаптивная вёрстка веб-версии);
• интеграция с 1С:ЗУП (планируется на втором этапе);
• перенос архива заказов старше 2023 года
  (остаётся доступным в старой системе на чтение);
• многоязычный интерфейс (только русский язык).

Вопрос 2. Чем ТЗ отличается от спецификации, ЧТЗ и user story?

Что проверяют. Ориентируетесь ли вы в типах документов и не пишете ли всё «одним большим вордом».

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

Вопрос 3. Как вы структурируете описание одной функции?

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

ФТ-210. Отмена заказа менеджером

Назначение   Менеджер отменяет заказ до отгрузки, чтобы не тратить
             ресурс склада на ненужные позиции.
Роли         Менеджер заказов, Руководитель отдела продаж
Предусловия  Заказ существует; статус «Новый» или «Оплачен»
Основной сценарий
  1. Пользователь открывает карточку заказа.
  2. Нажимает «Отменить», выбирает причину из справочника
     и вводит комментарий (обязателен, от 10 символов).
  3. Система переводит заказ в статус «Отменён».
  4. Для оплаченного заказа создаётся заявка на возврат.
  5. Клиенту отправляется уведомление на email.
Альтернативы и исключения
  2а. Причина не выбрана → сообщение «Укажите причину», отмена
      не выполняется.
  3а. Заказ уже перешёл в статус «В сборке» другим пользователем →
      сообщение «Заказ передан в сборку, отмена невозможна»,
      карточка обновляется.
  4а. Сервис возвратов недоступен → заказ всё равно отменяется,
      заявка ставится в очередь повтора, событие в журнале.
Постусловия  Статус «Отменён»; запись в журнале (кто, когда, причина);
             резерв склада снят.
Данные       см. сущность «Заказ», поля status, cancel_reason,
             cancelled_by, cancelled_at
Связанные    ФТ-211 (возврат средств), НФТ-PERF-04 (отклик <= 1 c)

Обратите внимание на пункт 4а: описано поведение при недоступности смежного сервиса. Именно такие пункты отличают спецификацию от пересказа демо.

Что делает документацию живой

• Единый источник истины. Одно требование живёт в одном месте; в остальных — ссылка. Скопированный в три документа текст расходится через месяц.
• Нумерация и версии. Разработчик и тестировщик ссылаются на ФТ-210, а не на «третий абзац сверху».
• Журнал изменений. Что изменилось, когда, по чьей инициативе.
• Ясные статусы. Черновик, на согласовании, утверждено, устарело.
• Регулярная чистка. Документ, которому не верят, хуже отсутствия документа: команда всё равно спросит устно, но потратит время на чтение.

Типичные ошибки кандидатов

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

Как ответить кратко

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