Глава 1. Постановка задачи, формирование требований к системе
Выполнение работы осуществляется в рамках решения глобальной задачи по декомпозиции существующей монолитной корпоративной системы и переносу ее в OpenShift. Ввиду низких производительности и отказоустойчивости, слабой масштабируемости и наличия серьезных архитектурных изъянов существующего программного решения, его доработка не представлялась целесообразной. Описываемые в рамках выполнения работы задачи фактически являются частью глобальной задачи разработки веб-приложения Hiring, являющегося модулем новой облачной корпоративной системы. Поскольку процесс декомпозиции и развертывания в OpenShift ряда модулей уже был реализован, была поставлена задача интегрировать клиентскую часть Hiring в частично реализованное на момент разработки решение. Помимо необходимости пересмотра архитектуры клиентской части приложения, реализации и усовершенствования старой функциональности модуля была поставлена задача реализовать ряд новой функциональности в виде отправки нотификаций, генерации отчета, интеграции с абстрактным файловым хранилищем для работы с документами, реализации безопасного доступа к зашифрованным данным и других не столь значительных доработок UX/UI.
1.1 Функциональные и нефункциональные требования к системе
Основной объект, c которым происходит работа в системе – так называемая “заявка на найм”. Для упрощения описания требований и процессов в дальнейшем этот объект будет именоваться Hiring Request.
Для работы с данным веб-приложением будет создана новая пользовательская роль – HR-Hiring. Функциональные требования, перечисленные в подпункте 1.1.1, определены для этой роли.
1.1.1 Функциональные требования
FR-1. Пользователь должен иметь возможность создать Hiring-Request с возможностью перехода к редактированию существующего, в случае если Hiring-Request с введенными на 1 шаге заполнения мастер-формы данными уже существует в системе.
FR-2. Пользователь должен иметь возможность просмотреть следующие данные по доступному ему Hiring-Request’y, перейдя на него с одного из дашбордов:
Общую информацию по Hiring-Request’y (раздел “Summary”),
Финансовую информацию Hiring-Request’а (раздел “Financial Info”),
Информацию по возможной релокации сотрудника (раздел “Relocation Info”),
Информацию, касающуюся требований по выделяемому сотруднику оборудованию (раздел “IT Equipment Request”),
Документы, прикрепленные к Hiring Request’y (раздел “Attachments”).
FR-3. Пользователь должен иметь возможность отредактировать данные каждого из разделов Hiring-Request’а.
FR-4. Пользователь должен иметь возможность просмотреть доступные ему активные Hiring-Request’ы в таблице на дашборде “Requests in Progress” и значения следующих атрибутов каждого из них:
Офис, в который планируется найм сотрудника,
Город, в котором планируется найм сотрудника,
Предполагаемая дата выхода сотрудника на работу,
Непосредственный руководитель сотрудника,
Статус Hiring-Request’а,
Статус обработки заявки на предоставление сотруднику IT-оборудования.
FR-5. Пользователь должен иметь возможность просмотреть все архивные Hiring-Request’ы в таблице на дашборде “Archive” и значения следующих атрибутов каждого из них:
Офис, в который планируется найм сотрудника,
Город, в котором планируется найм сотрудника,
Предполагаемая дата выхода сотрудника на работу,
Непосредственный руководитель сотрудника,
Статус Hiring-Request’а,
Статус обработки заявки на предоставление сотруднику IT-оборудования.
FR-6. Пользователь должен иметь возможность осуществить поиск по Hiring-Request’ам на каждом из дашбордов.
FR-7. Пользователь должен иметь возможность осуществить фильтрацию по значению полей таблицы на каждом из дашбордов.
FR-8. Пользователь должен иметь возможность осуществить сортировку по значению полей таблицы на каждом из дашбордов.
FR-9. Пользователь должен иметь возможность просмотреть Progress Info Hiring-Request’а, демонстрирующее стадию обработки Hiring-Request’а на каждом из основных этапов найма, на каждом из дашбордов и на странице Hiring-Request’а (вкладка “Summary”).
FR-10. Пользователь должен иметь возможность скрывать видимость всех колонок таблиц дашбордов, кроме названия Hiring-Request’а и его Progress Info.
FR-11. Пользователь, после ряда проверок со стороны фронтенда, должен иметь возможность скачать на свой ПК нотификацию “New Hire” –
письмо в EML-формате с предварительно заполненными данными для уведомления коллег и других отделов о найме сотрудника.
FR-12. Пользователь, после ряда проверок со стороны фронтенда, должен иметь возможность скачать на свой ПК нотификацию “Finance Group” – письмо в EML-формате с предварительно заполненными данными для уведомления Finance Group (бухгалтерия) о выходе нового сотрудника. Письмо скачивается автоматически в случае успешных проверок, в противном случае пользователь видит на экране уведомление, поясняющее причину невозможности скачивания письма.
FR-13. Пользователь, после ряда проверок со стороны фронтенда, должен иметь возможность скачать на свой ПК нотификацию “Payroll Group” – письмо в EML-формате с предварительно заполненными данными для уведомления Payroll Group (отдел кадров) о выходе нового сотрудника. Письмо скачивается автоматически в случае успешных проверок, в противном случае пользователь видит на экране уведомление, поясняющее причину невозможности скачивания письма.
FR-14. Пользователь должен иметь возможность завершить найм сотрудника с сохранением статуса, из которого он был завершен, для реализации возможного повторного открытия Hiring-Request’а.
FR-15. Пользователь должен иметь возможность отменить найм сотрудника с автоматическим скачиванием на ПК пользователя предварительно заполненного письма в EML-формате для информирования об этом должных лиц после повторного подтверждения действия. Статус, из которого Hiring-Request был отменен, сохраняется для возможного повторного открытия Hiring-Request’а.
FR-16. Пользователь должен иметь возможность повторного открытия Hiring-Request’а, находящегося на дашборде “Archive”.
FR-17. После ряда проверок со стороны фронтенда, при успешном их прохождении, пользователь должен иметь возможность сгенерировать и скачать на свой ПК PEP-Form для Hiring-Request’а в DOCX-формате, в противном случае пользователь видит на экране уведомление, поясняющее причину невозможности скачивания письма.
FR-18. Пользователь, после ряда проверок со стороны фронтенда, должен иметь возможность скачать на свой ПК нотификацию “Change Start Date” – письмо в EML-формате с предварительно заполненными данными для уведомления о смене даты выхода нового сотрудника в офис. Письмо скачивается автоматически.
FR-19. Пользователь, после ряда проверок со стороны фронтенда, должен иметь возможность скачать на свой ПК нотификацию “IT Equipment Approval” – письмо в EML-формате с предварительно заполненными данными для согласования с менеджером сотрудника запроса на предоставление IT-оборудования этому сотруднику. Письмо автоматически отправляется с системной почты.
FR-20. Пользователь после ряда проверок со стороны фронтенда, должен иметь возможность скачать на свой ПК нотификацию “IT Equipment Request” письмо в EML-формате с предварительно заполненными данными для уведомления о необходимости предоставления сотруднику IT-оборудования. Письмо автоматически отправляется с системной почты.
FR-21. Пользователь должен иметь возможность принудительно отметить процесс предоставления сотруднику IT-оборудования как завершенный, в случае если подтверждение необходимости предоставления оборудования не было получено в срок.
FR-22. Пользователь должен иметь возможность сконфигурировать параметры для отчета по Hiring Request’ам и скачать отчет на свой ПК в XLSL-формате.
FR-23. В случае если нанимаемый сотрудник в прошлом уже работал в компании, пользователь должен иметь возможность связать Hiring Request этого сотрудника с кодом этого сотрудника из корпоративной системы отдела кадров.
FR-24. Иконка веб-приложения Hiring в меню портала должна быть видима только при наличии у пользователя доступа к Hiring.
FR-25. Пользователь должен иметь возможность просмотреть шаблоны документов доступные для Hiring Request’а на данном этапе его обработки, а также документы, прикрепленные к этим шаблонам на вкладке “Attachments”.
FR-26. Пользователь должен иметь возможность обновить список доступных для Hiring Request’а шаблонов документов на вкладке “Attachments”.
FR-27. Пользователь должен иметь возможность скачать шаблон документа, доступный для данного Hiring Request’a со вкладки “Attachments”.
FR-29. Пользователь должен иметь возможность загрузить документ, прикрепив его к доступному шаблону на вкладке “Attachments”.
FR-30. Пользователь должен иметь возможность удалить прикрепленный к шаблону документ на вкладке “Attachments”.
На рисунке 1 представлена диаграмма вариантов использования:
Рисунок 1 – Диаграмма вариантов использования [9]
(ключевые функции системы выделены цветом для упрощения визуального восприятия диаграммы)