Функциональные требования

ITG# 47905

«Консолидация архива клиентских дел МГТС»

ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ

Версия

1.4

1        ИСТОРИЯ ИЗМЕНЕНИЙ        1

2        СОГЛАСОВАНИЕ        2

3        ССЫЛКИ        2

4        ЦЕЛИ И НАЗНАЧЕНИЕ ДОКУМЕНТА        2

5        ГЛОССАРИЙ        2

6        БИЗНЕС ТРЕБОВАНИЯ        3

6.1        Предпосылки        3

6.2        Область применения и границы        3

6.3        Цели и задачи, преимущества для бизнеса и компании        3

6.4        Способ измерения полученных результатов        3

7        ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ        3

7.1        Требования к настройкам и справочникам        3

7.2        Требования к абонентскому делу        4

7.3        Требования к операции массового создания экземпляров сущности «Карточка документа»        7

7.4        Требования к операции массового изменения адреса хранения        7

7.5        Требования к отчетности        8

7.6        Требования к ролям пользователей        8

8        НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ И ОГРАНИЧЕНИЯ        9

8.1        Требования к СЭАКД        9

8.2        Производительность        9

8.3        Информационная безопасность        9

8.4        Требования к мониторингу        9

9        РИСКИ ИЗМЕНЕНИЯ        9

ИСТОРИЯ ИЗМЕНЕНИЙ

Версия	Дата	ФИО	Описание
1.0	09.10.2014		Создание документа
1.1	29.10.2014		Внесение исправлений по замечаниям
1.2	12.11.2014		Внесение исправлений по замечаниям
1.3	21.11.2014		Внесение исправлений по замечаниям
1.4	5.01.2015		Внесение исправлений по замечаниям БУЗ для RFI

СОГЛАСОВАНИЕ

Версия	Подразделение	ФИО	Компания	Дата завершения согласования	Статус согласования	Лист согласования
1.3	БРИТ/ОВБЗ		МГТС	27.11.2014	Согласовано

ССЫЛКИ

№	Название
1.	Заявка ITGC # 47905
2.	Шаблон отчета «Карточки документов»
3	Выписка из СТ-МГТС-027-2
4	EADDR

ЦЕЛИ И НАЗНАЧЕНИЕ ДОКУМЕНТА

