Я недавно участвовал в достаточно крупном чемпионате по системному анализу. В тройку победителей не попал (только 15-е место), но пообщался с классными ребятами, и посмотрел, как они пишут ТЗ или TDD (Technical Design Document) на разработку ИТ-решения - речь о развитии текущей системы (добавление новой функциональности). Все сводится к следующей универсальной структуре, с чем «спешу» с вами поделиться.
Исходные требования/проблематика/запросЧто мы хотим сделать и почему - с точки зрения пользователей системы.
В философию «ну вот это пользователю на самом деле не нужно, это нужно его бизнес-руководителям» уходить не будем, так как тянет на отдельный пост. Считаем, что мы уже сделали этот анализ и спустились на уровень пользователя (или «моря», как пишет в своей известной книге Коберн).
Текущее состояние и поведение системы (AS IS) Необходимо понимать функциональность и структуру системы для того, чтобы не упустить из виду неожиданное влияние от реализации Исходные требования/проблематика/запрос на бизнес-логику, атрибуты качества, архитектуру и процессы сбоку (например, развертывания и поддержки)
МотивацияПочему мы, в роли поставщика/разработчика продукта, хотим удовлетворить Исходным требованиям/проблематике/запросу.
Предлагаемое решение (TO BE)Структура ниже может отличаться в зависимости от содержания разделов выше.
🔷 Сценарии использования
Является набором функциональных требований в контексте решения пользователем задачи.
Можно пропустить эту часть, если вы можете сразу формализовать функции и алгоритмы. Но я рекомендую не пропускать этот шаг, как минимум для самоконтроля, как максимум, чтобы команда лучше понимала контекст автоматизируемых задач пользователя.
🔷 Роли и права доступа
Изменения прав доступа по текущим ролям/добавление новых ролей.
🔷 НФТ
Скорее всего они уже где-то описаны для системы, и достаточно их приложить, чтобы указанные лимиты/пороги не были нарушены. Если изменение требует пересмотра значений, то необходимо прежде убедиться, что это возможно и уже описать здесь новые показатели.
🔷 Сущности
Логическая модель данных, на которую вы будете:
- ссылаться при описании бизнес-логики
- опираться при проектировании интерфейсов и модели хранения данных. Несмотря на то, что вы сделаете это проектирование (см. далее разделы), важно оставлять команде «первоисточник» в целях стимулирования предложнений в части лучших проектировочных решений.
🔷 Функции и алгоритмы (бизнес-логика)
Как изменяются объекты системы при различных условиях и/или действиях пользователей.
🔷 Интерфейсы
Все точки вызова алгоритмов и функций. Например, API, UI, JMX и т.п.
🔷 Хранение данных
Моделирование данных под конкретную СУБД.
🔷 Архитектура
Требования к компонентам - как необходимо доработать компоненты (сервисы) системы, чтобы удовлетворить заявленным требованиям и связанным проектным решениям (например, интерфейсам). Это будет основой для последующей технической декомпозиции, которую делают разработчики для распараллеливания работ. Если добавляется новый компонент, то необходимо приложить обновленную схему архитектуры.
Межкомпонентные взаимодействия - описание того, как работают вместе компоненты системы внутри или с внешними сервисами (интеграции), с указанием того, какие функции инициируют процесс.
🔷 Инфраструктура
Любые изменения в области инфраструктурного ПО и вычислительных мощностей.
Например, добавление логирования новых запросов, или расширение мониторинга и списка алертов.
🔷 Конфигурация
Любые параметры, определяющие как будет работать функциональность функциональности, или вовсе включающие/отключающие функциональность (фичефлаги).
Кому нужен пример такой работы, то пишите в личку (скину свое
).
