Требования¶

Первый шаг System Design. Отвечает на вопрос «что и зачем строим». Без требований архитектурные решения не с чем сверить: нельзя сказать, хороша ли архитектура, если неизвестно, что от неё нужно.

Часть требований	Решаемый вопрос
Context & Stakeholders	Кто пользователи и заказчики, с какими внешними системами граничим, что входит в scope?
Functional (FR)	Что система должна делать -- ключевые сценарии и use cases?
Quality Attributes (NFR)	Какими свойствами система должна обладать -- измеримо?
Constraints	Что задано заранее -- бюджет, сроки, команда, стек, законы, legacy?
Capacity Estimation	Какая нагрузка -- пользователи, RPS, read/write, объём данных и его рост?

Context & Stakeholders¶

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

Что выяснить:

Цель: какую бизнес-проблему решает система и как поймём, что решила (бизнес-метрики).
Пользователи: какие роли, сколько их, откуда работают (web, mobile, API, внутренние сотрудники).
Окружение: с какими внешними системами интегрируемся -- платёжки, IdP, ERP, legacy, партнёрские API.
Scope: что входит в систему и, что не менее важно, что не входит (out of scope).

Артефакты: список стейкхолдеров с их интересами, C4 Context Diagram (система как чёрный ящик, вокруг -- люди и внешние системы), глоссарий терминов предметной области.

У разных стейкхолдеров разные приоритеты: бизнесу важны сроки и фичи, эксплуатации -- стабильность и наблюдаемость, безопасности -- контроль доступа. Конфликты между ними решаются на этом шаге, а не во время разработки.

Functional Requirements (FR)¶

Функциональное требование -- что система делает: функция, сценарий, реакция на действие.

Формы записи:

Use Case -- подробный сценарий: актор, предусловия, основной поток шагов, альтернативные потоки, исключения.
User Story -- короткая формулировка: «Как роль, я хочу действие, чтобы ценность», плюс критерии приёмки.

Правила:

У каждого требования уникальный ID (FR-012), чтобы ссылаться на него из дизайна и тестов (traceability).
Требование проверяемо: есть критерий приёмки, по которому понятно, выполнено или нет.
Приоритизация, например MoSCoW: Must / Should / Could / Won't. В system design сначала проектируют под Must.
Ключевые сценарии (5--10 штук) выделяются отдельно: на них потом проверяется вся архитектура (это «+1» в 4+1).

Пример:

FR-012. Пользователь может отменить заказ, пока тот не передан в доставку. Критерий: после отмены статус заказа CANCELLED, деньги возвращаются на исходный способ оплаты в течение 3 рабочих дней, пользователь получает уведомление.

Quality Attributes (NFR)¶

Нефункциональное требование (атрибут качества) -- насколько хорошо система делает то, что делает. Именно NFR, а не FR, сильнее всего определяют архитектуру: одни и те же функции можно реализовать монолитом на одной ВМ или распределённой системой в трёх регионах, и выбор между ними диктуют NFR.

Главное правило: NFR должно быть измеримым.

Плохо	Хорошо
Система должна быть быстрой	p99 latency API оформления заказа < 300 мс при 1 000 RPS
Высокая доступность	Availability 99.9% в месяц для API заказов (не более 43 минут простоя)
Данные не должны теряться	RPO = 0 для платежей, RPO ≤ 15 минут для каталога; RTO ≤ 1 час
Система должна быть безопасной	Доступ только по OIDC, ПДн шифруются at rest, аудит-лог всех изменений заказов

Основные атрибуты:

Атрибут	Чем измеряют
Performance	Latency (p50 / p95 / p99), throughput (RPS, сообщений в секунду)
Availability	Процент времени работы за период, SLO/SLA
Durability, DR	RPO -- сколько данных можно потерять, RTO -- за сколько восстановиться
Consistency	Strong или eventual; допустимое время расхождения реплик; какие операции атомарны
Scalability	До какой нагрузки и объёма данных система растёт без переписывания
Security	Модель аутентификации и авторизации, шифрование, аудит, модель угроз
Observability	Какие метрики, логи, трейсы обязательны; время обнаружения инцидента
Maintainability	Время вывода фичи, частота релизов, время онбординга разработчика
Compliance	Каким нормам соответствуем: 152-ФЗ, GDPR, PCI DSS, отраслевые стандарты
Cost	Бюджет на инфраструктуру в месяц, стоимость на пользователя или транзакцию

Сколько это -- «девятки» доступности:

Availability	Простой в год	Простой в месяц
99%	~3.65 дня	~7.3 часа
99.9%	~8.8 часа	~43.8 минуты
99.99%	~52.6 минуты	~4.4 минуты
99.999%	~5.3 минуты	~26 секунд

