1.1.2 Нефункциональные требования
NFR-1. Стек технологий, используемый в ходе разработки системы, должен соответствовать стеку технологий, используемому компанией на внутренних проектах для удобства поддержки.
NFR-2. Система должна быть интегрирована с основной внутренней корпоративной системой управления персоналом.
NFR-3. Система должна быть интегрирована с внутренней корпоративной системой отдела финансов.
NFR-4. Клиентская часть системы должна быть разработана под браузер Google Chrome версии 80.0 и выше.
NFR-5. Выдача прав для пользовательских ролей и динамическая видимость должны быть реализованы через внутреннюю корпоративную систему контроля доступа - Access Control.
NFR-6. Персональные данные и денежные суммы должны быть зашифрованы.
NFR-7. Клиентская часть веб-приложения Hiring должна являться независимым динамическим модулем существующего приложения Host Application, который не взаимодействует с другими модулями приложения и имеет независимый деплой.
NFR-8. Пользователь должен быть повторно аутентифицирован и авторизован через Vault.
NFR-9. Веб-приложение должно быть протестировано вручную по пользовательским сценариям, CRUD-функциональность должна быть покрыта unit-тестами.
NFR-10. Система должна быть интегрирована с предоставляющим свой REST API корпоративным абстрактным сервисом File Storage, реализующим облачное хранилище файлов для шифрования и дешифрования ключей которых необходима регистрация в File Storage Vault токена авторизации.
Глава 2. Проектирование архитектуры системы и описание логики взаимодействия ее компонентов
2.1 Системная архитектура
Веб-приложение
Hiring
будет развернуто в OpenShift-кластере,
представленном на диаграмме, изображенной
на рисунке 2.
Рисунок 2 – Диаграмма компонентов системы
На рисунке 2 представлены следующие компоненты системы:
Host Application – уже разработанный Angular микрофронтенд, интерфейс которого представляет собой меню, из которого можно попасть в существующие модули портала. Данный микрофронтенд будет доработан таким образом, чтобы из его меню также можно было попасть в Hiring при наличии доступа. В Host Application сконфигурирован сервер, реализованы авторизация и маршрутизация между существующими модулями портала, которые будут доработаны в ходе разработки Hiring, а также реализованы модели и сервисы, некоторые из которых будут использоваться в Hiring (подробнее в подразделе 2.5). В ходе разработки Hiring в Host Application будут реализованы новые сервисы,
MUI Platform Microservice – реализованный бэкенд-микросервис, предоставляющий доступную по REST API функциональность, необходимую для деплоя микрофронтендов, в том числе “Hiring” (подробнее см. в разделе 2.4.1. “Microservices UI Platform Framework”),
Identity Provider – написанный на базе KeyCloak [10] корпоративный сервис, предоставляющий поддержку OpenID Connect протокола и готовое Single Sign-On решение. В ходе разработки “Hiring” c помощью Identity Provider будет создана и выдана новая пользовательская роль для доступа к “Hiring”,
HashiCorp Vault – сервис, обеспечивающий надёжное хранение и распространение секретов, который будет интегрирован в систему для обеспечения шифрования конфиденциальных данных и документов в Hiring, а также реализации безопасного доступа к этим данным посредством повторной аутентификации и авторизации пользователя через Vault [5]. Расположение Vault в отдельном от остальной инфраструктуры приложения OpenShift-кластере обусловлено необходимостью ограничить доступ к ключам шифрования,
Backend Infrastructure – реализация бэкенд архитектуры веб-приложения.