Сбор требований

Цели урока

• Понимать, почему сбор требований - первый шаг в System Design
• Различать functional и non-functional requirements
• Владеть ключевыми NFR: availability, latency, consistency
• Определять масштаб системы по DAU, QPS, Read/Write ratio
• Использовать структурированный чеклист для сбора требований

Предварительные знания

• Введение в System Design (предыдущий урок)
• Базовое понимание клиент-серверной архитектуры

Knight Capital Group потеряла 440 млн долларов за 45 минут из-за deployment без четких требований к процессу. Amazon посчитал: каждые 100 мс задержки стоят 1% выручки. Требования - это не бюрократия. Это деньги.

• **FAANG-интервью**: правильные вопросы в первые 5 минут отделяют senior от junior
• **Amazon**: внутренний стандарт - каждый новый сервис начинается с PR/FAQ документа с требованиями
• **Google**: Design docs с NFR - обязательный этап перед любым крупным проектом
• **Netflix**: архитектура стриминга проектировалась под 50M+ concurrent users с первого дня

Как появился requirements engineering

На конференции NATO 1968 года в Гармише инженеры впервые формализовали понятие software crisis - проекты срывались из-за отсутствия чётких требований. Фред Брукс в «Мифическом человеко-месяце» (1975) показал: ошибки в требованиях обходятся в 100 раз дороже на этапе продакшена, чем при проектировании. Современный requirements engineering в SD-интервью - прямой наследник этих идей.

Почему требования - это первый шаг?

Knight Capital Group, 2012. Алготрейдинговая система запустила неверный код - 45 минут работы, убыток 440 млн долларов. Корень проблемы: требования к deployment process не были formalized. System design без чётких требований - это код без тестов. Кажется быстрее, но только до первого продакшена.

Типичная ошибка: сразу бросаться рисовать диаграммы. Сначала нужно понять ЧТО проектировать, и только потом КАК.

Требования определяют архитектуру. Twitter для 1000 пользователей и Twitter для 500 миллионов - это **совершенно разные системы**.

**Вопросы показывают опыт**

Senior-инженер видел разные проекты и знает, какие вопросы задавать. Интервьюер оценивает не только финальную архитектуру, но и процесс её создания.

Если интервьюер отвечает «свободный выбор» - это не отмашка. Он хочет услышать рассуждения: «Допустим масштаб X, тогда архитектура будет Y. Если масштаб Z - то W».

Функциональные требования

Netflix, 2007. Reed Hastings поставил задачу инженерам: «Спроектируйте систему стриминга». Первый вопрос команды был правильным: «Для скольких устройств одновременно? Только браузер или Smart TV, мобильный?». Это и есть работа с functional requirements - определить scope до того, как начнётся проектирование.

**Функциональные требования** описывают **ЧТО система должна делать**. Конкретные features и use cases. Задача - определить **scope** интервью. Невозможно спроектировать весь Twitter за 45 минут.

**Пример диалога:**

**Ключевые вопросы для functional requirements:**

1. Какие **основные use cases**? Что пользователь делает чаще всего?
2. Какие **операции** нужны? Create, Read, Update, Delete?
3. Нужна ли **real-time** функциональность? (чат, notifications)
4. Нужен ли **поиск**? По каким полям?
5. Нужна ли **аналитика**? Какая детализация?
6. Есть ли **интеграции** с внешними системами?

Non-Functional Requirements

Amazon, 2006. Инженеры посчитали: каждые 100 мс задержки стоят 1% выручки. Это и есть NFR в денежном выражении. **Non-Functional Requirements (NFR)** описывают **КАК система должна работать**: performance, reliability, scalability. NFR определяют архитектуру не меньше, чем features.

Система с 99.99% availability требует принципиально другого подхода, чем система с 99%.

**Availability: девятки**

Availability измеряется в «девятках». Каждая дополнительная девятка стоит значительно дороже.

**Latency: p50 vs p99**

p50 (median) - время, за которое выполняется 50% запросов. p99 - 99% запросов. p99 представляет worst case и часто важнее.

**Consistency: strong vs eventual**

Вопрос: «Какие данные требуют strong consistency?». Часто можно использовать eventual consistency для большинства данных и strong только для критичных.

Определение масштаба

WhatsApp, 2014. Компанию купили за 19 млрд долларов - 450 млн пользователей, 32 инженера. Секрет: архитектура была спроектирована под масштаб с первого дня. **Масштаб определяет архитектуру**. Перед проектированием нужно понять: сколько пользователей? сколько данных? какая нагрузка?

Ключевые метрики масштаба:

**Референсные цифры:**

**Read-heavy vs Write-heavy**

Соотношение чтение/запись критично для архитектуры. Read-heavy системы используют aggressive caching. Write-heavy системы фокусируются на write throughput.

Чеклист сбора требований

Этот чеклист - инструмент для первых 5-10 минут интервью. Не нужно задавать каждый вопрос - выбирать релевантные для конкретной задачи.

**Пример полной сессии сбора требований (5 минут):**

Ключевые требования нужно записать на доску/в заметки. К ним придётся возвращаться: «Помним, что договорились на 99.9% availability - вот как это достигается...»

Ключевые выводы

• Requirements gathering: Functional (что делает) + Non-functional (как работает)
• Ключевые NFR: availability (девятки), latency (p50, p99), consistency (strong vs eventual)
• Масштаб определяет архитектуру: DAU, QPS, Read/Write ratio
• Использовать чеклист и фиксировать предположения

Следующий шаг

Следующий урок: Load Estimation (back-of-envelope вычисления) - как превратить требования в конкретные числа: QPS, storage, bandwidth, количество серверов.

• system-design — related to

Вопросы для размышления

• Тебе говорят: «Сделай систему уведомлений, чтобы всё работало быстро». Какие уточняющие вопросы ты задашь первыми - и почему именно они?

Связанные уроки

• sd-01-intro — Введение в system design формирует контекст для работы с требованиями
• sd-03-scalability — Load estimation строится поверх требований по scale
• sd-04-database — High-level design невозможен без чёткого scope
• devops-01 — SLA и availability nines на практике - в devops контексте
• ds-02-cap-theorem — CAP-теорема - прямое следствие NFR-выбора consistency vs availability
• se-01 — Software engineering требования - более формальная версия того же процесса
• db-01-intro