Документ является приложением к Запросам (ITG # 47905), направленному на автоматизацию работы с абонентскими делами.

Целями разработки данного документа являются:

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

Данный документ может использоваться для:

подготовки системных требований; подготовки методики испытаний;

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

ГЛОССАРИЙ

Основные понятия, термины и сокращения, используемые в документе

Понятие	Определение	Ссылки на источники
BR	Business Requirement
eADDR	Информационная система, выполняющая функции централизованного адресного справочника МГТС
FR	Functional Requirement
OR	Other Requirement
СЭАКД	Система электронного архива клиентских дел

БИЗНЕС ТРЕБОВАНИЯ Предпосылки Планируется сокращение количество объектов хранения и миграция архивов на несколько площадок МГТС. Область применения и границы Данный документ описывает функциональные требования к ведению электронного каталога документов. В данных функциональных требованиях не определена ИС, в которой будет реализовываться электронный каталог. Для обозначения ИС используется термин СЭАКД. В данных функциональных требованиях не предполагается проверка корректности атрибутов «Карточки документа» с данными из других ИС. В данных функциональных требованиях предполагается, что в СЭАКД не будет осуществляться работа со спец-абонентами. В данных функциональных требованиях предполагается возможность выдачи оригиналов абонентского дела сотрудникам Отдела Судебной работы и Департамента по работе со специальными пользователями. Цели и задачи, преимущества для бизнеса и компании Высвобождение помещений, занимаемых под архив. Получение дополнительных доходов от сдачи в аренду высвобожденных помещений. Хранение информации о клиентских делах по всем абонентам в одном месте. Изменение принципа работы с архивом (сокращение времени на поиск дела, увеличение скорости обработки данных при работе с претензиями, создание электронного архива позволит осуществлять on-line доступ). Ограничение неавторизованного доступа к документам. Наполнение справочника «Адрес хранения» лежит в зоне ответственности подразделений, задействованных в бизнес-процессе. Способ измерения полученных результатов Сокращение времени доступа к клиентским делам МГТС и как следствие увеличение скорости и качества обслуживания абонентов. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ Требования к настройкам и справочникам В СЭАКД должны быть представлены справочники:

Типы документов Категории абонентов Историческая ценность Цель выдачи документа Адрес хранения Срок хранения документа

При инициализации, справочник «Типы документов» должен принимать значение:

Абонентское дело

При инициализации, справочник «Категории абонентов» должен принимать значения:

Квартирные Хозрасчетные Госбюджетные

При инициализации, справочник «Историческая ценность» должен принимать значения:

Обычный Исторический

При инициализации, справочник «Цель выдачи документа»1 должен принимать значения:

Претензия абонента Судебное разбирательство Обращение в офис

Справочник «Адрес хранения» должен иметь следующую структуру:

Адрес Комната Стеллаж Коробка Папка № п/п

Атрибуты справочника «Адрес хранения», за исключением атрибута «№ п/п» должны быть обязательными для заполнения. В справочнике «Адрес хранения» атрибут «Адрес» должен принимать значения из eADDR. (API eADDR представлен в приложении 1 ) При инициализации, справочник «Срок хранения документа» должен иметь значение согласно таблице 1:

Таблица 1. Справочник "Срок хранения документа"

Тип документа	Тип абонента	Срок хранения документа
Абонентское дело	Юр. лица	3650 дней
Абонентское дело	Физ. лица	1825 дней

Требования к абонентскому делу В СЭАКД должна быть добавлена сущность «Карточка документа». В СЭАКД должны быть доступны следующие операции для сущности «Карточка документа»:

Создание экземпляра сущности «Карточка документа» Поиск экземпляров сущности «Карточка документа» Изменение значений атрибутов экземпляра сущности «Карточка документа», в том числе и массовое изменение адреса хранения Изменение статуса экземпляра сущности «Карточка документа» Удаление экземпляра сущности «Карточка документа».

Сущность «Карточка документа» должна иметь статусы согласно таблице 2:

Таблица 2. Статусы сущности "Карточка документа"

Начальный статус	Конечный статус
Черновик	Актуальный
Актуальный	Выдан
На ревизии
Договор расторгнут
Выдан	Актуальный
На ревизии	Актуальный
Договор расторгнут	Удален

Экземпляр сущности «Карточка документа» должен создаваться в статусе «Черновик». Конечным статусом экземпляра сущности «Карточка документа» должен быть статус «Удален». Форма создания экземпляра сущности «Карточка документа» должна содержать атрибуты согласно таблице 3:

Таблица 3. Форма создания экземпляра сущности "Карточка документа"

Наименование атрибута	Источник	Обязательность заполнения
Телефон	Вводиться вручную в формате «+7-YYY-XXX-XX-XX»	да
Тип документа	Одно из значений из справочника «Типы документов»	да
ФИО/Наименование организации	Вводится вручную	да
Тип абонента	Одно из значений: Юр. лицо Физ. лицо	да
Категория абонента	Значение из справочника «Категории абонентов»	да
Договор	Вводится вручную	да
Адрес установки	Значение из EADDR	да
Адрес хранения	Значение из справочника «Адрес хранения»	нет
Реестр	Вводится вручную	нет
Историческая ценность (категория)	Значение из справочника «Историческая ценность». По умолчанию, должно принимать значение «Обычный»	да
Вложения	Интерфейс для прикрепления документов	нет
Комментарий	Текстовое поле	нет

Атрибут «Телефон» должен соответствовать шаблону «+7-YYY-XXX-XX-XX», где X – произвольная цифра, а YYY – ABC – код. ABC-код должен принимать значение 495, 498 или 499 и быть настраиваемым. Атрибуты сущности «Карточка документа»:

Телефон Договор Адрес хранения

должны быть уникальными.

Форма экземпляра сущности «Карточка документа» должна содержать атрибуты согласно таблице 4:

Таблица 4. Форма сущности "Карточка документа"

Наименование атрибута	Источник/Описание атрибута	Возможность редактирования
Телефон	Номер в формате «+7-YYY-XXX-XX-XX»	нет
АТС	Рассчитывается автоматически как 4-6 цифры маски номера телефона  (+7- YYY-XXX-XX-XX)	нет
Тип документа	Одно из значений из справочника «Типы документов»	нет
ФИО/Наименование организации	Текстовое поле	да
Тип абонента	Одно из значений: Юр. лицо Физ. лицо	да
Категория абонента	Значение из справочника «Категории абонентов»	да
Договор	Текстовое поле	да
Адрес установки	Значение из EADDR	нет
Адрес хранения	Значение из справочника «Адрес хранения»	да
Реестр	Текстовое поле	да
Историческая ценность (категория)	Значение из справочника «Историческая ценность»	да
Статус	Текущий статус «Карточки документа»	да
Дата создания карточки документа	Дата создания экземпляра сущности «Карточка документа»	нет
Цель выдачи	Значение из справочника «Цель выдачи абонентского дела»
Выдан	ФИО сотрудника, которому передается бумажная версия дела2	да
Вложения	Интерфейс для прикрепления документов, а также вложенные ранее документы	да
Комментарий	Текстовое поле	да

Для сущности «Карточка документа» должна быть возможность добавления пользовательских атрибутов. Изменение статуса экземпляра сущности «Карточка документа» должно осуществляться вручную. Изменение статуса экземпляра сущности «Карточка документа» со статуса «Черновик» должно быть доступно только при заполненном атрибуте «Адрес хранения». Изменение статуса с «Договор расторгнут» на «Удален» должно осуществляться с подтверждением. Для экземпляров сущности «Карточка документа», имеющих значение «Исторический» в поле «Историческая ценность», должна быть закрыта возможность  перевода в статус «Удален». При изменении статуса «Карточки документа» на значение «Выдан» обязательно должны быть заполнены поля «Цель выдачи» и «Выдан». При изменении статуса «Карточка документа» со значения «Выдан» должны автоматически очищаться поля «Цель выдачи» и «Выдан». В СЭАКД должна быть возможность поиска экземпляров сущности «Карточка документа» по:

Номеру телефона ФИО/Наименованию организации Номеру АТС Адресу установки Адресу расположения с детализацией до уровня комнаты, стеллажа, коробки, папки, № п/п Статусу

В СЭАКД должно осуществляться логирование управляющих действий (создание карточки документа, изменение статуса, изменение атрибутов, изменение адреса хранения). Требования к операции массового создания экземпляров сущности «Карточка документа» В СЭАКД должна быть доступна операция массового создания экземпляров сущности «Карточка документа». В СЭАКД при осуществлении операции массового создания экземпляров сущности «Карточка документа» карточки документов должны создаваться для всех абонентов из FF, имеющих открытый договор. В СЭАКД при осуществлении операции массового создания экземпляров сущности «Карточка документа» карточки документов должны создаваться согласно таблице 5:

Таблица 5. Создание экземпляра сущности "Карточка документа"

Наименование атрибута	Источник
Телефон	Абонентский номер из FF
АТС	Рассчитывается автоматически согласно алгоритму
Тип документа	«Абонентское дело»
ФИО/Наименование организации	Абонент из FF
Тип абонента	Тип абонента из FF
Категория абонента	Категория абонента из FF
Договор	Договор из FF
Адрес установки	Адрес установки из FF
Адрес хранения	-
Реестр	-
Историческая ценность (категория)	«Обычный»
Статус	«Черновик»
Дата создания карточки документа	Дата создания экземпляра сущности «Карточка документа»
Цель выдачи	-
Выдан	-
Вложения	-
Комментарий	-

Требования к операции массового изменения адреса хранения В СЭАКД должна быть доступна операция массового изменения адреса хранения для экземпляров сущности «Карточка документа». В СЭАКД для осуществления операции массового изменения адреса хранения должны быть указаны:

«Старый адрес хранения» «Новый адрес хранения»

«Старый адрес хранения» и «Новый адрес хранения» должны принимать значения из  справочника «Адрес хранения». «Старый адрес хранения» и «Новый адрес хранения» могут быть указаны до уровня детализации комната, стеллаж, коробка, папка или № п/п. В СЭАКД перед осуществлением операции массового изменения адреса хранения,  должна осуществляться проверка, что не существует экземпляров сущности «Карточка документа» в диапазоне3 значений «Нового адреса хранения». В случае, если такие экземпляры существуют,  пользователю должно выводиться соответствующее сообщение, операция массового изменения адресов хранения запускаться не должна. При осуществлении операции массового изменения адреса хранения должны отбираться экземпляры сущности «Карточка документа» с адресом хранения,  совпадающим со «Старым адресом хранения» до указанного уровня детализации (атрибуты адресах ранения более низкого уровня детализации могут быть любыми). При осуществлении операции массового изменения адреса хранения для отобранных экземпляров сущности «Карточка документа» автоматически должен изменяться адрес хранения на «Новый адрес хранения» до уровня детализации, указанного в интерфейсе операции массового изменения адреса хранения. При этом, атрибуты адреса хранения более низкого уровня детализации должны сохранять старые значения (Если изменяем местоположение стеллажей, то значения коробок, папок и № п/п должно оставаться прежним). Требования к отчетности В СЭАКД должен быть добавлен отчет:

Карточки документов.

Отчет «Карточки документов» должен иметь входные параметры:

Период формирования (даты «С» и «По») Тип документа Статус дела

Во входном параметре «Тип документа» должна быть возможность выбора одного значения. Во входном параметре «Статус дела» должна быть возможность выбора:

Одного значения Нескольких значений Ни одного значения (формировать отчет по всем статусам)

Отчет «Карточки документов» должен формироваться по экземплярам «Карточка документа», переведенных в указанный период на указанные статусы (переведенных в указанный период в любой статус при пустом значении параметра «Статус дела»). Отчет «Карточки документов» должен соответствовать шаблону, указанному в разделе 3. Выводимые данные в отчете «Карточки документов» должны быть отсортированы по дате изменения статуса (самые свежие - сверху). Требования к ролям пользователей В СЭАКД должны быть добавлены роли:

Оператор Поиск и просмотр Менеджер Администратор безопасности Администратор

Функциональные возможности ролей показаны в следующей матрице:

Функциональная возможность	Оператор	Поиск и просмотр	Менеджер	Администратор безопасности	Администратор
Создание «Карточки документа»	+	+
Поиск и просмотр «Карточки документа» с возможностью самостоятельного сохранения на своем рабочем месте атрибута «Вложения»	+	+	+
Изменение атрибутов «Карточки документа»	+	+
Изменение статуса «Карточки документа», кроме перевода на этап «Удален»	+	+
Изменение статуса «Карточки документа» на статус «Удален»	+
Массовое создание экземпляров сущности «Карточки документа»	+
Массовое изменение адреса хранения	+	+
Просмотр истории изменений «Карточки документа»	+	+
Видимость «Карточки документа» в статусе «Удален»	+
Назначение ролей пользователям	+
Администрирование СЭАКД	+

НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ И ОГРАНИЧЕНИЯ Требования к СЭАКД СЭАКД должна иметь клиент-серверную архитектуру. СЭАКД должна поддерживать 20 рабочих мест (лицензий). СЭАКД должна иметь возможность развернута на виртуальной среде VMWare принадлежаще . Взаимодействие пользователя с системой должно осуществляться с помощью графического веб-интерфейса. Минимальное разрешение экрана для работы веб-приложения должно быть не менее 1024x768 пикселей. Веб-интерфейс системы должен функционировать на Microsoft Internet Explorer версии 8.0 и выше; Интерфейс пользователя должен быть удобным, интуитивно понятным Конфигурационные параметры системы должны изменяться без перекомпиляции исходных текстов разработанного программного обеспечения. Производительность Реализация данных доработок не должна существенно повлиять на скорость  реализованных процессов в системах. Система должна обеспечивать следующий показатель производительности в части взаимодействия пользователей с веб-порталом (без учёта задержек сети) – время получения отклика (фиксируется по началу процесса прорисовки в окне веб-браузера данных, полученных с серверной части системы на запрос пользователя) не более 3 секунд для 95% типов доступных для пользователя запросов Системные требования и производительность виртуальной серверной платформы, включая тип ОС, требуемое количество ядер, оперативной памяти, дискового пространства, уровень RAID и т. д., определяет исполнитель. Данные сведения должны быть включены в конкурсную заявку. Исполнитель должен быть готов предоставить обоснование требуемой вычислительной мощности. Система должна обеспечить хранение минимум 2 500 000 абонентских дел, максимум - 6 000 000 абонентских дел Информационная безопасность СЭАКД должна соответствовать стандарту СТ-МГТС-027-2 (Требования для новых приложений и информационных систем). Ссылка на выписку из СТ-МГТС-027-2  размещена в п.3.3 настоящих ФТ. Требования к мониторингу Мониторинг СЭАКД должен осуществляться системой мониторинга МГТС - System Center Operation Manager 2012 R2 Показатели мониторинга указывает поставщик СЭАКД Требования к надёжности

К системе предъявляются следующие требования надёжности:

система должна функционировать круглосуточно, в непрерывном режиме, кроме времени проведения регламентных работ; сбои в работе рабочих станций и сетевого оборудования не должны приводить к разрушению данных, обрабатываемых системой, и сказываться на работоспособности системы в целом; должна обеспечиваться защита от ошибочных действий пользователей и технического персонала (которые могут привести к нарушению работоспособности системы) за счёт чёткого разграничения прав доступа, ведения электронных журналов регистрации событий (детальной регистрации действий пользователей) и т. п. РИСКИ ИЗМЕНЕНИЯ
Формат предоставления данных

1. Цена системы, рубли без НДС

2. Цена интеграции с EADDR, рубли без НДС

3. Срок внедрения системы, включая все этапы

4. Срок внедрения с EADDR, включая все этапы

5. Описание предлагаемой системы

6. Требования к КТС

1 Данный справочник указывает на цели выдачи бумажного варианта абонентского дела

2 Предполагается выдача оригиналов абонентского дела сотрудникам Отдела Судебной работы и Департамента по работе со специальными пользователями

3 Под диапазоном здесь подразумеваются адреса хранения,  которые совпадают с «Новым адресом хранения» до указанного уровня детализации. Значения атрибутов адреса хранения более низких уровней детализации при этом могут быть любыми