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

4.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 Система должна поддерживать версионность документов.

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

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

4.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 В системе должен быть предусмотрен механизм интеграции с порталом для регистрации обращений, а также просмотра статусов текущих обращений, поданных через портал.

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

4.5. Требования к модулю “Управление уровнем услуг (SLA)”

3.4.1 Система должна поддерживать исполнение функций следующих ролей в рамках процесса “Управление уровнем услуг(SLA)”: Менеджер услуг (SLA).
3.4.2 Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа карточку контакта по установленной форме.
3.4.3 Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа карточку организации по установленной форме.
3.4.4 Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа карточку Услуги по установленной форме с заполнением основной и подробной и информации, соглашений об уровне обслуживания по услуге, а также привязки к другой услуге.
3.4.5
Система должна позволять пользователю с соответствующими правами доступа просматривать список всех:
  • Контактов
  • Организаций
  • Услуг
  • А также осуществлять поиск и фильтрацию по ключевым полям данных форм.

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

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

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

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

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