Написание технических заданий, требований и спецификаций
Самым грубым образом можно разделить документы на два уровня:
- Высокоуровневые, которых достаточно для понимания конечного результата.
- Детальные, которые полностью описывают, что и как должно быть сделано.
Вторые не всегда нужны, если в проекте работают опытные разработчики, находящиеся в бизнес-контексте (внутренняя команда разработки).
Вторые обязательны, если Вы работаете с внешним подрядчиком или фиксируете стоимость проекта. А это обычное дело, если Вы закупаете услуги по конкурсной процедуре.
Разбираясь глубже, можно было бы выделить массу видов спецификаций, но есть сложности не только с именованием как таковым, а что во что входит. Например, варианты использования и другие UML-диаграммы это могут быть отдельные документы, а могут включаться в ТЗ. Причём, иногда как отдельные части, а иногда внутри других разделов. Тоже самое происходит с текстовыми частями.
Некоторые поставщики, помимо исходного ТЗ, настаивают на собственном ТЗ и на различных видах исполнительной документации. Это всё порождает многообразие того, как комплект технической документации может быть составлен. Тут, на практике, стандарта не получается.
Можно разделить всё документы, используемые в процессе разработки, на:
- Протоколы встреч и согласований
- Документы бизнес-требований
- Документы архитектурного решения
- Документы обоснований
- Функциональные требования и технические задания
- Прочие технические спецификации
Технические задания помимо функциональных требований включают, разумеется, нефункциональные (к быстродействию, способности обеспечить заданную нагрузку, технологические и т.п.), а также концептуальные части.
Аналитики из крупных банков рассказывали мне, что у них есть три уровня документов:
- Документы бизнес-требований (они их называют BRD — Business Requirements Document).
- Архитектурный документ.
- Спецификации на разработку (они их называют SRD — Software Requirements Document).
P.S. 2020 г. В МТС ИТ, где я работаю, архитектурный документ называется "Проект решения". Качество решения держится на единстве контекста в головах аналитиков и архитекторов.
Формат простого технического задания
Если Вы планируете разработку бизнес-приложения с веб-интерфейсом, хотите уложить все требования в один документ ТЗ и ищите формат, который позволит не забыть о важных вещах, могу предложить такой вариант:
- Термины и определения
- Введение
- Общие требования
3.1. Среда выполнения
3.2. Серверная часть
3.3. Браузерная часть
3.4. Журналирование и телеметрия - Контроль доступа пользователей и аудит
4.1. Аутентификация и авторизация
4.2. Права доступа и роли
4.3. Аудит - Пользовательский интерфейс
5.1. Концепция
5.2. Разделы и экранные формы
5.2.x. [Название раздела]
5.2.x. ... - Модель предметной области
6.x. [Название объекта]
6.x. ... - Периодические задания
7.x. [Название джоба]
7.x. ... - Отчёты
8.x. [Название отчёта]
8.x. ... - Интеграция и API
9.1. Авторизация при взаимодействиях система-система
9.2. Сценарии взаимодействий
9.3. Предоставляемые API
9.4. Вызываемые API
Можно скачать шаблон ТЗ с примерами заполнения.
Однако, имейте ввиду, что в зависимости от ситуации (микросервисный бэкенд или монолитный, SPA или MVC, сценарии внешних взаимодействий и ваш текущий ИТ ландшафт, есть ли отдельная стадия проектирования UI и какой уровень описания требований нужен для неё) некоторые части ТЗ должны получить сильный фокус внимания, а некоторые можно удалить. Шаблон — это только напоминалка.