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

ПРИЛОЖЕНИЕ К ЗАПРОСУ НА ИЗМЕНЕНИЕ
ITG# 47905
«Консолидация архива клиентских дел МГТС»
ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
Версия
1.4
ИСТОРИЯ ИЗМЕНЕНИЙ ...............................................................................................................1
СОГЛАСОВАНИЕ...........................................................................................................................3
ССЫЛКИ ..........................................................................................................................................3
ЦЕЛИ И НАЗНАЧЕНИЕ ДОКУМЕНТА ......................................................................................3
ГЛОССАРИЙ ...................................................................................................................................4
БИЗНЕС ТРЕБОВАНИЯ .................................................................................................................4
6.1 Предпосылки.............................................................................................................................4
6.2 Область применения и границы ..............................................................................................4
6.3 Цели и задачи, преимущества для бизнеса и компании .......................................................4
6.4 Способ измерения полученных результатов .........................................................................4
7 ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ ........................................................................................5
7.1 Требования к настройкам и справочникам ............................................................................5
7.2 Требования к абонентскому делу ...........................................................................................5
7.3 Требования к операции массового создания экземпляров сущности «Карточка
документа» ...........................................................................................................................................8
7.4 Требования к операции массового изменения адреса хранения .........................................8
7.5 Требования к отчетности .........................................................................................................9
7.6 Требования к ролям пользователей ........................................................................................9
8 НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ И ОГРАНИЧЕНИЯ ..............................................10
8.1 Требования к СЭАКД ............................................................................................................10
8.2 Производительность ..............................................................................................................10
8.3 Информационная безопасность ............................................................................................11
8.4 Требования к мониторингу ...................................................................................................11
9 РИСКИ ИЗМЕНЕНИЯ ..................................................................................................................11
1
2
3
4
5
6
1 ИСТОРИЯ ИЗМЕНЕНИЙ
Версия
Дата
ФИО
Описание
1.0
09.10.2014
Галич К.О.
Создание документа
1.1
29.10.2014
Галич К.О.
Внесение исправлений по замечаниям
1.2
12.11.2014
Галич К.О.
Внесение исправлений по замечаниям
1.3
21.11.2014
Галич К.О.
Внесение исправлений по замечаниям
стр. 1 из 11
1.4
5.01.2015
Павловский В.Ю.
Внесение исправлений по замечаниям БУЗ для RFI
стр. 2 из 11
2 СОГЛАСОВАНИЕ
Версия
Подразделение
ФИО
Компания
1.3
БРИТ/ОВБЗ
Галич К.О.
МГТС
Дата завершения
Статус
Лист
согласования
согласования
согласования
27.11.2014
Согласовано
3 ССЫЛКИ
№
1.
Название
Заявка ITGC # 47905
ITGC 47905
Консолидация архива клиентских дел МГТС.doc
2.
Шаблон отчета «Карточки документов»
Карточки
документов требования к отчету.xls
3
Выписка из СТ-МГТС-027-2
Параметры
информационной безопасности внедряемой автоматизированной системы
4
EADDR
Единая_адресная_
база.doc
4 ЦЕЛИ И НАЗНАЧЕНИЕ ДОКУМЕНТА
Документ является приложением к Запросам (ITG # 47905), направленному на автоматизацию
работы с абонентскими делами.
Целями разработки данного документа являются:
 описание высокоуровневых бизнес требований;
 определение цели и задачи изменения;
 описание ожидаемых бизнес-результатов;
 определение области применения изменения;
 формирование функциональных требований;
 формирование требований к качеству.
Данный документ может использоваться для:
 подготовки системных требований;
 подготовки методики испытаний;
стр. 3 из 11
Настоящий документ не раскрывает технические подробности реализации, такие как,
архитектура решения и детали дизайна
5 ГЛОССАРИЙ
Основные понятия, термины и сокращения, используемые в документе
Понятие
Определение
BR
Business Requirement
eADDR
Информационная система, выполняющая функции
Ссылки на источники
централизованного адресного справочника МГТС
FR
Functional Requirement
OR
Other Requirement
СЭАКД
Система электронного архива клиентских дел
6 БИЗНЕС ТРЕБОВАНИЯ
6.1 Предпосылки
BR.1. Планируется сокращение количество объектов хранения и миграция архивов на
несколько площадок МГТС.
6.2 Область применения и границы
BR.2. Данный документ описывает функциональные требования к ведению
электронного каталога документов.
BR.3. В данных функциональных требованиях не определена ИС, в которой будет
реализовываться электронный каталог. Для обозначения ИС используется термин
СЭАКД.
BR.4. В данных функциональных требованиях не предполагается проверка
корректности атрибутов «Карточки документа» с данными из других ИС.
BR.5. В данных функциональных требованиях предполагается, что в СЭАКД не будет
осуществляться работа со спец-абонентами.
BR.6. В данных функциональных требованиях предполагается возможность выдачи
оригиналов абонентского дела сотрудникам Отдела Судебной работы
и Департамента по работе со специальными пользователями.
6.3 Цели и задачи, преимущества для бизнеса и компании
BR.7. Высвобождение помещений, занимаемых под архив.
BR.8. Получение дополнительных доходов от сдачи в аренду высвобожденных
помещений.
BR.9. Хранение информации о клиентских делах по всем абонентам в одном месте.
BR.10. Изменение принципа работы с архивом (сокращение времени на поиск дела,
увеличение скорости обработки данных при работе с претензиями, создание
электронного архива позволит осуществлять on-line доступ).
BR.11. Ограничение неавторизованного доступа к документам.
BR.12. Наполнение справочника «Адрес хранения» лежит в зоне ответственности
подразделений, задействованных в бизнес-процессе.
6.4 Способ измерения полученных результатов
BR.13. Сокращение времени доступа к клиентским делам МГТС и как следствие
увеличение скорости и качества обслуживания абонентов.
стр. 4 из 11
7 ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
7.1 Требования к настройкам и справочникам
В СЭАКД должны быть представлены справочники:
 Типы документов
 Категории абонентов
 Историческая ценность
 Цель выдачи документа
 Адрес хранения
 Срок хранения документа
FR.2.
При инициализации, справочник «Типы документов» должен принимать
значение:
 Абонентское дело
FR.3.
При инициализации, справочник «Категории абонентов» должен принимать
значения:
 Квартирные
 Хозрасчетные
 Госбюджетные
FR.4.
При инициализации, справочник «Историческая ценность» должен принимать
значения:
 Обычный
 Исторический
FR.5.
При инициализации, справочник «Цель выдачи документа»1 должен принимать
значения:
 Претензия абонента
 Судебное разбирательство
 Обращение в офис
FR.6.
Справочник «Адрес хранения» должен иметь следующую структуру:
 Адрес
 Комната
 Стеллаж
 Коробка
 Папка
 № п/п
FR.7.
Атрибуты справочника «Адрес хранения», за исключением атрибута «№ п/п»
должны быть обязательными для заполнения.
FR.8.
В справочнике «Адрес хранения» атрибут «Адрес» должен принимать значения из
eADDR. (API eADDR представлен в приложении 1 )
FR.9.
При инициализации, справочник «Срок хранения документа» должен иметь
значение согласно таблице 1:
FR.1.
Таблица 1. Справочник "Срок хранения документа"
Тип документа
Абонентское дело
Абонентское дело
Тип абонента
Юр.лица
Физ.лица
Срок хранения документа
3650 дней
1825 дней
7.2 Требования к абонентскому делу
FR.10.
В СЭАКД должна быть добавлена сущность «Карточка документа».
FR.11.
В СЭАКД должны быть доступны следующие операции для сущности «Карточка
документа»:
 Создание экземпляра сущности «Карточка документа»
1
Данный справочник указывает на цели выдачи бумажного варианта абонентского дела
стр. 5 из 11


Поиск экземпляров сущности «Карточка документа»
Изменение значений атрибутов экземпляра сущности «Карточка документа», в
том числе и массовое изменение адреса хранения
 Изменение статуса экземпляра сущности «Карточка документа»
 Удаление экземпляра сущности «Карточка документа».
FR.12.
Сущность «Карточка документа» должна иметь статусы согласно таблице 2:
Таблица 2. Статусы сущности "Карточка документа"
Начальный статус
Черновик
Актуальный
Конечный статус
Актуальный
Выдан
На ревизии
Договор расторгнут
Выдан
Актуальный
На ревизии
Актуальный
Договор расторгнут
Удален
FR.13.
Экземпляр сущности «Карточка документа» должен создаваться в статусе
«Черновик».
FR.14.
Конечным статусом экземпляра сущности «Карточка документа» должен быть
статус «Удален».
FR.15.
Форма создания экземпляра сущности «Карточка документа» должна содержать
атрибуты согласно таблице 3:
Таблица 3. Форма создания экземпляра сущности "Карточка документа"
Наименование
атрибута
Телефон
Тип документа
ФИО/Наименование
организации
Тип абонента
Источник
Обязательность
заполнения
Вводиться вручную в формате «+7-YYY-XXX- да
XX-XX»
Одно из значений из справочника «Типы да
документов»
Вводится вручную
да
Одно из значений:
да
 Юр.лицо
 Физ.лицо
Категория абонента
Значение из справочника «Категории абонентов»
да
Договор
Вводится вручную
да
Адрес установки
Значение из EADDR
да
Адрес хранения
Значение из справочника «Адрес хранения»
нет
Реестр
Вводится вручную
нет
Историческая ценность Значение
из
справочника
«Историческая да
(категория)
ценность». По умолчанию, должно принимать
значение «Обычный»
Вложения
Интерфейс для прикрепления документов
нет
Комментарий
Текстовое поле
нет
FR.16.
Атрибут «Телефон» должен соответствовать шаблону «+7-YYY-XXX-XX-XX»,
где X – произвольная цифра, а YYY – ABC – код.
FR.17.
ABC-код должен принимать значение 495, 498 или 499 и быть настраиваемым.
FR.18.
Атрибуты сущности «Карточка документа»:
 Телефон
 Договор
 Адрес хранения
должны быть уникальными.
FR.19.
Форма экземпляра сущности «Карточка документа» должна содержать атрибуты
согласно таблице 4:
стр. 6 из 11
Таблица 4. Форма сущности "Карточка документа"
Наименование
атрибута
Телефон
АТС
Тип документа
ФИО/Наименование
организации
Тип абонента
Источник/Описание атрибута
Возможность
редактирования
Номер в формате «+7-YYY-XXX-XX-XX»
нет
Рассчитывается автоматически как 4-6 цифры нет
маски номера телефона (+7- YYY-XXX-XX-XX)
Одно из значений из справочника «Типы нет
документов»
Текстовое поле
да
Одно из значений:
да
 Юр.лицо
 Физ.лицо
Категория абонента
Значение из справочника «Категории абонентов»
да
Договор
Текстовое поле
да
Адрес установки
Значение из EADDR
нет
Адрес хранения
Значение из справочника «Адрес хранения»
да
Реестр
Текстовое поле
да
Историческая ценность Значение
из
справочника
«Историческая да
(категория)
ценность»
Статус
Текущий статус «Карточки документа»
да
Дата
создания Дата создания экземпляра сущности «Карточка нет
карточки документа
документа»
Цель выдачи
Значение из справочника «Цель выдачи
абонентского дела»
Выдан
ФИО сотрудника, которому передается бумажная да
версия дела2
Вложения
Интерфейс для прикрепления документов, а также да
вложенные ранее документы
Комментарий
Текстовое поле
да
FR.20.
Для сущности «Карточка документа» должна быть возможность добавления
пользовательских атрибутов.
FR.21.
Изменение статуса экземпляра сущности «Карточка документа» должно
осуществляться вручную.
FR.22.
Изменение статуса экземпляра сущности «Карточка документа» со статуса
«Черновик» должно быть доступно только при заполненном атрибуте «Адрес хранения».
FR.23.
Изменение статуса с «Договор расторгнут» на «Удален» должно осуществляться с
подтверждением.
FR.24.
Для экземпляров сущности «Карточка документа», имеющих значение
«Исторический» в поле «Историческая ценность», должна быть закрыта возможность
перевода в статус «Удален».
FR.25.
При изменении статуса «Карточки документа» на значение «Выдан» обязательно
должны быть заполнены поля «Цель выдачи» и «Выдан».
FR.26.
При изменении статуса «Карточка документа» со значения «Выдан» должны
автоматически очищаться поля «Цель выдачи» и «Выдан».
FR.27.
В СЭАКД должна быть возможность поиска экземпляров сущности «Карточка
документа» по:
 Номеру телефона
 ФИО/Наименованию организации
 Номеру АТС
 Адресу установки
Предполагается выдача оригиналов абонентского дела сотрудникам Отдела Судебной работы и Департамента по
работе со специальными пользователями
стр. 7 из 11
2

Адресу расположения с детализацией до уровня комнаты, стеллажа, коробки,
папки, № п/п
 Статусу
FR.28.
В СЭАКД должно осуществляться логирование управляющих действий (создание
карточки документа, изменение статуса, изменение атрибутов, изменение адреса
хранения).
7.3 Требования к операции массового
сущности «Карточка документа»
создания
экземпляров
FR.29.
В СЭАКД должна быть доступна операция массового создания экземпляров
сущности «Карточка документа».
FR.30.
В СЭАКД при осуществлении операции массового создания экземпляров
сущности «Карточка документа» карточки документов должны создаваться для всех
абонентов из FF, имеющих открытый договор.
FR.31.
В СЭАКД при осуществлении операции массового создания экземпляров
сущности «Карточка документа» карточки документов должны создаваться согласно
таблице 5:
Таблица 5. Создание экземпляра сущности "Карточка документа"
Наименование атрибута
Телефон
АТС
Тип документа
ФИО/Наименование
организации
Тип абонента
Категория абонента
Договор
Адрес установки
Адрес хранения
Реестр
Историческая
ценность
(категория)
Статус
Дата
создания
карточки
документа
Цель выдачи
Выдан
Вложения
Комментарий
Источник
Абонентский номер из FF
Рассчитывается автоматически согласно алгоритму
«Абонентское дело»
Абонент из FF
Тип абонента из FF
Категория абонента из FF
Договор из FF
Адрес установки из FF
«Обычный»
«Черновик»
Дата создания экземпляра сущности «Карточка документа»
-
7.4 Требования к операции массового изменения адреса хранения
FR.32.
В СЭАКД должна быть доступна операция массового изменения адреса хранения
для экземпляров сущности «Карточка документа».
FR.33.
В СЭАКД для осуществления операции массового изменения адреса хранения
должны быть указаны:
 «Старый адрес хранения»
 «Новый адрес хранения»
FR.34.
«Старый адрес хранения» и «Новый адрес хранения» должны принимать значения
из справочника «Адрес хранения».
FR.35.
«Старый адрес хранения» и «Новый адрес хранения» могут быть указаны до
уровня детализации комната, стеллаж, коробка, папка или № п/п.
FR.36.
В СЭАКД перед осуществлением операции массового изменения адреса
хранения, должна осуществляться проверка, что не существует экземпляров сущности
стр. 8 из 11
«Карточка документа» в диапазоне3 значений «Нового адреса хранения». В случае, если
такие экземпляры существуют, пользователю должно выводиться соответствующее
сообщение, операция массового изменения адресов хранения запускаться не должна.
FR.37.
При осуществлении операции массового изменения адреса хранения должны
отбираться экземпляры сущности «Карточка документа» с адресом хранения,
совпадающим со «Старым адресом хранения» до указанного уровня детализации
(атрибуты адресах ранения более низкого уровня детализации могут быть любыми).
FR.38.
При осуществлении операции массового изменения адреса хранения для
отобранных экземпляров сущности «Карточка документа» автоматически должен
изменяться адрес хранения на «Новый адрес хранения» до уровня детализации,
указанного в интерфейсе операции массового изменения адреса хранения. При этом,
атрибуты адреса хранения более низкого уровня детализации должны сохранять старые
значения (Если изменяем местоположение стеллажей, то значения коробок, папок и №
п/п должно оставаться прежним).
7.5 Требования к отчетности
В СЭАКД должен быть добавлен отчет:
Карточки документов.
FR.40.
Отчет «Карточки документов» должен иметь входные параметры:
 Период формирования (даты «С» и «По»)
 Тип документа
 Статус дела
FR.41.
Во входном параметре «Тип документа» должна быть возможность выбора
одного значения.
FR.42.
Во входном параметре «Статус дела» должна быть возможность выбора:
 Одного значения
 Нескольких значений
 Ни одного значения (формировать отчет по всем статусам)
FR.43.
Отчет «Карточки документов» должен формироваться по экземплярам «Карточка
документа», переведенных в указанный период на указанные статусы (переведенных в
указанный период в любой статус при пустом значении параметра «Статус дела»).
FR.44.
Отчет «Карточки документов» должен соответствовать шаблону, указанному в
разделе 3.
FR.45.
Выводимые данные в отчете «Карточки документов» должны быть
отсортированы по дате изменения статуса (самые свежие - сверху).
FR.39.

7.6 Требования к ролям пользователей
FR.46.





FR.47.
В СЭАКД должны быть добавлены роли:
Оператор
Поиск и просмотр
Менеджер
Администратор безопасности
Администратор
Функциональные возможности ролей показаны в следующей матрице:
Под диапазоном здесь подразумеваются адреса хранения, которые совпадают с «Новым адресом хранения» до
указанного уровня детализации. Значения атрибутов адреса хранения более низких уровней детализации при этом
могут быть любыми
стр. 9 из 11
3
+
+
+
+
+
+
+
Администратор
безопасности
Администратор
Поиск и
просмотр
Менеджер
Создание «Карточки документа»
Поиск и просмотр «Карточки документа» с возможностью
самостоятельного сохранения на своем рабочем месте
атрибута «Вложения»
Изменение атрибутов «Карточки документа»
Изменение статуса «Карточки документа», кроме перевода
на этап «Удален»
Изменение статуса «Карточки документа» на статус
«Удален»
Массовое создание экземпляров сущности «Карточки
документа»
Массовое изменение адреса хранения
Просмотр истории изменений «Карточки документа»
Видимость «Карточки документа» в статусе «Удален»
Назначение ролей пользователям
Администрирование СЭАКД
Оператор
Функциональная возможность
+
+
+
+
+
+
+
+
+
+
+
8 НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ И ОГРАНИЧЕНИЯ
8.1 Требования к СЭАКД
OR.1.
СЭАКД должна иметь клиент-серверную архитектуру.
OR.2.
СЭАКД должна поддерживать 20 рабочих мест (лицензий).
OR.3.
СЭАКД должна иметь возможность развернута на виртуальной среде VMWare
принадлежаще ОАО МГТС.
OR.4.
Взаимодействие пользователя с системой должно осуществляться с помощью
графического веб-интерфейса.
OR.5.
Минимальное разрешение экрана для работы веб-приложения должно быть не
менее 1024x768 пикселей.
OR.6.
Веб-интерфейс системы должен функционировать на Microsoft Internet Explorer
версии 8.0 и выше;
OR.7.
Интерфейс пользователя должен быть удобным, интуитивно понятным
OR.8.
Конфигурационные параметры системы должны изменяться без перекомпиляции
исходных текстов разработанного программного обеспечения.
8.2 Производительность
OR.9.
Реализация данных доработок не должна существенно повлиять на скорость
реализованных процессов в системах.
OR.10.
Система должна обеспечивать следующий показатель производительности в
части взаимодействия пользователей с веб-порталом (без учёта задержек сети) – время
получения отклика (фиксируется по началу процесса прорисовки в окне веб-браузера
данных, полученных с серверной части системы на запрос пользователя) не более
3 секунд для 95% типов доступных для пользователя запросов
OR.11.
Системные требования и производительность виртуальной серверной платформы,
включая тип ОС, требуемое количество ядер, оперативной памяти, дискового
пространства, уровень RAID и т.д., определяет исполнитель. Данные сведения должны
стр. 10 из 11
быть включены в конкурсную заявку. Исполнитель должен быть готов предоставить
обоснование требуемой вычислительной мощности.
OR.12.
Система должна обеспечить хранение минимум 2 500 000 абонентских дел,
максимум - 6 000 000 абонентских дел
8.3 Информационная безопасность
OR.13.
СЭАКД должна соответствовать стандарту СТ-МГТС-027-2 (Требования для
новых приложений и информационных систем). Ссылка на выписку из СТ-МГТС-027-2
размещена в п.3.3 настоящих ФТ.
8.4 Требования к мониторингу
OR.14.
Мониторинг СЭАКД должен осуществляться системой мониторинга МГТС System Center Operation Manager 2012 R2
OR.15.
Показатели мониторинга указывает поставщик СЭАКД
8.5 Требования к надёжности
К системе предъявляются следующие требования надёжности:
OR.16.
система должна функционировать круглосуточно, в непрерывном режиме, кроме
времени проведения регламентных работ;
OR.17.
сбои в работе рабочих станций и сетевого оборудования не должны приводить к
разрушению данных, обрабатываемых системой, и сказываться на работоспособности
системы в целом;
OR.18.
должна обеспечиваться защита от ошибочных действий пользователей и
технического персонала (которые могут привести к нарушению работоспособности
системы) за счёт чёткого разграничения прав доступа, ведения электронных журналов
регистрации событий (детальной регистрации действий пользователей) и т.п.
9 РИСКИ ИЗМЕНЕНИЯ
10 Формат предоставления данных
1. Цена системы, рубли без НДС
2. Цена интеграции с EADDR, рубли без НДС
3. Срок внедрения системы, включая все этапы
4. Срок внедрения с EADDR, включая все этапы
5. Описание предлагаемой системы
6. Требования к КТС
стр. 11 из 11