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 | Система должна поддерживать версионность документов. |
| 3.1.17 | Система должна поддерживать выгрузку данных в виде файла Excel с возможностью фильтрации по данным на форме, а также настройки отображаемых полей. |
| 3.1.18 | Система должна предоставлять возможность создания, редактирования, удаления шаблонов отчетов по данным реестров в рамках пользователя. |
4.2. Требования к модулям Системы¶
| 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 | Система должна предоставлять доступ пользователям к модулю “Управление активами”. |
4.3. Требования к модулю “Управление обращениями (инцидентами и заявками на обслуживание)”¶
| 3.2.1 |
|
| 3.2.2 | Система должна позволять создавать/редактировать/удалять обращение в соответствии с правами доступа. |
| 3.2.3 | Система должна позволять в описании обращения указывать:подробную информацию об авторе, детальное описание, классификацию (по услугам и SLA, типу запроса, приоритету инициатора), ранжирование (по важности/срочности), связи с услугами, проблемами, конфигурационными единицами и другими обращениями. |
| 3.2.4 | Система должна позволять пользователю с ролью Оператор указывать Исполнителя по обращению и сроков его исполнения. |
| 3.2.5 | Система должна позволять осуществлять маршрут исполнения обращения согласно текущему его статусу. |
| 3.2.6 | В Системе должен быть предусмотрен механизм расчета временных метрик обращения, автоматически определяемый по услуге, SLA, а также с учетом рабочего календаря; |
| 3.2.7 | В Системе должен быть предусмотрен возврат обращений “на доработку” с автоматическим приостановлением расчета временных метрик. |
| 3.2.8 | Система должна предусматривать назначения обращения определенному ответственному или группе, а также назначению ответственного в рамках выбранной группы. Система должна предусматривать возможность переназначения с группы на группу, на ответственного и т.д. |
| 3.2.9 | По завершению работ по обращению, система должна позволять вносить описание решения в запись об обращении, а также осуществлять оценку сервиса. |
| 3.2.10 | Система должна предусматривать возможность завершения обращения без необходимости вносить оценку, принятия инициатором. |
| 3.2.11 | Система должна предоставлять возможность перехода по всем связанным объектам (обращение - проблема- услуга - конфигурационная единица), а также возвращению необходимых значений в связанные объекты, при изменении статуса основного. |
| 3.2.12 | В Системе должна быть возможность выполнять информирование инициатора обращения (e-mail-уведомления) на всех этапах жизненного цикла обращения |
| 3.2.13 | Система должна позволять пользователю с соответствующими правами доступа просматривать список всех обращений, а также осуществлять поиск и фильтрацию по ключевым полям формы. |
| 3.2.14 | Система должна поддерживать интеграцию с электронной почтой на предмет получения записей об обращениях. |
| 3.2.15 | В системе должен быть предусмотрен механизм интеграции с порталом для регистрации обращений, а также просмотра статусов текущих обращений, поданных через портал. |
| 3.2.16 | Система должна предоставлять оператору и исполнителю данные по ранее зарегистрированным обращениям автора. |
| 3.2.17 | Система должна предоставлять возможность отправления обращения внешнему поставщику с расчетом времени завершения по SLA. |
| 3.2.18 | Система должна предоставлять возможность отображения конфигурационных единиц, связанных с автором обращения. |
| 3.2.19 | Система должна предоставлять возможность сотрудникам IT-службы добавлять к обращению комментарии как внутренние, так и общие. |
| 3.2.20 | Система должна предоставлять возможность направления обращения на согласование, а также согласование либо отклонение обращения с вводом комментария. |
| 3.2.21 | Система должна хранить данные результатах согласования на форме обращения. |
| 3.2.22 | Система должна предоставлять возможность указывать проблему, решение которого требуется для дальнейшего разрешения обращения. А также система должна автоматически возвращать обращение в работу исполнителя после завершения проблемы. |
| 3.2.23 | Портал самообслуживания должен предоставлять возможность просмотра информации о пользователе, должности, руководителе. |
| 3.2.24 | Портал самообслуживания должен предоставлять возможность просмотра и редактирования почтового адреса пользователя. |
| 3.2.25 | Портал самообслуживания должен предоставлять возможность изменения авторизационных данных: логина и пароля - с проверкой соответствия системным настройкам. |
| 3.2.26 | Система должна поддерживать возможность интеграции с системой мониторинга Zabbix, основываясь на интеграции с почтой. |
| 3.2.27 | Система должна позволять автоматически направлять обращения в очередь исполнителям на вторую линию. |
| 3.2.28 | Система должна предоставлять возможность закрывать обращения, которые находятся на доработке у инициатора больше 16 рабочих часов. |
| 3.2.29 | Система должна предоставлять возможность массово направлять обращения на очередь, на оценку, на доработку и на ожидание закрытия массового инцидента . |
| 3.2.30 | Система должна предоставлять возможность создания проблемы из обращения. |
| 3.2.31 | Система должна предоставлять возможность регистрировать обращения из снешних систем при помощи API. |
| 3.2.32 | Система должна предоставлять возможность создания запросов на изменение из обращений. |
| 3.2.33 | Система должна предоставлять возможность ручной смены приоритета обращения с автоматическим пересчетом сроков исполнения. |
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 | Система должна позволять указывать связанные с проблемой обращения, решение которых зависит от текущей проблемы. |
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 | Система должна позволять пользователю с соответствующими правами доступа просматривать список всех записей Базы знаний, а также осуществлять поиск и фильтрацию по ключевым полям данных форм. |
| 3.5.5 | Система должна позволять пользователю создавать запись в базе знаний на основе обращения или проблемы. |
| 3.5.6 | Система должна позволять автоматизировать процесс пересмотра и актуализации статей в базе знаний |
4.7. Требования к модулю “Управление конфигурациям蔶
| 3.6.1 | Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа Конфигурационную Единицу по установленной форме |
| 3.6.2 | Система должна позволять пользователю с соответствующими правами доступа просматривать список всех конфигурационных единиц. А также осуществлять поиск и фильтрацию по ключевым полям данных форм. |
4.8. Требования к модулю “Управление изменениям蔶
| 3.7.1 |
|
| 3.7.2 | Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа запрос на изменение (RFC) с заполнением следующей основной информации о запросе. А также дополнительной информации, позволяющей классифицировать данный запрос по важности/срочности, связывать запрос на изменение (RFC) с касающимися его услугами. |
| 3.7.3 | Система должна позволять осуществлять процесс согласования запроса на изменения (RFC) с советом по изменения (CAB), а также с другими заинтересованными лицами. |
| 3.7.4 | Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа на основании запроса на изменение (RFC) запись об изменении CR: определять план реализации и план отката. |
| 3.7.5 | Система должна позволять осуществлять маршрут запроса на изменение согласно его текущему статусу. |
| 3.7.6 | Система должна позволять осуществлять маршрут изменения согласно его текущему статусу. |
| 3.7.7 | Система должна позволять пользователю с соответствующими правами доступа просматривать список всех запросов на изменения (RFC) и записей об изменении (CR), а также осуществлять поиск и фильтрацию по ключевым полям данных форм. |
| 3.7.8 | Система должна позволять уведомлять автора и группу пользователей, поддерживающих IT услугу, о смене статуса запроса на изменение посредством электронной почты. |
4.9. Требования к модулю “Управление доступо씶
| 3.8.1 |
|
| 3.8.2 | Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа Заявку на права доступа по установленной форме. |
| 3.8.3 | Система должна позволять пользователю с соответствующими правами доступа просматривать список всех заявок на права доступа. |
| 3.8.4 | Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа роли к имеющимся системам по установленной форме |
| 3.8.5 | Система должна позволять пользователю с соответствующими правами доступа просматривать список всех ролей. |
| 3.8.6 | Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа Реестр прав доступа по установленной форме |
| 3.8.7 | Система должна позволять пользователю с соответствующими правами доступа просматривать список всех записей в реестре прав доступа. |
| 3.8.8 | В системе должен быть предусмотрен механизм интеграции с порталом для регистрации заявок на права доступа. |
| 3.8.9 | Система должна позволять руководителю согласовать или отклонять заявку на права доступа на портале самообслуживания. |
4.10. Требования к модулю “Управление активам蔶
| 3.9.1 | Система должна позволять создавать/редактировать/удалять в соответствии с правами доступа карточку актива по установленной форме |
| 3.9.2 | Система должна позволять пользователю с соответствующими правами доступа просматривать список всех активов. А также осуществлять поиск и фильтрацию по ключевым полям данных форм. |
| 3.9.3 | Система должна предоставлять возможность информировать определенных лиц об истечении сроков по документам актива путем отправления уведомления на почту. |