127 lines
5.2 KiB
Markdown
127 lines
5.2 KiB
Markdown
# Документ 04. Non-Functional Requirements
|
||
|
||
## Назначение
|
||
|
||
Документ определяет нефункциональные требования (NFR) к платформе Agent
|
||
Control Center. Они являются обязательными для всех компонентов системы
|
||
и используются как критерии архитектурных решений и приемки.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
# NFR-001 Производительность
|
||
|
||
Система должна:
|
||
|
||
- поддерживать не менее 100 одновременных пользователей для MVP;
|
||
- обеспечивать время ответа API (P95) менее 500 мс для операций
|
||
чтения;
|
||
- запускать задачи без заметных задержек при штатной нагрузке;
|
||
- поддерживать горизонтальное масштабирование.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
# NFR-002 Надежность
|
||
|
||
Требования:
|
||
|
||
- отсутствие единой точки отказа для критических компонентов;
|
||
- автоматическое восстановление после кратковременных сбоев;
|
||
- повторная обработка временных ошибок;
|
||
- сохранение состояния длительных задач.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
# NFR-003 Масштабируемость
|
||
|
||
Архитектура должна позволять:
|
||
|
||
- масштабировать API независимо;
|
||
- масштабировать обработчики задач;
|
||
- подключать дополнительные коннекторы без изменения ядра;
|
||
- добавлять новые AI-провайдеры через адаптеры.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
# NFR-004 Безопасность
|
||
|
||
Обязательные требования:
|
||
|
||
- TLS для всех сетевых соединений;
|
||
- безопасное хранение секретов;
|
||
- разграничение доступа по ролям;
|
||
- журналирование критических действий;
|
||
- защита от повторного выполнения чувствительных операций.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
# NFR-005 Наблюдаемость
|
||
|
||
Система должна предоставлять:
|
||
|
||
- структурированные журналы;
|
||
- метрики;
|
||
- трассировку запросов;
|
||
- проверки состояния (health checks);
|
||
- мониторинг очередей и фоновых задач.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
# NFR-006 Поддерживаемость
|
||
|
||
Кодовая база должна:
|
||
|
||
- иметь модульную структуру;
|
||
- сопровождаться документацией;
|
||
- покрываться автоматическими тестами;
|
||
- поддерживать обратную совместимость публичных API.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
# NFR-007 Совместимость
|
||
|
||
Платформа должна:
|
||
|
||
- работать на Linux;
|
||
- поддерживать контейнеризацию;
|
||
- использовать PostgreSQL как основную СУБД;
|
||
- обеспечивать совместимость с OpenAPI 3.x.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
# NFR-008 Тестируемость
|
||
|
||
Для каждого функционального требования должны существовать:
|
||
|
||
- unit-тесты;
|
||
- интеграционные тесты;
|
||
- контрактные тесты (при необходимости);
|
||
- критерии приемки.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
# NFR-009 Эксплуатация
|
||
|
||
Необходимо обеспечить:
|
||
|
||
- централизованную конфигурацию;
|
||
- безопасное обновление компонентов;
|
||
- резервное копирование данных;
|
||
- документированные процедуры восстановления.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
# NFR-010 Качество
|
||
|
||
Все изменения должны проходить:
|
||
|
||
- статический анализ;
|
||
- автоматические проверки;
|
||
- код-ревью;
|
||
- регрессионное тестирование.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
## Traceability
|
||
|
||
Каждое NFR должно иметь связь с: - архитектурными решениями; -
|
||
тестами; - эксплуатационной документацией; - критериями приемки.
|