Архитектура · Средняя
Зафиксировать нефункциональные требования
Определить требования к скорости, надежности, безопасности, масштабированию, хранению данных и эксплуатации до проектирования решения.
Быстро понять за 2 минуты
Определить требования к скорости, надежности, безопасности, масштабированию, хранению данных и эксплуатации до проектирования решения. На выходе: нефункциональные требования записаны в задаче или ADR.
Контекст
Пункт относится к этапу «Архитектура». Его задача — превратить рабочее действие в проверяемый результат. Он нужен до передачи результата frontend, QA, DevOps и владельцу продукта: иначе команда рискует обсуждать только бизнес-функции и забывать про эксплуатацию.
Что это дает
Нефункциональные требования часто вспоминают слишком поздно. Если их зафиксировать заранее, архитектура не будет случайной, а решения по кешу, очередям, индексам и отказоустойчивости станут обоснованными.
Как выполнить
- Соберите ожидания по latency, нагрузке, объему данных, доступности, безопасности и срокам хранения.
- Переведите ожидания в измеримые ограничения: p95, RTO, RPO, лимиты запросов, права доступа.
- Согласуйте, какие требования обязательны сейчас, а какие можно отложить.
Критерии приемки
- Нефункциональные требования записаны в задаче или ADR.
- Для ключевых требований есть измеримые значения.
- Архитектурное решение ссылается на эти ограничения.
Типичные ошибки
- Обсуждать только бизнес-функции и забывать про эксплуатацию.
- Писать требования словами “быстро” и “надежно” без чисел.
- Закладывать избыточную сложность без реальной необходимости.
Инструменты
Рабочий артефакт
Architecture note
Список NFR для backend-решения
Пример для разработки серверного модуля: специалист начинает с действия «Соберите ожидания по latency, нагрузке, объему данных, доступности, безопасности и срокам хранения». Затем фиксирует результат в рабочем артефакте и передает его команде. Пункт считается выполненным только когда выполнено условие: «Нефункциональные требования записаны в задаче или ADR».
- Bounded context
- Dependencies
- Domain entities
- Risk areas
Контроль качества
Карта границ сервиса
Нефункциональные требования записаны в задаче или ADR.
После изменения контрактов, релизов, инцидентов, роста нагрузки и пересмотра архитектурных решений.
Контракт, ограничения, сценарии отказа, метрики, владельца сервиса и критерии готовности.
Перед отметкой выполнено: Нефункциональные требования записаны в задаче или ADR.
Как применять
Начинайте с границ ответственности и пользовательского сценария, который обслуживает система. Затем проверьте контракт, данные, отказоустойчивость, безопасность и наблюдаемость. Хороший backend-пункт фиксирует, что именно меняется, как это проверить и какие метрики покажут стабильность решения.
Режим обучения
Тест по теме
Проверка понимания
Ответьте на вопросы по материалу и получите итоговый отчет: что понято хорошо, а что стоит перечитать.