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

Самым грубым образом можно разделить документы на два уровня:

  1. Высокоуровневые, которых достаточно для понимания конечного результата.
  2. Детальные, которые полностью описывают, что и как должно быть сделано.

Вторые не всегда нужны, если в проекте работают опытные разработчики, находящиеся в бизнес-контексте (внутренняя команда разработки).

Вторые обязательны, если Вы работаете с внешним подрядчиком или фиксируете стоимость проекта. А это обычное дело, если Вы закупаете услуги по конкурсной процедуре.

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

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

Можно разделить всё документы, используемые в процессе разработки, на:

  1. Протоколы встреч и согласований
  2. Документы бизнес-требований
  3. Документы архитектурного решения
  4. Документы обоснований
  5. Функциональные требования и технические задания
  6. Прочие технические спецификации

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

Аналитики из крупных банков рассказывали мне, что у них есть три уровня документов:

  1. Документы бизнес-требований (они их называют BRD — Business Requirements Document).
  2. Архитектурный документ.
  3. Спецификации на разработку (они их называют SRD — Software Requirements Document).

P.S. 2020 г. В МТС ИТ, где я работаю, архитектурный документ называется "Проект решения". Качество решения держится на единстве контекста в головах аналитиков и архитекторов.

Формат простого технического задания

Если Вы планируете разработку бизнес-приложения с веб-интерфейсом, хотите уложить все требования в один документ ТЗ и ищите формат, который позволит не забыть о важных вещах, могу предложить такой вариант:

  1. Термины и определения
  2. Введение
  3. Общие требования
    3.1. Среда выполнения
    3.2. Серверная часть
    3.3. Браузерная часть
    3.4. Журналирование и телеметрия
  4. Контроль доступа пользователей и аудит
    4.1. Аутентификация и авторизация
    4.2. Права доступа и роли
    4.3. Аудит
  5. Пользовательский интерфейс
    5.1. Концепция
    5.2. Разделы и экранные формы
    5.2.x. [Название раздела]
    5.2.x. ...
  6. Модель предметной области
    6.x. [Название объекта]
    6.x. ...
  7. Периодические задания
    7.x. [Название джоба]
    7.x. ...
  8. Отчёты
    8.x. [Название отчёта]
    8.x. ...
  9. Интеграция и API
    9.1. Авторизация при взаимодействиях система-система
    9.2. Сценарии взаимодействий
    9.3. Предоставляемые API
    9.4. Вызываемые API

Можно скачать шаблон ТЗ с примерами заполнения.

Однако, имейте ввиду, что в зависимости от ситуации (микросервисный бэкенд или монолитный, SPA или MVC, сценарии внешних взаимодействий и ваш текущий ИТ ландшафт, есть ли отдельная стадия проектирования UI и какой уровень описания требований нужен для неё) некоторые части ТЗ должны получить сильный фокус внимания, а некоторые можно удалить. Шаблон — это только напоминалка.