3. Требования к разработке ИС «Synergy ITSM»

3.1. Общие требования к Системе

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	Система должна предоставлять инструмент управления бизнес-процессами, поддерживающий нотацию BPMN.
3.1.15	Система должна предоставлять дизайнер бизнес-процессов. Создание и редактирование бизнес-процессов должно выполняться в рабочем пространстве дизайнера бизнес-процессов.
3.1.16	Система должна поддерживать версионность документов.

3.2. Требования к модулям Системы

3.2.1	Система должна предоставлять доступ пользователям к модулю “Управление обращениями (инцидентами и заявками на обслуживание)”.
3.2.2	Система должна предоставлять доступ пользователям к модулю “Управление проблемами”.
3.2.3	Система должна предоставлять доступ пользователям к модулю “Управление уровнем услуг (SLA)”.
3.2.4	Система должна предоставлять доступ пользователям к модулю “Управление знаниями”.
3.2.5	Система должна предоставлять доступ пользователям к модулю “Управление конфигурациями”.
3.2.6	Система должна предоставлять доступ пользователям к модулю “Управление изменениями”.

3.3. Требования к модулю “Управление обращениями (инцидентами и заявками на обслуживание)”

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	Система должна предусматривать назначения обращения определенному ответственному или группе, а также назначению ответственного в рамках выбранной группы. Система должна предусматривать возможность переназначения с группы на группу, на ответственного и т.д.
3.2.11	По завершению работ по обращению, система должна позволять вносить описание решения в запись об обращении, а также осуществлять оценку сервиса.
3.2.12	Система должна предусматривать возможность завершения обращения без необходимости вносить оценку, принятия инициатором.
3.2.13	Система должна предоставлять возможность перехода по всем связанным объектам (обращение - проблема- услуга - конфигурационная единица), а также возвращению необходимых значений в связанные объекты, при изменении статуса основного.
3.2.14	В Системе должна быть возможность выполнять информирование инициатора обращения (e-mail-уведомления) на всех этапах жизненного цикла обращения
3.2.15	Система должна позволять пользователю с соответствующими правами доступа просматривать список всех обращений, а также осуществлять поиск и фильтрацию по ключевым полям формы.
3.2.16	Система должна поддерживать интеграцию с электронной почтой на предмет получения записей об обращениях.
3.2.17	Система должна поддерживать интеграцию с приложением “Telegram” (через реализацию TelegramBot) на предмет получения записей об обращениях.
3.2.18	В системе должен быть предусмотрен механизм интеграции с порталом для регистрации обращений, а также просмотра статусов текущих обращений, поданных через портал.

3.4. Требования к модулю “Управление проблемами”

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) на предмет получения записей о проблемах.

3.5. Требования к модулю “Управление уровнем услуг (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.6. Требования к модулю “Управление знаниями”

3.5.1	Система должна поддерживать осуществление следующих ролей в рамках процесса “Управление знаниями”: Инициатор записи Базы знаний - любой пользователь системы, имеющий право доступа на создание записи в соответствующем реестре.
3.5.2	Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа запись базы знаний с заполнением основной и подробной информации по установленной форме.
3.5.3	Система должна позволять связывать запись базы знаний с зарегистрированными обращениями и проблемами в соответствующих реестрах.
3.5.4	Система должна позволять пользователю с соответствующими правами доступа просматривать список всех записей Базы знаний, а также осуществлять поиск и фильтрацию по ключевым полям данных форм.

3.7. Требования к модулю “Управление конфигурациями”

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

3.8. Требования к модулю “Управление изменениями”

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), а также осуществлять поиск и фильтрацию по ключевым полям данных форм.