• 3А. Если валидация данных не прошла:

  1. Система уведомляет арендатора о необходимости заменить вводимые данные.

  2. Арендатор заменяет данные.

  3. Арендатор отправляет данные в систему.

  4. Система проверяет корректность данных (валидация email, проверка уникальности).

Специальные требования:

• На шаге 4 необходимо обеспечить безопасное хранение паролей (хэширование).

Список технологий и типов данных:

Для реализации прецедента используются: валидация данных (регулярные выражения, API проверки уникальности), безопасное хранение паролей (хэширование, например, bcrypt), интеграция с почтовыми сервисами (SMTP или SendGrid/Mailgun), база данных (PostgreSQL или MongoDB) и фронтенд (HTML/CSS/JavaScript). Типы данных включают строки (имя, email, хэшированный пароль) и файлы (PDF/JPEG/PNG для документов).

Частота использования: постоянно.

Открытые вопросы:

• Какие форматы документов допустимы для загрузки (только PDF или также изображения)?

• Требуется ли двухфакторная аутентификация для входа в систему?

Прецедент П3. Контроль работы системы

Рамки. Система управления арендуемой недвижимостью. Уровень. Нефункциональное требование. Основной исполнитель. Администратор.

Заинтересованные лица и их требования:

• Администратор. Хочет контролировать работу системы, своевременно выявлять ошибки и устранять их.

• Арендодатель и арендатор. Заинтересованы в стабильной работе системы.

Предусловия. Система находится в рабочем состоянии.

Результаты. Администратор получил информацию о работе системы и устранил выявленные проблемы.

Основной успешный сценарий:

1. Администратор запрашивает данные о производительности, ошибках и логах у системы.

2. Система отображает данные.

3. Администратор анализирует данные и выявляет проблемы.

4. Администратор устраняет выявленные проблемы.

Расширения:

• 3А. Если обнаружена критическая ошибка:

  1. Система автоматически уведомляет администратора о необходимости срочного вмешательства.

  2. Администратор принимает меры для устранения ошибки.

Специальные требования:

• На шаге 1 требуется интеграция с инструментами мониторинга.

• Необходимо обеспечить сбор и анализ логов для выявления ошибок.

Список технологий и типов данных:

Для контроля работы системы используются инструменты мониторинга (Grafana, Prometheus), системы сбора логов (ELK-стек), механизмы уведомлений (Slack, Telegram, Email API), базы данных для хранения логов и метрик (PostgreSQL, TimescaleDB), а также средства оркестрации (Docker, Kubernetes). Типы данных включают логи (текст ошибок, временные метки), метрики (загрузка CPU/RAM, время ответа API) и уведомления (текст ошибки, уровень критичности).

Частота использования: постоянно.

Открытые вопросы:

• Какие критерии используются для определения «критической ошибки»?

• Кто, кроме администратора, получает уведомления о критических сбоях (например, разработчики)?

• Как обрабатываются ложные срабатывания мониторинга (например, временные скачки нагрузки)?

Прецедент П4. Оплата аренды

Рамки. Система управления арендуемой недвижимостью. Уровень. Задача, определенная пользователем. Основной исполнитель. Арендатор.

Заинтересованные лица и их требования:

• Арендатор. Хочет произвести оплату аренды онлайн.

• Арендодатель. Заинтересован в своевременном получении платежей.

• Администратор. Требует, чтобы все транзакции фиксировались и были прозрачными.

Предусловия. Арендатор выбрал объект и получил счет на оплату.

Результаты. Оплата произведена, арендодатель уведомлен, транзакция зафиксирована.

Основной успешный сценарий:

1. Система отправляет счет на оплату арендатору.

2. Арендатор выбирает способ оплаты.

3. Система перенаправляет арендатора на страницу платежной системы.

4. Арендатор вводит необходимые данные и подтверждает оплату.

5. Платежная система обрабатывает транзакцию и возвращает результат в систему.

6. Система фиксирует оплату и уведомляет арендодателя.

Альтернативные потоки: