requirementslisted

# Сбор требований в спецификацию Превращает размытые бизнес-требования в письменную спеку до кода. Порядок жесткий: сначала понять и уточнить, только потом писать. ## Шаг 1: Собрать вход - Если требования уже лежат в проекте (например `docs/requirements/business-requirements.md` или тикет) - прочитай их. - Если содержательных требований нет - попроси пользователя описать, что нужно и зачем. Не начинай писать спеку с пустого места. ## Шаг 2: Уточнить ПЕРЕД тем как писать - Составь список вопросов, неясностей и неявных требований. - Выяви допущения и назови их явно. - Отметь противоречия в требованиях и edge cases. - **Задай вопросы и дождись ответов.** Не додумывай бизнес-логику - спрашивай. ## Шаг 3: Зафиксировать требования Если требования пришли из ответов пользователя (а не лежали готовыми в файле) - сохрани их в `docs/requirements/business-requirements.md`: исходное описание, уточнения, ключевые ограничения. Спека без зафиксированного источника висит в воздухе; не переходи к ТЗ, пока источник не записан. ## Шаг 4: Написать спецификацию Масштабируй формальность под задачу: маленькая фича - короткая спека; полноценный greenfield - развернутая. Не раздувай разделы, которые проект не требует. `docs/requirements/technical-spec.md` - по мере применимости: - Цель, аудитория, границы (что входит / что НЕ входит). - Глоссарий терминов - если есть неоднозначные. - Функциональные требования: ID (FR-001), описание, приоритет (MoSCoW: Must / Should / Could / Won't), бизнес-