Requirements: спецификация требований

Цель

Превратить MVP Scope в формальную спецификацию требований с чёткими функциональными и нефункциональными требованиями, ограничениями и зависимостями между ними через структурированный диалог.

Входные данные

Перед началом прочитай docs/PROJECT_BRIEF.md и docs/MVP_SCOPE.md. Если какой-то файл не найден — сообщи пользователю и предложи сначала создать недостающий документ.

Процесс

Фаза 1: Валидация понимания

Кратко перескажи ключевые сценарии из MVP Scope (3-5 предложений) и спроси:

1. •"Я правильно понимаю приоритеты? Что-то изменилось с момента написания MVP Scope?"

Фаза 2: Функциональные требования по сценариям

Для каждого сценария из MVP Scope задавай ПО ОДНОМУ вопросу. Жди ответа перед следующим.

1. •"Берём сценарий [название]. Какие данные система получает на входе? Что отдаёт на выходе?"
2. •"Какие валидации и проверки нужны? Что считается ошибкой и как система должна реагировать?"
3. •"Есть ли бизнес-правила, которые ограничивают поведение? Например: лимиты, права доступа, обязательные поля?"
4. •"Нужно ли сохранять историю действий или состояний? Что именно и как долго?"

Повтори вопросы 2-5 для каждого критичного сценария. Предлагай свои варианты требований на основе типичных практик, если пользователь затрудняется.

Фаза 3: Нефункциональные требования

1. •"Какое время отклика приемлемо для основных операций? Например: открытие страницы, отправка сообщения агенту, загрузка дашборда?"
2. •"Сколько пользователей или параллельных операций система должна выдерживать в MVP?"
3. •"Есть ли требования к безопасности и авторизации? Кто может видеть и делать что?"
4. •"Какие данные критичны и не должны теряться? Нужны ли бэкапы в MVP?"

Фаза 4: Граничные случаи

1. •"Что происходит, если [внешний сервис] недоступен? Как система должна себя вести?"
2. •"Что если пользователь делает что-то неожиданное — закрывает вкладку посреди процесса, отправляет пустую форму, открывает один проект в двух вкладках?"

Фаза 5: Зависимости между требованиями

1. •"Какие требования блокируют друг друга? Что нужно реализовать первым, чтобы остальное стало возможным?"

Фаза 6: Формирование документа

Когда все ответы собраны — представь Requirements блоками по 200-300 слов. После каждого блока спрашивай: "Эта часть выглядит верно?" Будь готов вернуться и уточнить, если что-то не сходится.

Результат

После валидации всех блоков создай файл docs/REQUIREMENTS.md:

# Requirements: [Название проекта]

## Обзор

[Краткое описание scope требований и связь с MVP Scope. 2-3 предложения]

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

### FR-1: [Название функциональной области]

**Связанный сценарий:** [Ссылка на сценарий из MVP Scope]

| ID | Требование | Приоритет |
|---|---|---|
| FR-1.1 | [Система должна...] | Must / Should / Could |
| FR-1.2 | [Система должна...] | Must / Should / Could |

### FR-N: [Название функциональной области]

[Аналогичная структура]

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

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

| ID | Требование | Метрика |
|---|---|---|
| NFR-1 | [Описание] | [Конкретное значение] |

### Безопасность

| ID | Требование | Метрика |
|---|---|---|
| NFR-N | [Описание] | [Конкретное значение] |

### Надёжность

| ID | Требование | Метрика |
|---|---|---|
| NFR-N | [Описание] | [Конкретное значение] |

## Ограничения и допущения

**Ограничения:**
- [Технические, бизнесовые или организационные ограничения]

**Допущения:**
- [Что считаем истинным без проверки]

## Зависимости между требованиями

[Какие требования блокируют другие. Рекомендуемый порядок реализации]

## Глоссарий

| Термин | Определение |
|---|---|
| [Термин] | [Что он значит в контексте проекта] |

Ключевые принципы

• •Один вопрос за раз — не перегружай собеседника множеством вопросов
• •Варианты ответов предпочтительнее — предлагай 2-3 варианта, на них проще отвечать
• •«Система должна» — формат требований — каждое требование формулируется как утверждение о поведении системы
• •Проверяемость — каждое требование должно быть проверяемым: с конкретной метрикой или критерием
• •Челлендж неявных требований — "быстро работать" → "время отклика < 500мс на 95 перцентиле"
• •Не изобретай требований — вытягивай требования из сценариев MVP Scope, а не придумывай новые
• •Инкрементальная валидация — представляй документ блоками, проверяй каждый
• •Будь гибким — возвращайся и уточняй ранние решения, если что-то не сходится