Каждая следующая девятка стоит заметно дороже: дублирование, несколько зон или регионов, автоматический failover, дежурства. Поэтому NFR задают для конкретных частей системы, а не одной цифрой на всё: платежам нужно 99.99% и RPO = 0, а отчётам хватит 99% и данных за вчера.

Quality Attribute Scenario (из метода ATAM, SEI) -- способ записать NFR так, чтобы его можно было проверить:

Элемент	Пример
Источник	Пользователи в пиковый час распродажи
Стимул	5 000 запросов в секунду на оформление заказа
Окружение	Штатный режим, одна зона доступности недоступна
Артефакт	Сервис заказов
Реакция	Заказы принимаются, ни один подтверждённый не потерян
Мера реакции	p99 < 500 мс, ошибок < 0.1%

NFR конфликтуют между собой: strong consistency против availability и latency (CAP, PACELC), безопасность против удобства, производительность против стоимости. Приоритеты между ними фиксируют явно -- это и есть входные данные для trade-off'ов на шаге 3.

Constraints¶

Ограничение -- решение, которое уже принято за архитектора и не обсуждается. В отличие от требования, его не выполняют, а учитывают.

Тип	Примеры
Бизнес	Бюджет, дедлайн, модель лицензирования, обязательные партнёры
Организационные	Размер и навыки команды, количество команд (закон Конвея), процессы компании
Технические	Стек компании, корпоративная платформа (облако, on-prem, Kubernetes), обязательные интеграции, legacy
Юридические	152-ФЗ (ПДн граждан РФ хранятся в РФ), GDPR, PCI DSS, требования ФСТЭК, импортозамещение

Ограничения часто сильнее всего сужают пространство решений. Пример: «команда -- 4 человека, срок -- 3 месяца» почти всегда означает модульный монолит, а не микросервисы, какими бы ни были остальные требования.

Capacity Estimation¶

Оценка нагрузки «на салфетке» (back-of-the-envelope). Нужна не точность, а порядок величины: 100 RPS, 10 000 RPS и 1 000 000 RPS -- это три разные архитектуры.

Что оценить:

Пользователи: DAU / MAU, одновременные сессии.
Запросы: среднее и пиковое RPS, отдельно чтение и запись (read/write ratio).
Данные: объём одной записи, сколько записей в день, рост за 1--5 лет, с учётом реплик и бэкапов.
Трафик: входящий и исходящий объём (особенно для медиа и файлов).
Горячие данные: что из этого часто читается и должно лежать в кэше.

Формулы:

1 сутки ≈ 86 400 с ≈ 10^5 с

RPS средний = DAU × запросов на пользователя в день / 86 400
RPS пиковый ≈ RPS средний × (2..10)       -- зависит от суточного профиля и событий
Объём в год = записей в день × размер записи × 365 × коэффициент репликации

Пример: сервис с 1 млн DAU, каждый делает 20 запросов в день, из них 10% -- запись, одна запись -- 1 КБ.

Запросов в сутки:  1 000 000 × 20 = 20 млн
RPS средний:       20 млн / 86 400 ≈ 230
RPS пиковый:       ≈ 230 × 5 ≈ 1 200
Из них запись:     ≈ 120 RPS в пике, остальное чтение -- read-heavy, имеет смысл кэш и read-реплики
Данные в сутки:    2 млн записей × 1 КБ = 2 ГБ
Данные в год:      2 ГБ × 365 × 3 реплики ≈ 2.2 ТБ

Вывод из такой оценки: одна PostgreSQL с репликами справится, шардирование пока не нужно, но через 3--5 лет объём стоит пересмотреть.

Результат шага¶

Список стейкхолдеров, цель системы, scope и out of scope, C4 Context Diagram.
FR с ID, приоритетами и критериями приёмки; выделенные ключевые сценарии.
NFR в измеримом виде, отдельно для критичных частей системы, с явными приоритетами между ними.
Список ограничений.
Оценка нагрузки и объёмов данных.
Всё это обычно собирается в SRS (Software Requirements Specification) или в набор страниц в wiki.

Куда требования идут дальше¶

Требование	Какие решения из System Design оно определяет
Context & Stakeholders, FR	Domain Classification, Strategic DDD, Communication & API Style
Constraints (команда, срок, стек)	Deployment / Topology, Infrastructure Platform
Capacity Estimation	Data Architecture, Scaling & Performance
NFR: Performance, Scalability	Scaling & Performance, Data Architecture
NFR: Consistency	Consistency & Transactions, Data Architecture
NFR: Availability, RPO/RTO	Fault-Tolerance & Resilience, Deployment / Topology
NFR: Security, Compliance	Security Architecture, Governance & Compliance
NFR: Observability	Observability
NFR: Maintainability	Micro-Arch (Code), Build & Delivery

Связь «требование → решение → тест» фиксируют в traceability matrix: для каждого FR и NFR видно, каким решением оно закрыто и каким тестом проверено.