Функционально-технические требования к системе электронного документооборота (стр. 3 )

Требования к доступности и производительности

Требования к доступности системы (суммарное допустимое время простоя)	Режим работы системы должен обеспечивать возможность ввода данных в рабочее время на любом обслуживаемом предприятии в режиме 8х5. Учитывая, территориальное распределение филиалов. Предполагаемый режим доступности продуктивной системы – 24х7. Процент доступности системы = 99,45% (время простоя на проведение регламентных работ = 48 часов/год).
Максимальное время восстановления после сбоя и максимальное окно потери данных	Максимально допустимое время восстановления функционирования системы после аппаратного/программного сбоя или планового выведения системы из продуктивной эксплуатации (RTO) = 24 часа. Окно потери данных (RPO) = 24 часа.
Нагрузка	Объем хранения данных (планируемый объем данных, обрабатываемых системой, с учетом прогноза роста на ближайшие 5 лет) = 2 Тб. Планируемое кол-во зарегистрированных пользователей составляет: -Аэро», центральный офис г. Москва: 200 чел. -Аэро», филиал в а/п Красноярск: 40 чел. -Аэро», филиал в г. Артем: 50 чел. -Аэро», филиал в г. Санкт-Петербург: 10 чел.
Требования к каналам связи	Работоспособность каналообразующего оборудования должна быть обеспечена в режиме 24 часа в сутки 7 дней в неделю. Максимальное время восстановления работоспособности каналообразующего оборудования – 4 часа в случае аппаратного сбоя (при наличии резервного оборудования у Заказчика). Максимальное время восстановления работоспособности каналообразующего оборудования – 1,5 часа в случае программного сбоя. Требования к пропускной способности каналов связи: Соединение между клиентскими компьютерами и серверной частью системы со скоростью 100 Мбит/с; Соединение между серверами, входящими в состав аппаратной платформы системы, с полосой пропускания 1 Гбит/с.
Требования к резервному копированию и восстановлению	Цикл хранения резервных копий: ежедневный бэкап – срок хранения 1 неделя; еженедельный бэкап – срок хранения 1 месяц; ежемесячный бэкап – срок хранения 1 год; ежегодный бэкап – срок хранения 10 лет.
Другие требования к надежности	Тип подключения пользователей системы: клиентское ПО, использование web-клиента, использование терминального клиента.
Другие требования к надежности	Требования к системе хранения. Система хранения данных должна обеспечивать возможность хранения БД и соответствовать требованиям надежности и отказоустойчивости, предъявляемым к продуктивным системам в промышленной эксплуатации. Требования к резервному копированию. Система резервного копирования должна обеспечивать возможность выполнения восстановления БД Системы в течение 24 часов. Срок оповещения о проведении технологических работ - за неделю до планируемых работ.

ТРЕБОВАНИЯ К БЕЗОПАСНОСТИ

Категория конфиденциальности информации, обрабатываемой в информационной системе – «конфиденциальная».

Безопасность информации, обрабатываемой в информационной системе, обеспечивается аппаратными средствами и каналами связи со стороны Заказчика.

Доступ к ИС осуществляется только с рабочих станций, входящих в состав сегментов сети Компании, аттестованных для обработки информации конфиденциального характера или оборудованных персональными комплексами защиты информации ПКЗИ-КТ.

ТРЕБОВАНИЯ К АВТОМАТИЗАЦИИ
ОБЩИЕ ТРЕБОВАНИЯ К АВТОМАТИЗАЦИИ

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

Система должна быть доступна для работников -Аэро», включая филиалы.

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

В Системе должны быть реализованы проверки для минимизации ошибок, вызванных человеческим фактором. Полный перечень необходимых проверок должен быть определен в ТЗ на Систему.

Необходимо предусмотреть в Системе возможность ведения сложных реквизитов контрагентов, в том числе банковских; необходимо на этапе КД разработать алгоритм их подстановки в печатных формах, с учетом падежей (например, для подписантов).

Должна быть возможность вывода в отчеты указанных аналитик.

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

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

ТРЕБОВАНИЯ К ФОРМИРОВАНИЮ КОНТРОЛЬНОЙ СРЕДЫ

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

Для определения точных параметров контроля в рамках контрольной среды необходимо:

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

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

ТРЕБОВАНИЯ К ДАННЫМ

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

На этапе разработки ТЗ должны быть разработаны и согласованы с Заказчиком:

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

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

СВЯЗЬ С СУЩЕСТВУЮЩИМ ОКРУЖЕНИЕМ И ИНТЕГРАЦИЯ

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

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

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

Частота и содержание обмена данными со смежными системами и решениями (в рамках интеграции) должны быть определены на этапе формирования ТЗ.

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

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

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

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

ТРЕБОВАНИЯ К ПЕРЕНОСУ ДАННЫХ

Окончательный объем данных (объекты миграции) должен быть определен на этапе ТЗ исходя из процессного объема Решения.

В рамках работ по миграции данных из систем выводящихся из эксплуатации в рамках настоящего функионала необходимо: