Потребность в данном документе возникает, когда доработке подвергается сразу несколько интегрированных друг с другом систем.
Проектное решение (Solution Design) составляется на основе: Бизнес- и Пользовательских требований, иногда на основе Vision (видения, концепции).

Цепочка аналитических артефактов и место Проектного решения в ней:

Памятка, создавал для себя:

(опционально) Используемые термины

ИС — информационная система.
...

Суть решения

Приводится краткое описание сути решения, позволяющее определить, как изменится ИТ-ландшафт в результате внедрения проектного решения, какую проблему это решит и какие цели будут достигнуты.

Сценарии использования решения

Содержание раздела должно отвечать на вопросы:

• какие функциональные возможности реализует проектное решение?
• кто и как будет использовать их после внедрения?

Описывается:

• какие пользователи (Роли) будут работать с новым/измёненным решением;
• сценарии использования (Use cases) решения (основной и важные альтернативные). Use cases разрабатываются на основе Бизнес-требований и модели "ToBe" Бизнес-процессов, приведённых в концепции;
• основные пользовательские и системные функции.

Например:

#	Acteur (Действующее лицо)	Verbe (Шаг, действие)	Objet (Объект воздействия)	Objectif (Целевой объект)
1	Клиент	подаёт	заявку на Продукт/Услугу	эксперту в офисе
2	Эксперт	регистрирует	заявку	Карточка Клиента в Системе
3	Система	присваивает	номер заявки	Карточка Клиента в Системе
N	...	...	...	...

Архитектура проектного решения

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

Могут быть приведены несколько вариантов проектного решения. В этом случае должны быть описаны достоинства и недостатки каждого варианта.

• Модель + Описание (если требуется). Описание может включать в себя:
  • cсылки на архитектурное описание существующих компонентов (н-р, "для реализации этого кейса мы используем существующий компонент Системы1")
  • ссылки на раздел с описанием интеграционного слоя (н-р, если у нас новый интерфейс, либо старый изменился)
  • перечень необходимого оборудования
• Достоинства / Недостатки

Логическое представление

Для описания логической модели проектного решения может быть использован язык моделирования Archimate, любой понятный вам и команде, или какой-то принятый в вашей организации в качестве обязательного стандарта. Модель должна демонстрировать:

• все перечисленные use cases;
• какими компонентами слоя приложений будут реализованы use cases;
• возможные изменения в инфраструктуре.

Например: (скачать модель в .archimate)

Физическое представление

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

Интеграционные потоки

Приводится перечень предполагаемых интерфейсов интеграции информационных систем и сервисов.
Например:

Действие в бизнес/системной логике	Инициатор взаимодействия	Поток данных		Тип взаимодействия	Протокол	Формат данных
		из	в
Запрос в систему2 для чего-то там	Система1	Система1	Система2	(а)синхронный Request-Response, MQ	HTTP RESTful / FTP / file / (g)RPC / ...	XML / JSON / CSV / plain text / ...

Потребность в оборудовании и его лицензировании

Отражается потребность в оборудовании для функционирования проектируемого решения. Если описаны несколько вариантов реализации, то возможная потребность в оборудовании указывается для каждого варианта.

Предназначение	кол-во	Характеристики	Окружение, ПО
Web сервер	2	CPU: 16vCPU; RAM: 32Gb SSD: 100Gb	Windows Server 2012 R2

При необходимости, указывается потребность в лицензиях на оборудование/ПО. Потребность в лицензировании влияет на оценку стоимости проектного решения. Приводится для каждого варианта решения.

Оценка решения

Оценка приводится для каждого варианта решения. В оценке должно быть указание на то, в каких ИС потребуются доработки.
Например:

Функциональность (use case)	Система1	Система2	Система3
Печать заявки	+ (30 т.р.)
Фотографирование Клиента	+ (35 т.р.)
Отправка запроса в ПФР		+ (25 т.р.)
Выпуск дебетовой карты			+ (90 т.р.)
ИТОГО:	65 т.р.	25 т.р.	90 т.р.

ИЛИ

№	Состав работ	Трудоёмкость, ч/дн	Стоимость, руб. без НДС
1	Аналитика	220	0,000,000.00
2	Разработка	340	0,000,000.00
3	Тестирование	260	0,000,000.00
4	DevOps	60	0,000,000.00
5	Проектное управление	120	0,000,000.00
6	Риски (10%)	-	0,000,000.00
7	Командировочные расходы	-	0,000,000.00
ИТОГО:		1000	0,000,000.00

И/ИЛИ

Трудозатраты по Системе1	XXX
Трудозатраты по Системе2	XXX
Трудозатраты по Системе3	XXX
Трудозатраты по Системе4	XXX
Асинхронные развязки при обработке команд	+
Маршрутизация, брокер очередей	+
Гарантированная доставка информации по процессам в конечную систему	+
Главный плюс решения:	что-то там
Минусы решения	Добавляется ещё одна ИС (набор микросервисов), которую надо дорабатывать, тестировать и обслуживать. Потребуется закупать мощности для развёртывания и включения в текущие промышленные и тестовые контуры. ...

Эту таблицу можно использовать для демонстрации Заказчику сравнения вариантов решения для дальнейшего выбора.

Декомпозиция работ

Этот пункт добавляется, когда вариант решения выбран и следует распределить задачи по исполнителям.
Указывается список задач верхнего уровня для бэклога по каждой информационной системе, требующей доработок согласно проектному решению. Для каждой информационной системы должна быть одна входная задача, содержащая общую постановку того, что нужно сделать в данной системе. На основе этой задачи создаются Change Requests на доработки, по которым разрабатываются спецификации на изменения.
Например:

ИС	# задачи в СУЗ	Сервис / Бизнес-функция (берётся из Archimate-модели решения)	Функциональность (берётся из разработанных use cases)
Учётная система	XXXX	веб-сервис проверки наличия у Клиента ИНН	отправка запроса к веб-сервису ПФР обработка данных ответа
Учётная система	YYYY	выпуск дебетовой карты и заполнение справочников	...