Самым грубым образом можно разделить документы на два уровня:
- Высокоуровневые, которых достаточно для понимания конечного результата.
- Детальные, которые полностью описывают, что и как должно быть сделано.
Вторые не всегда нужны, если в проекте работают опытные разработчики, находящиеся в бизнес-контексте (внутренняя команда разработки).
Вторые обязательны, если Вы работаете с внешним подрядчиком или фиксируете стоимость проекта. А это, обычное дело, если Вы закупаете услуги по конкурсной процедуре.
Разбираясь глубже, можно было бы выделить массу видов спецификаций, но есть сложности не только с именованием как таковым, а что во что входит. Например, варианты использования и другие UML-диаграммы это могут быть отдельные документы, а могут включаться в ТЗ. Причём, иногда как отдельные части, а иногда внутри других разделов. Тоже самое происходит с текстовыми частями.
Некоторые поставщики, помимо исходного ТЗ, настаивают на собственном ТЗ и на различных видах исполнительной документации. Это всё порождает многообразие того, как комплект технической документации может быть составлен. Тут, на практике, стандарта не получается.
Можно разделить всё документы, используемые в процессе разработки, на:
- Протоколы встреч и согласований
- Документы бизнес-требований
- Документы архитектурного решения
- Документы обоснований
- Функциональные требования и технические задания
- Прочие технические спецификации
- Прочие документы
Технические задания помимо функциональных требований включают, разумеется, нефункциональные (к быстродействию, способности обеспечить заданную нагрузку, технологические и т.п.), а также концептуальные части.
Аналитики из крупных банков рассказывали мне, что у них есть три категории документов:
- Документы бизнес-требований (они их называют BRD — Business Requirements Document).
- Архитектурный документ.
- Спецификации (они их называют 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.
Поведение модели предметной области нужно описать так, чтобы команда разработки могла реализовать юнит-тесты по этим требованиям.
Формат не претендует на пригодность во всех случаях жизни, но во многих из них поможет.
Можно скачать шаблон ТЗ с примерами заполнения.