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

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

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

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

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

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

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

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

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

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

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

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

Один из возможных вариантов может выглядеть так:

1. Введение
2. Термины и определения
3. Общие требования
3.1. Среда выполнения
3.2. Серверная часть (Back-end)
3.3. Браузерная часть (Front-end)
3.4. Журналирование и телеметрия
4. Контроль доступа и аудит
4.1. Аутентификация и авторизация
4.2. Права доступа и роли
4.3. Аудит
5. Пользовательский интерфейс
5.1. Концепция
5.2. Разделы и экранные формы
5.2.x. [Название раздела]
6. Модель предметной области
6.x. [Название объекта или перечисления]
7. Периодические задания
7.x. [Название]
8. Внешние API
8.x. [Название]

Список можно продолжать другими разделами, например "Отчёты".

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

Среди функциональных требований, на мой взгляд, просматриваются три большие группы:

I) Те, которые относятся к поведению модели предметной области.

II) Те, которые относятся к пользовательскому интерфейсу.

III) Прочие, типа периодических заданий, отчётов, и внешних API.

Поведение модели предметной области нужно описать так, чтобы команда разработки могла реализовать юнит-тесты по этим требованиям.

Формат не претендует на пригодность во всех случаях жизни, но во многих из них поможет.

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