В настоящем документе используются следующие определения, сокращения и аббревиатуры:
* **ОС** - операционная система;
* **ИС** - информационная система;
* **Система** - ИС «Showcase»;
* **НУЦ РК** - Национальный удостоверяющий центр Республики Казахстан;
* **ЭЦП** - Электронная цифровая подпись;
* **СЭД** - Система электронного документооборота;
* **СУБД** - система управления базами данных;
* **Справочник** - перечень заранее определенных значений параметров объектов системы;
* **Форма** - тип файла в Платформе, предназначенный для сбора и отображения структурированных данных;
* **Реестр** - способ представления данных по Форме в табличном виде;
* **Запись** - документ на основе Формы в Реестре.
* **Работа** - объект системы, представляющий собой сформулированное автором требование выполнить действие за конечное время и возложенное на конкретного исполнителя (ответственного).
* **Приоритет** - атрибут работы, определяющий важность её исполнения. Названия и параметры имеют возможность настройки.
* **Нагрузка** - атрибут работы, определяющий время, выделенное на выполнение данной работы. Нагрузка может быть выражена в количестве часов в день, в количестве часов всего, в количестве рабочих дней, в проценте от рабочего времени. Данный параметр работы участвует в формулах расчета общей нагрузки пользователя и его эффективности.
* **Прогресс** - атрибут работы, характеризующий процент её выполнения (от 0% до 100%).
* **Статус** - атрибут работы, определяющий статус работы в системе:
* **Маршрут** - многократно используемый набор Работ и правил переходов, связанных последовательно и/или параллельно, направленных на достижение заранее определённого результата.
* **Фильтры работ** - способ группировки работ в зависимости от их свойств и по отношению пользователя к работе (на исполнении, на контроле).
* **Согласование** - работа, требующая в качестве своего завершения выбора одного из пунктов: согласовано или не согласовано, позволяющая также при выборе ввести комментарий.
* **Утверждение** - работа, требующая в качестве своего завершения выбора одного из пунктов: утверждено или не утверждено, позволяющая также при выборе ввести комментарий.
* **Ознакомление** - работа, требующая в качестве своего завершения выбора пункта: ознакомился.
* **Документ** - именованный контейнер в Хранилище, содержащий реквизиты и файлы, а также их версии. Реквизиты содержат: Карточку документа (в зависимости от типа), Ход исполнения, Изменения в документе, Листы подписей.
* **Дочерний документ** - документ, созданный на основании данного. Связь «основание - дочерний» отображается в карточке документа.
* **Основание документ** - документ, на основании которого был создан данный. Связь «основание - дочерний» отображается в карточке документа.
* **Обращение (инцидент или заявка на обслуживание)** - Документ (в терминах системы), позволяющий хранить структурированные данные об инциденте ( - незапланированном прерывании или снижении качества ИТ-услуги, сбои конфигурационной единицы) или заявке на обслуживание по утвержденной форме.
* **Проблема (запись о проблеме)**- Документ (в терминах системы), позволяющий хранить структурированные данные о проблеме (-причине одного или нескольких инцидентов) по утвержденной форме.
* **Конфигурационная единица** - Документ (в терминах системы), позволяющий хранить структурированные данные по утвержденной форме о любом компоненте или другом сервисном активе, которым необходимо управлять для того, чтобы предоставлять ИТ-услугу.
* **Соглашение об уровне услуг (SLA)** - Документ (в терминах системы), позволяющий хранить структурированные данные о соглашении (целевые показатели уровня услуги, зоны ответственности сторон) по утвержденной форме.
* **Лицензия** - Документ (в терминах системы), позволяющий хранить структурированные данные о лицензии по утвержденной форме.
* **Наряд** - Документ (в терминах системы), позволяющий хранить структурированные данные о наряде (формальном запросе на выполнение определенной деятельности) по утвержденной форме.
* **Оценка сервиса** - Документ (в терминах системы), позволяющий хранить структурированные данные об оценке качества предоставляемого сервиса по устранению инцидента.
* **Запись базы знаний** - Документ (в терминах системы), позволяющий хранить структурированные данные (- точек зрения,идей, опыта, информации) по утвержденной форме.
* **Услуга(сервис)** - Документ (в терминах системы), позволяющий хранить структурированные данные об услуге (описании желаемых результатов, ценовой политике, пакетах обслуживания и пр.) по утвержденной форме.
* **Спецификация услуги** - Документ (в терминах системы), позволяющий хранить структурированные данные об услуге (сервисные условия, связанные внутренние и внешние IT сервисы, процедурные оценки, финансы) по утвержденной форме.
* **Карточка контакта** - Документ (в терминах системы), позволяющий хранить структурированные данные о контакте (сотруднике организации) по утвержденной форме.
* **Карточка организации** - Документ (в терминах системы), позволяющий хранить структурированные данные об организации по утвержденной форме.
* **Запрос на изменение (RFC)** - (RFC - Request for changes). Документ (в терминах системы), позволяющий хранить структурированные данные о запросе (-формальном предложении на выполнение изменений) по утвержденной форме.
* **Запись об изменении (CR)** - (CR - Change record). Документ (в терминах системы), позволяющий хранить структурированные данные об изменении по утвержденной форме. Прим. Запись об изменении (CR) может являться дочерним документом для запроса на изменение (RFC)
3.1.1, "Система должна поддерживать работу на следующих серверных операционных системах: Linux, BSD, Solaris (рекомендуется использовать ОС Debian GNU/Linux 6.0 (amd64)."
3.1.2, "Система должна поддерживать работу на реляционных СУБД и на noSQL СУБД."
3.1.3, "Система не требует обязательного приобретения дополнительных компонентов (лицензии на ОС, на СУБД и т.п.)."
3.1.4, "Система поддерживает шифрование подключений с помощью протокола SSL (HTTPS)."
3.1.5, "Система должна поддерживать работу с распределённым хранилищем данных."
3.1.6, "Система должна обеспечивать возможность распределенной работы и удаленного доступа к ресурсам и объектам."
3.1.7, "Система должна поддерживать работу в архитектуре Internet/Intrаnet."
3.1.8, "Система должна предоставлять Web-интерфейс, который не требует установки клиентской части. Система должна поддерживать интернет-браузеры Google Chrome, Mozilla Firefox актуальных версий."
3.1.9, "Система должна предоставлять возможность реализовывать пользовательские интерфейсы, используя HTML и/или JavaScript."
3.1.10, "Система должна предоставлять комплект средств разработки (Software Development Kit - SDK), включая: REST API; способы авторизации: сессионная, по логину и паролю, по ключам; события, возникающие в различных точках исполняемого кода при выполнении определённых условий; очереди сообщений; поддержку плагинов; JavaScript интерпретаторы."
3.1.11, "Система должна предоставлять инструментарий для локализации языка интерфейса. Система должна обеспечить возможность добавлять и настраивать неограниченное количество языков без программирования в процессе эксплуатации. А также позволять изменять переводы в режиме реального времени, без остановки системы и без применения сторонних инструментов."
3.1.12, "Система должна предоставлять возможность администрирования организационной структуры, функциональных ролей и учетных записей пользователей."
3.1.13, "Система должна предоставлять возможность регулирования доступа к объектам платформы в соответствии с правами доступа пользователя."
3.1.14, "Система должна предоставлять возможность создания, редактирования форм в визуальном редакторе форм."
3.1.15, "Система должна предоставлять инструмент управления бизнес-процессами, поддерживающий нотацию BPMN."
3.1.16, "Система должна предоставлять дизайнер бизнес-процессов. Создание и редактирование бизнес-процессов должно выполняться в рабочем пространстве дизайнера бизнес-процессов."
3.1.17, "Система должна поддерживать версионность документов."
Требования к процессу “Управление обращениями (инцидентами и заявками на обслуживание)”
3.2.1, "Система должна поддерживать осуществление следующих ролей в рамках процесса “Управление обращениями (инцидентами и заявками на обслуживание)”:
* Инициатор обращения (автор)
* Оператор
* Исполнитель
* Менеджер сервиса"
3.2.2, "Система должна позволять создавать/редактировать/удалять обращение в соответствии с правами доступа."
3.2.3, "Система должна позволять в описании обращения указывать:подробную информацию об авторе (с автоматической подстановкой данных, при их наличии) детальное описания инцидента или заявки на обслуживание, классификацию (по услугам и SLA, типу запроса, приоритету инициатора), ранжирование (по важности/срочности), связи с услугами, проблемами, конфигурационными единицами и другими обращениями."
3.2.4, "Система должна позволять пользователю с ролью Оператор указывать Исполнителя по обращению и сроков его исполнения."
3.2.5, "Система должна позволять осуществлять маршрут исполнения обращения согласно текущему его статусу."
3.2.6, "Система должна позволять создавать один или несколько нарядов на основе данного инцидента. Наряд, в свою очередь, может включать в себя одну или несколько работ."
3.2.7, "Система должна позволять осуществлять координацию реализации работ по наряду. А именно: контроль прогресса исполнения, комментирование, прикрепление вложений в виде файлов."
3.2.8, "В Системе должен быть предусмотрен рабочий календарь обращения, автоматически определяемый по услуге и SLA, по рабочему календарю для дальнейшего отсчет временных метрик;"
3.2.9, "В системе должен быть предусмотрен возврат обращений “на доработку” с автоматическим приостановлением расчета временных метрик."
3.2.10, "Система должна поддерживать функцию вертикальной эскалации (передачу инцидента на более высокий уровень по оргструктуре), при нарушении SLA. В системе должна быть предусмотрена возможность настройки механизма эскалации по счетчикам (количество переназначений исполнителя, количество переклассификаций обращения и т.п.)"
3.2.11, "Система должна предусматривать назначения обращения определенному ответственному или группе, а также назначению ответственного в рамках выбранной группы. Система должна предусматривать возможность переназначения с группы на группу, на ответственного и т.д."
3.2.12, "По завершению работ по инциденту, система должна позволять вносить описание решения в запись об инциденте, а также осуществлять оценку сервиса пользователю с ролью Менеджер сервиса."
3.2.13, "Система должна предусматривать возможность завершения обращения без необходимости вносить оценку, принятия инициатором."
3.2.14, "Система должна предоставлять возможность перехода по всем связанным объектам (обращение - проблема- услуга - конфигурационная единица), а также возвращению необходимых значений в связанные объекты, при изменении статуса основного."
3.2.15, "В Системе должна быть возможность выполнять информирование инициатора обращения (e-mail-уведомления) на всех этапах жизненного цикла обращения"
3.2.16, "Система должна позволять пользователю с соответствующими правами доступа просматривать список всех обращений, а также осуществлять поиск и фильтрацию по ключевым полям формы."
3.2.17, "Система должна поддерживать интеграцию с электронной почтой на предмет получения записей об инцидентах."
3.2.18, "Система должна поддерживать интеграцию с приложением “Telegram” (через реализацию TelegramBot) на предмет получения записей об инцидентах."
3.2.19, "В системе должен быть предусмотрен механизм интеграции с порталом для регистрации обращений, а также просмотра статусов текущих обращений, поданных через портал."
3.3.1, "Система должна поддерживать осуществление следующих ролей в рамках процесса “Управление проблемами”:
* Инициатор записи о проблеме(автор)
* Оператор
* Исполнитель
* Менеджер сервиса"
3.3.2, "Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа запись о проблеме."
3.3.3, "Система должна позволять в описании проблемы указывать подробную информацию об авторе, отличать проблему от известной ошибки, детальное описание самой проблемы, а также указывать связи с сервисами, инцидентами и другими проблемами. "
3.3.4, "Система должна позволять пользователю с ролью Оператор указывать Исполнителя по инциденту и сроков его исполнения."
3.3.5, "Система должна позволять осуществлять маршрут исполнения проблемы согласно текущему её статусу."
3.3.6, "Система должна позволять осуществлять координацию реализации работ маршрута проблемы. А именно: контроль прогресса исполнения, комментирование, прикрепление вложений в виде файлов."
3.3.7, "Система должна позволять пользователю с соответствующими правами доступа просматривать список всех проблем, а также осуществлять поиск и фильтрацию по ключевым полям формы."
3.3.8, "Система должна поддерживать интеграцию с электронной почтой на предмет получения записей о проблемах."
3.3.9, "Система должна поддерживать интеграцию с приложением “Telegram” (через реализацию TelegramBot) на предмет получения записей о проблемах."
Требования к процессу “Управление уровнем услуг (SLA)”
3.4.1, "Система должна поддерживать осуществление следующих ролей в рамках процесса “Управление уровнем услуг(SLA)”: Менеджер услуг (SLA)."
3.4.2, "Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа карточку контакта по установленной форме."
3.4.3, "Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа карточку организации по установленной форме."
3.4.4, "Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа соглашение об уровне обслуживания с заполнением основной информации, описании ожидаемых результатов, взаимодействия и ответственности сторон, условия предоставления услуг."
3.4.5, "Система должна предоставлять возможность заполнения истории изменения Соглашений об уровне обслуживания (SLA)."
3.4.6, "Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа карточку Усулги по установленной форме с заполнением основной и подробной и информации, а также привязки к другой услуге."
3.4.7, "Система должна позволять пользователю с соответствующими правами доступа просматривать список всех:
* Контактов
* Организаций
* Услуг
* Соглашений об уровне обслуживания (SLA)
* А также осуществлять поиск и фильтрацию по ключевым полям данных форм."
3.5.1, "Система должна поддерживать осуществление следующих ролей в рамках процесса “Управление знаниями”: Инициатор записи Базы знаний - любой пользователь системы, имеющий право доступа на создание записи в соответствующем реестре."
3.5.2, "Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа запись базы знаний с заполнением основной и подробной информации по установленной форме."
3.5.3, "Система должна позволять связывать запись базы знаний с зарегистрированными инцидентами и проблемами в соответствующих реестрах."
3.5.4, "Система должна позволять пользователю с соответствующими правами доступа просматривать список всех записей Базы знаний, а также осуществлять поиск и фильтрацию по ключевым полям данных форм."
3.6.1, "Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа Конфигурационную Единицу по установленной форме"
3.6.2, "Система должна позволять пользователю с соответствующими правами доступа просматривать список всех конфигурационных единиц. А также осуществлять поиск и фильтрацию по ключевым полям данных форм."
3.7.1, "Система должна поддерживать осуществление следующих ролей в рамках процесса “Управление изменениями”:
* Инициатор RFC - Любой сотрудник компании, являющийся автором и отправителем Заявки на изменение RFC
* Совет по изменениям (CAB) - группа пользователей, согласующими RFC или CR на разных этапах процесса.
* Эксперт - Сотрудник компании (н-р, сотрудник IT отдела) являющийся экспертом по данному вопросу из RFC, обладающие компетенциями чтобы провести оценку рисков, ресурсов, составить план работ и план отката.
* Менеджер SC- Сотрудник компании (н-р, руководитель IT отдела), распределяющий нагрузку среди исполнителей работ по изменениям, назначающий сроки исполнения этих работ. (управляет Графиком изменений)
* Исполнитель - Сотрудник, отвечающий за исполнение конкретной работы по плану реализации или плану отката CR"
3.7.2, "Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа запрос на изменение (RFC) с заполнением следующей основной информации о запросе. А также дополнительной информации, позволяющей классифицировать данный запрос по важности/срочности, связывать запрос на изменение (RFC) с касающимися его услугами."
3.7.3, "Система должна позволять осуществлять процесс согласования запроса на изменения (RFC) с советом по изменения (CAB), а также с другимизаинтересованными лицами."
3.7.4, "Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа на основании запроса на изменение (RFC) запись об изменении CR: определять план реализации и план отката, а также необходимость включения в Релиз."
3.7.5, "Система должна позволять осуществлять маршрут согласования CR c советом по изменениям (CAB), а также другими заинтересованными лицами."
3.7.6, "Система должна позволять пользователю с ролью менеджер SC определять сроки исполнения работ по плану реализации и плану отката CR."
3.7.7, "Система должна позволять осуществлять координацию реализации работ по плану реализации и плану отката CR. А именно: контроль прогресса исполнения, комментирование, прикрепление вложений в виде файлов."
3.7.8, "Система должна позволять пользователю с соответствующими правами доступа просматривать список всех запросов на изменения (RFC) и записей об изменении (CR), а также осуществлять поиск и фильтрацию по ключевым полям данных форм."
