Техническое задание на разработку кабинета для клиента по электронным деньгам (Юнекс банк)

Техническое задание на разработку кабинета для клиента

по электронным деньгам (Юнекс банк)

1. Вступление

Этот документ является основой для разработки и создания системы электронных денег в ПАТ «ЮНЕКС БАНК».

Этот документ определяет требования к Системе электронных денег,  в т. ч. требования к интеграции с внешними и внутренними источниками данных.

Требования к Системе определяются как:

Бизнес-требования – верхнеуровневые цели, которые определяются заказчиком Системы; Требования пользователей – цели и задачи пользователей, которые будут решаться Системой; Функциональные требования – функциональность Системы, которую будут строить разработчики, а также системные требования – описание технических характеристик для возможности работы программного обеспечения; Нефункциональные требования – требования, определяющие работу Системы в целом (системные свойства).

2. Термины и определения.

ПРОСТIР – национальная система платежных карт Украины Система – Система электронных денег Электронные деньги – единицы стоимости, которые сохраняются на электронном носителе и принимаются как средство платежа неэмитентами и являются денежным обязательством эмитента Клиент банка – лицо зарегестированное в АБС SRBANK Клиент/пользователь Системы – лицо использующее Систему, но не являющееся клиентом банка Backend Системы – набор сервисов, имплементирующих основную программно-аппаратную часть Frontend Системы – набор клиентских приложений, имплементирующих интерфейс взаимодействия между пользователем Системы и ее Backend’ом

3. Назначение Системы. Основные требования к Системе.

Основные бизнес – требования:

работа на базе платежной системы «ПРОСТIР»; автоматизация учета электронных денег; привлечение неклиентов банка; максимальный контроль бизнес-процесса;

Основные требования пользователей:

интуитивно понятный интерфейс; удобство в использовании (usability); простота сопровождения; стабильность работы; простота работы с Системой.

Основные функциональные требования:

создание, аутентификация и авторизация пользователей; возможность создать новый кошелек; просмотр авторизационных остатков; возможность перевода с кошелька на кошелек; возможность ввода и вывода денежных средств посредством любой МПС; возможность просмотра истории по операциям; возможность редактирования данных пользователя; административный интерфейс для просмотра активности пользователей; возможность поиска/транзакции пользователя в административном интерфейсе; разграничение прав доступа в административный интерфейс согласно ролевой модели; возможность построения отчетов о транзакциях в разрезе системы/клиента с возможностью фильтрации по времени в xls/csv; формирование выписки по операции по запросу клиента; возможность привязки клиента-пользователя электронных денег к клиенту банка; возможность прикрепления, сохранения, печати и транспортировки файлов (документов в электронном виде в формате doc. xls. рdf. jpg.); возможность установления/изменения/отмены порядка прикрепления, сохранения, печати и транспортировки файлов (документов в электронном виде в формате doc. xls. рdf.  jpg.) администратором Системы на каждом этапе бизнес-процесса;  хранение истории действий пользователей.

Основные нефункциональные требования (атрибуты качества):

отказоустойчивость и устойчивость к ошибкам, масштабируемость, простота сопровождения, удобство использования, защищенность, надежность,

4. Бизнес-процесс

5. Этапы бизнес-процесса

5.1. Регистрация

При регистрации пользователю необходимо отобразить экран для ввода данных с такими полями:

- Логин (номер мобильного телефона)

- Пароль

- Подтверждение пароля

- Чекбокс о согласии с Условиями и Правилами

После успешного ввода данных необходимо отправить на номер телефона пользователя код подтверждения и открыть пользователю форму для ввода кода подтверждения. После успешной проверки введенного кода пользователь попадает в личный кабинет.

5.2 Авторизация

При авторизации пользователю необходимо отобразить экран для ввода данных с такими полями:

- Логин (номер телефона)

- Пароль

Двухфакторная аутентификация.

После успешной проверки пароля необходимо отправить на номер телефона пользователя код подтверждения и открыть пользователю форму для ввода кода подтверждения.

После успешной проверки введенного кода пользователь попадает в личный кабинет.

5.3. Личный кабинет

На главном экране личного кабинета необходимо отображать такие данные:

- Идентификатор пользователя в системе;

- Идентификатор кошелька пользователя в системе;

- Баланс кошелька в системе;

- История операций за последнюю неделю;

- Кнопку поиска по истории по нажатию на которой открывается фильтр по датам со строкой поиска;

- Кнопку пополнить баланс по нажатию на которой необходимо ввести данные карты с которой будет осуществлено пополнение и сумму пополнения;

