Приложение. Форма обоснования мероприятий по информатизации и функциональные требования к мероприятию по информатизации "Наименование мероприятия по информатизации"

Приложение
к Порядку реализации мероприятий
по информатизации, утвержденному
приказом Минэкономразвития России
от 18.08.2023 г. N 581

I. Форма обоснования мероприятий по информатизации

Таблица 1

Общие сведения о мероприятии по информатизации

Параметр	Характеристика
Наименование мероприятия по информатизации	Указывается наименование мероприятия по информатизации
Сроки реализации мероприятия по информатизации	С даты заключения контракта по "___" _________ 202_ г.
Функциональный заместитель Министра	Ф.И.О. заместителя Министра, в подчинении которого находится функциональный заказчик
Функциональный заказчик	Наименование департамента - инициатора мероприятий по информатизации
Цель, задачи, ожидаемый эффект	Указываются причины, в связи с которыми необходима реализация мероприятия по информатизации, основные цели и задачи на решение которых направлено мероприятие по информатизации, экономический эффект реализации мероприятия по информатизации
Источники данных для информационных систем (ИС)	Описание источников данных из иных ИС, реестров данных, информационных ресурсов в информационно-телекоммуникационной сети "Интернет" и т.д. (перечислить)
Интеграция с иными информационными системами	Описание потребности в интеграции с иными ИС (перечислить)

Таблица 2

Содержание мероприятия по информатизации

Показатели результативности	Единица измерения (шт., чел., %)	Начальное значение показателя (текущий год)	Значение показателей результативности			Объем финансирования (тыс. руб.)
			текущий финансовый год	очередной финансовый год	плановый период	текущий финансовый год	очередной финансовый год	плановый период
Описание показателей результативности мероприятия по информатизации, сформулированных с учетом целей цифровой трансформации, предусмотренных постановлением Правительства Российской Федерации от 10 октября 2020 г. N 1646 "О мерах по обеспечению эффективности мероприятий по использованию информационно-коммуникационных технологий в деятельности федеральных органов исполнительной власти и органов управления государственным и внебюджетными фондами"	...	...	...	...	...	...	...	...
Например, "Доля реестров данных, автоматизированных в подсистеме сбора и хранения данных (ЕХД)"	%	30	50	70	80	25 000,00	50 000,00	50 000,00
Методика расчета показателя	Например, DR = Rцт / Rт * 100%, где DR - доля реестров данных, автоматизированных в ЕХД; Rцт - количество реестров данных, автоматизированных в ЕХД по итогам цифровой трансформации государственной функции; R - общее количество реестров данных Минэкономразвития России

II. Функциональные требования к мероприятию по информатизации "Наименование мероприятия по информатизации"

Перечень используемых терминов, сокращений и их значение

Термин/сокращение	Значение
...	...

1. Нормативные и методические документы

1.1. Нормативные правовые акты.

Указываются нормативные правовые акты (далее - НПА), которые определяют содержание деятельности и (или) процессов, которые подлежат автоматизации в рамках функциональных требований. Сведения о НПА предоставляются только в том случае, если они необходимы и являются определяющими с точки зрения работ/услуг по автоматизации.

1.2. Методические и иные документы, определяющие требования и ограничения к процессам, подлежащим автоматизации.

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

2. Требования к результату мероприятия по информатизации
(обязательный к заполнению раздел)

В настоящем разделе приводится описание требований (бизнес-требований, бизнес-правил, функциональных и иных видов требований), предъявляемых к результатам работ/услуг (разрабатываемому решению).

2.1. Бизнес-процесс или функциональные требования.

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

2.2. Общее описание автоматизируемых бизнес-процессов и их участников, модели взаимодействия и порядка обработки данных.

2.2.1. Наименование бизнес-процесса.

Вместо настоящего текста указывается наименование автоматизируемого бизнес-процесса.

2.2.2. Описание (логика бизнес-процесса).

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

В форме диаграмм в нотации BPMN либо в свободной форме, но содержательно позволяющей составить исчерпывающее представление о процессах. Описание должно включать в себя смежные процессы, если это важно для однозначного понимания задачи.

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

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

Должна быть понятна последовательность действия пользователя при работе с подсистемой/компонентом. Должны быть сформулированы требования к пользовательскому интерфейсу, если необходимо.

Если в рамках разрабатываемой задачи предполагается процесс согласования/утверждения, это также должно быть пошагово описано с указанием соответствующих ролей пользователей.

2.2.3. Участники взаимодействия и их роли.

Вместо настоящего текста должно быть приведено описание ролевой модели в рамках автоматизируемого процесса.

2.2.4. Схема взаимодействия.

Вместо настоящего текста приводится (при необходимости) схема взаимодействия участников.

2.2.5. Описание смежных видов деятельности.

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

2.2.6. Описание основных сущностей.

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

2.3. Входные данные.

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

Для каждого набора данных формируется отдельное описание.

2.3.1. Состав входной информации.

Вместо настоящего текста указывается состав наборов входных данных (документов).

2.3.2. Наименование набора данных.

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

2.3.2.1. Описание входной информации.

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

2.3.2.2. Формат.

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

2.3.2.3. Способ загрузки.

Вместо настоящего текста указывается предпочтительный способ загрузки исходной информации в систему: ручной ввод (загрузка), автоматизированный ввод (загрузка), загрузка по утвержденному шаблону, автоматизированная передача данных из ИС.

2.3.2.4. Владелец.

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

2.3.2.5. Статусная модель.

2.4. Выходные данные.

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

2.5. Нефункциональные требования.

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

3. Роли и права доступа пользователей

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

4. Критерии проверки результатов работ/услуг

Вместо настоящего текста приводятся (при наличии) показатели, которые следует использовать в программе и методике испытаний для проверки результатов работ/услуг по заявке.