...
Опис Функціональних вимог присутній в ТЗ до конкретного продукту
Нефункціональні вимоги
Нефункціональні вимоги
1. Використання програмного забезпечення
Використання вільно розповсюджуваного програмного забезпечення.
Рівень відкритості програмного забезпечення
...
має бути сумісним з ліцензією Apache 2.0.
Незалежність рішення від пропрієтарних сервісів,
...
включаючи сервіси хостинг-провайдерів
...
Мають використовуватись технології, для яких час закінчення життєвого циклу на момент прийняття рішення про використання не визначено або складає більше одного року
...
.
2. Життєвий цикл технологій
Використовувані технології повинні мати невизначений або щонайменше річний залишковий життєвий цикл на момент прийняття рішення.
3. Архітектурні вимоги
Використання контейнеризації (та оркестрації контейнерів)
...
для всіх оточень.
Виключення компонентів, чия втрата може спричинити значні втрати даних або функціональності.
Механізми синхронізації даних
...
та
...
паралельної обробки
...
повинні гарантувати відсутність конфліктів
...
.
Наявність механізмів повторних спроб
...
або використання проміжних черг між
...
компонентами
...
.
...
Орієнтація на асинхронну комунікацію між компонентами.
Можливість
...
"гарячого" додавання інстансів будь-яких
...
компонентів.
4. Тестування та продуктивність
Покриття коду юніт-тестами має
...
бути ≥85%
...
Покриття автоматизованими тестами має сукупно забезпечувати перевірку роботи всіх критичних бізнес-процесів
...
.
Автоматизоване тестування повинно перевіряти всі критичні бізнес-процеси.
Розробка універсального пакету автотестів для перевірки взаємодії клієнта (майданчика) з
...
Має бути виконано навантажувальне тестування, за результатами якого був би складений профайл конфігурації відповідно до очікуваної кількості одночасних та історичних артефактів в системі (кількість аукціонів, кількість учасників на аукціон, кількість процедур, кількість змін статусів, очікувані затримки під навантаженням, уповільнення відповідно до росту об’єму даних тощо)
Управління через конфігурацію (без потреби змінювати код та перевстановлювати сервіси) всіма змінними, що присутні в бізнес-логіці: набір періодів, тривалість періодів, набори даних процедури тощо
Зберігання усіх текстів, що відображаються в модулі аукціонів або на інших сторінках, у конфігураційних файлах
Можливість відновлення з бекапів бази в цілому, документів окремої процедури, окремих дій (репроцесинг черги/логів)
Наявність автоматизованої збірки контейнерів
Наявність автоматизованого деплойменту на різні оточення
...
API.
Проведення навантажувального тестування з профайлінгом конфігурації відповідно до очікуваного навантаження.
5. Гнучкість налаштувань
Управління змінними бізнес-логіки через конфігурацію без зміни коду.
Збереження текстів інтерфейсу в конфігураційних файлах.
Можливість відновлення даних з бекапів (ціла база, окрема процедура, окремі дії).
6. Автоматизація розгортання
Автоматизована збірка контейнерів.
Автоматизований деплоймент на різні оточення.
7. Управління доступом та безпека
Максимальне розділення доступу для окремих клієнтів (майданчиків).
...
Логування всіх дій адміністратора,
...
що впливають на бізнес-логіку.
Адміністратор не повинен мати доступу до ставок до початку аукціону.
...
Керування доступом майданчика через мережеві обмеження (білий список
...
IP) та
...
ключі доступу.
...
Швидке внесення змін
...
у доступи майданчиків.
Доступ до компонент, що не передбачають зовнішньої комунікації (тобто всіх, окрім публічних АРІ та АРІ для майданчиків) має бути заборонений на рівні мережі та доречним механізмом авторизації
Доступ безпосередньо до елементів інфраструктури має здійснюватись через єдиний шлюз
АРІ, відкриті узовні, мають надавати ті і тільки ті можливості, що прямо передбачені узгодженою документацією
Повсемісно має використовуватись безпечне (шифроване) з’єднання
Управління доступом до елементів ЕТС на основі рольової моделі
Логування всіх дій по зміні станів та проміжних станів даних по кожній процедурі
...
Заборона доступу до внутрішніх компонентів через мережеві обмеження та механізми авторизації.
Єдиний шлюз для доступу до інфраструктури.
API повинні надавати лише ті можливості, які передбачені документацією.
Використання лише безпечних (шифрованих) з’єднань.
Управління доступом на основі рольової моделі.
8. Логування
Логування всіх змін станів процедур.
Логування дій майданчиків (бізнес-дані, API виклики).
Логування дій користувачів модуля аукціону
...
, включаючи помилки фронтенду.
Можливість відстеження пов’язаних дій у межах однієї логічної транзакції (trackID).
Логування роботи оркестратора, контейнерів, ОС та інфраструктурних сервісів.
Автоматична ротація технічних логів.
9. Інтерфейс та UX
Коректне відображення у популярних браузерах
...
Можливість відслідкувати усі пов’язані дії для однієї логічної транзакції, що виконувались різними сервісами (trackID)
Технічний лог поведінки оркестратора, контейнерів, операційних систем, інфраструктурних сервісів тощо в об’ємі достатньому для продуктивного супроводження системи
Наявність автоматичної ротації технічних логів.
...
(Chrome, Firefox, Safari, Edge, IE).
В інтерфейсах має бути використаний дизайн, що автоматично адаптується під розміри екрану та тип пристрою користувача
...
Дизайн повинен бути адаптивним до різних екранів і пристроїв.
Повідомлення про помилки мають бути зрозумілими та містити рекомендації щодо їх усунення.
Вимоги до видів забезпечення
...