AgentSkillsCN

requirements-analysis

以结构化的方式收集并细化需求，形成清晰明确的技术规格（TASK）。

SKILL.md
--- frontmatter
name: requirements-analysis
description: Процесс сбора и уточнения требований в структурированное ТЗ (TASK).
version: 1.3

Анализ Требований (Requirements Analysis)

1. Цикл Анализа

  1. •Разведка: Изучите структуру проекта, .AGENTS.md.
  2. •Идентификация: Каковы варианты использования (Use Cases)? Акторы? Предусловия?
  3. •Уточнение: Составьте список открытых вопросов. Лучше спросить сейчас, чем провалиться позже.

2. Структура Технического Задания (TASK)

Ваше ТЗ должно содержать следующие разделы:

0. Мета-информация

  • •Task ID: Извлеките из существующих задач (например, 002, если 001 существует) или используйте 001 для нового проекта.
  • •Slug: Короткое имя в kebab-case (например, user-auth).

1. Общее Описание

  • •Краткое описание задачи на основе общего заявления пользователя
  • •Цель разработки
  • •Связь с существующей системой (если применимо)

2. Список Вариантов Использования (Use Cases)

Создайте список Use Case'ов. Выделите, какие новые, а какие являются модификацией существующих.

Для каждого Use Case укажите:

2.1. Название Use Case

Короткое, понятное имя (например, "Регистрация Нового Пользователя")

2.2. Акторы

Кто участвует в этом сценарии:

  • •Пользователь (укажите роль, если важно)
  • •Система
  • •Внешние системы (если есть)

2.3. Предусловия

Что должно быть выполнено перед началом сценария

2.4. Основной Сценарий

Пошаговое описание успешного выполнения. При обновлении существующего Use Case укажите, какие шаги существуют, какие добавлены, изменены или удалены:

  1. •Актор выполняет действие X
  2. •Система отвечает Y
  3. •...

2.5. Альтернативные Сценарии

Описание отклонений от основного сценария:

  • •Альтернатива 1: Что происходит, если...
    1. •Шаг
    2. •Шаг
  • •Альтернатива 2: ...

2.6. Постусловия

Что должно быть достигнуто после успешного выполнения

2.7. Критерии Приемки

Конкретные, проверяемые критерии:

  • •✅ Критерий 1
  • •✅ Критерий 2
  • •✅ Критерий 3

3. Нефункциональные Требования (если применимо)

  • •Производительность
  • •Безопасность
  • •Масштабируемость
  • •Совместимость

4. Ограничения и Допущения

  • •Технические ограничения
  • •Бизнес-ограничения
  • •Допущения, сделанные при создании ТЗ

5. Открытые Вопросы

Список вопросов, требующих уточнения у пользователя

3. Важные Правила

✅ ДЕЛАТЬ:

  1. •Быть детальным: Описывайте каждый шаг в сценариях.
  2. •Думать о граничных случаях: Учитывайте ошибки, исключения, граничные условия.
  3. •Задавать вопросы: Если что-то неясно — добавляйте в "Открытые Вопросы".
  4. •Использовать существующую терминологию: Используйте термины из документации проекта.
  5. •Ссылаться на существующий функционал: Явно указывайте, как новый функционал взаимодействует с существующим.

❌ НЕ ДЕЛАТЬ:

  1. •НЕ писать код: Вы создаете ТЗ, а не реализацию.
  2. •НЕ проектировать архитектуру: Это задача Архитектора.
  3. •НЕ выдумывать: Если неясно, задайте вопрос.
  4. •НЕ делать скрытых предположений: Явно указывайте, где вы делаете допущение.
  5. •НЕ усложнять: Будьте проще, не занимайтесь overengineering'ом.
  6. •НЕ игнорировать существующий функционал: Изучите проект перед написанием ТЗ.
  7. •НЕ оставлять важные решения на потом: Все ключевые решения должны быть выбраны или запрошено уточнение у пользователя.

🔴 КРИТИЧНО: Управление Неопределенностью

Вы находитесь на самой ранней стадии разработки. Нерешенная неопределенность сейчас может привести к провалу проекта. Поэтому:

  1. •Уделяйте максимум внимания неясным моментам
  2. •Не стесняйтесь задавать много вопросов
  3. •Лучше задать "глупый" вопрос, чем сделать неверное предположение
  4. •Если сомневаетесь — добавляйте в "Открытые Вопросы"