- Кнопку вывести средства по нажатию на которую необходимо ввести сумму и данные карты, в пользу которой будет осуществлено списание;

- Кнопку выставить счет, по нажатию на которую необходимо ввести сумму и номер телефона, пользователю которого будет выставлен счет;

- Кнопку история, по нажатию на которую идет переход в историю операций;

- По каждой операции можно сформировать и распечатать выписку (и /или вывести на просмотр);

- Кнопку редактировать личные данные, по нажатию на которую открывается редактирование профиля пользователя.

5.4. Открытие кошелька(карты)

Карты необходимо открывать на базе платежной системы «ПРОСТIР». По запросу в систему учета карточных данных выдается пул свободных prepaid-карт, которые можно привязать к учетной записи клиента. При привязке карты необходимо сообщить о том, что эта карта использована запросом к системе учета карточных данных, эта карта будет убрана из ответа на следующий запрос пула свободных карт. К этой карте применяются все действующие ограничения и лимиты, согласно установленных законодательными актами Украины.

Ограничения должны распространятся на электронный кошелек, согласно нормативов НБУ.

6. Требования к backend’у системы

6.1. Принципы построения

Backend Системы должен быть построен на базе микросервисной архитектуры с вынесением всех критичных модулей в отдельные сервисы с возможностью их отдельного запуска. Каждый из этих сервисов должен обладать следующими качествами:

- Ограниченный контекст;

- Быстрое масштабирование;

- Слабая связанность;

- Собственный источник данных.

И должен обладать следующими возможностями:

- health check

- REST API

- асинхронность

- кроссервисная авторизация

- кеширование

6.2. Управление

Управление backend Системы должно производиться посредством веб-интерфейса администратора, в который должны быть вынесены все базовые функции, такие как:

- запуск нового сервиса;

- реконфигурация сервиса;

- остановка, перезапуск сервиса;

- просмотр логов сервиса;

- мониторинг сервиса;

- управление сетями;

- управление административными пользователями.

6.3. Безопасность

Авторизация в рамках системы должна быть централизованной, построенной на базе JWT с соблюдением рекомендаций OWASP

Все действия в системе должны быть залогированы и сохранены в журнал на базе elasticsearch.

6.4. Масштабирование и отказоустойчивость

Система должна иметь возможность масштабироваться вертикально и горизонтально, учитывая все элементы, включая базу данных.

В случае отказа какого-либо из сервисов остальные сервисы должны продолжать работу.

Для обеспечения отказоустойчивости необходимо использовать систему очередей (Message Queue)

6.5. Интеграция

Система должна быть построена на базе платежной системы «ПРОСТIР», с возможностью проведения переводов через системы VISA и MASTERCARD.

Необходима интеграция с АБС SRBANK (детали будут уточнены или предоставлены по запросу), а также с процессингом Укркарт.

Клиенты в рамках Системы должны храниться отдельно с возможностью их выгрузки в АБС SRBANK, а также их загрузки из АБС.

7. Frontend системы (клиентский)

7.1. Принципы построения

Frontend Системы должен быть построен на базе AngularJS не ниже 2 версии с разбиением на отдельные модули.

Должны быть разработки приложений  для Android&IOS.

7.2. Управление

Frontend Системы должен представлять из себя набор статичных js, css и html файлов, роутинг должен осуществляться непосредственно средствами AngularJS, серверные редиректы и т. п. недопустимы.

7.3. Безопасность

Frontend Системы должен соответствовать рекомендациям OWASP TOP 10, если следование рекомендациям невозможно, необходимо предоставить исчерпывающее объяснение, почему невозможно.

7.4. Масштабирование

Frontend Системы должен быть подготовлен к распространению через CDN

7.5. Интеграция

Frontend Системы должен быть интегрирован с Backend Системы через REST API

8. Прочие требования

8.1. Передача кода на сторону Банку

Обеспечить передачу Банку программного кода,  описания компонентов файлов ПО в полном объеме.

Передача осуществляется по актам приема-передачи с учетом условий договоров.

8.2. Лицензирование

ПО передается Банку одновременно с  имущественными правами  согласно соответствующего  договора (лицензия на использование объекта права интеллектуальной собственности/лицензионный договор/договор о создании на заказ и использование объекта права интеллектуальной собственности/и пр.) на правах неисключительной лицензии. Банк может использовать ПО своему усмотрению и передавать/продавать третьим лицам.

8.4. Сопровождение

Описание компонентов файлов ПО передается с учетом возможности последующего сопровождения (модификации) на стороне Банка.

Предложение должно быть сформулировано с возможностью сопровождения ПО компанией с указанием стоимости.

8.5. Сроки

Срок реализации – 3 месяца.