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

← [Раздел](README.md) · [Главная](../README.md)

## Цель

Научиться переводить **бизнес-задачу** в структурированные **функциональные требования**, user stories и ограничения — основу для архитектурных решений.

## Предварительно

- [Оглавление раздела 03](README.md)

## Время

**4–5 часов**

---

## От идеи к требованиям

**Идея:** «Семьи ведут общий список покупок».  
**Требование:** проверяемое утверждение о поведении системы.

Без требований архитектор рисует «красивую схему», не решающую проблему заказчика.

---

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

Описывают **что** система делает.

| ID | Формулировка | Критерий приёмки |
|----|--------------|------------------|
| FR-1 | Пользователь регистрируется по email | Письмо с подтверждением за 5 мин |
| FR-2 | Создаёт список с названием | Список виден в «Мои списки» |
| FR-3 | Добавляет пункт с текстом | Пункт появляется < 2 с на втором устройстве |
| FR-4 | Приглашает по ссылке | Гость с правом edit видит список |
| FR-5 | Отмечает пункт выполненным | Состояние синхронизируется |

Шаблон: **«Актор + действие + объект + условие»**.

---

## User stories (формат Agile)

```
Как <роль>, я хочу <действие>, чтобы <ценность>.
```

Пример:

> Как родитель, я хочу поделиться списком по ссылке, чтобы супруг видел покупки без установки отдельного аккаунта (гостевой доступ).

**Acceptance criteria** (чеклист для QA):

- [ ] Ссылка одноразовая / с TTL 7 дней (уточнить с заказчиком)  
- [ ] Отзыв доступа отключает просмотр за 1 мин  

---

## Нефункциональные требования (NFR)

См. отдельно [NFR и SLA](nfr-i-sla.md). На этапе сбора **задайте вопросы сразу**:

| Вопрос заказчику | Влияние на архитектуру |
|------------------|------------------------|
| Сколько пользователей через год? | Реплики, шардинг |
| Допустим простой ночью? | Окна maintenance |
| Персональные данные EU? | Регион DC, GDPR |
| Нужен офлайн? | Sync на клиенте, CRDT |

---

## Stakeholders и роли

```mermaid
flowchart TB
  PO[Владелец продукта] --> Req[Требования]
  Users[Пользователи] --> Req
  Legal[Юристы] --> Constraints[Ограничения]
  Security[Security] --> Constraints
  Req --> Arch[Архитектор]
  Constraints --> Arch
```

| Stakeholder | Что важно |
|-------------|-----------|
| Пользователь | Скорость, простота |
| Бизнес | Срок, бюджет |
| Compliance | Хранение данных, аудит |
| Операции | Дежурства, runbooks |

---

## Ограничения (constraints)

| Тип | Пример |
|-----|--------|
| Технические | «Только PostgreSQL в компании» |
| Бюджет | «Не больше $500/мес на инфру» |
| Срок | «MVP за 8 недель» |
| Регуляторные | «152-ФЗ, данные в РФ» |
| Интеграции | «Вход через корпоративный SSO» |

Ограничения **сужают** пространство решений — это нормально.

---

## Use case (краткий сценарий)

**UC-3: Добавить пункт**

1. Пользователь авторизован  
2. Открыт список L  
3. Вводит «хлеб», нажимает «Добавить»  
4. Система валидирует длину ≤ 200 символов  
5. Сохраняет, возвращает 201  
6. **Альтернатива 4a:** не авторизован → 401  

Use cases хороши для **потоков**; user stories — для **бэклога**.

---

## MoSCoW приоритизация

| Метка | Значение |
|-------|----------|
| **Must** | Без этого нет MVP |
| **Should** | Важно, но после MVP |
| **Could** | Приятно иметь |
| **Won't** | Сознательно не делаем сейчас |

Пример Won't: «Голосовой ввод» в v1 — фиксируем, чтобы не расползся scope.

---

## Трассируемость

Каждое FR должно **отразиться** на C4 и в тестах:

| FR | Container | Тест |
|----|-----------|------|
| FR-3 | API + DB | integration POST /items |
| FR-4 | API + Sharing + Email queue | e2e invite flow |

---

## Типичные ошибки сбора

| Ошибка | Как избежать |
|--------|--------------|
| Решение вместо требования | «Нужен Kubernetes» → «Нужна отказоустойчивость 99.9%» |
| Размытые слова | «Быстро» → «p95 < 300 ms» |
| Нет владельца решения | Product sign-off на scope |
| Игнор edge cases | Удаление аккаунта, GDPR export |

---

## Практика

1. Напишите 5 FR и 3 user stories для учебного кейса.  
2. Проведите mock-интервью: 10 вопросов заказчику про нагрузку и данные.  
3. Составьте MoSCoW для MVP из 8 фич.

---

## Самопроверка

1. Чем use case отличается от user story?  
2. Приведите пример технического ограничения, не FR.  
3. Зачем критерии приёмки?

---

## Дальше

→ [NFR и SLA](nfr-i-sla.md)