---
name: dev-requirement
description: 开发流程 - 需求分析阶段，通过探讨和澄清循环产出需求文档
---

# 需求分析

> 开发流程第一阶段：通过探讨 → 产出 → 澄清循环，产出满意的需求文档。

## 调用方式

`/dev-requirement` 或 `/dev-req`，也可说"开始需求分析"。

支持传入需求来源：`/dev-requirement docs/idea.md` 或 `/dev-requirement Issue#42`。

## 产出目录

`docs/requirements/`

## 执行流程

### Checklist

- [ ] 探索项目上下文
- [ ] 收集原始需求
- [ ] 探讨循环（澄清问题）
- [ ] 产出需求文档
- [ ] 用户确认并保存

### 1. 探索项目上下文

启动后首先了解当前项目状态：

- 读取项目根目录的文件结构
- 查看现有文档（README、CLAUDE.md 等）
- 查看最近的 git 提交（如有）
- 查看是否已有 `docs/requirements/` 目录下的需求文档

### 2. 收集原始需求

根据用户输入获取需求来源：

- 如果传入文件路径，读取该文件作为原始需求
- 如果传入 Issue 编号，尝试读取 Issue 内容
- 如果无参数，询问用户描述需求

### 3. 探讨循环

参考 superpowers:brainstorming 的核心模式：

**规则：**
- 一次只问一个澄清问题
- 优先使用多选选项向用户提问
- 提出 2-3 个方案供选择时，说明权衡和推荐
- YAGNI 原则：主动去掉不必要的需求
- 不要自作主张添加用户没提到的需求

**探讨内容：**
- 业务背景和目标
- 用户角色和使用场景
- 核心功能需求
- 非功能需求（性能、安全等）
- 约束和假设
- 范围边界（包含/不包含）

**退出条件：** 你已充分理解以下内容：
- 为什么做这个项目
- 谁是目标用户
- 核心功能有哪些
- 成功标准是什么

### 4. 产出需求文档

按以下模板生成需求文档，分段展示给用户审阅：

```markdown
# 需求文档：<项目名称>

> 创建日期：YYYY-MM-DD
> 状态：已确认

## 1. 背景与目标
### 业务背景
### 核心目标
### 成功指标

## 2. 功能需求
（每个需求用用户故事格式）
### 用户故事 N
**作为** [角色]，**我想要** [功能]，**以便** [价值]
验收条件：
- [ ] 条件 1

## 3. 非功能需求
- 性能：
- 安全：
- 兼容性：
- 可维护性：

## 4. 约束与假设
### 技术约束
### 业务假设

## 5. 范围说明
### 包含
### 不包含
```

**审阅规则：**
- 每展示一段后询问是否满意
- 收集反馈后修改，进入下一轮展示
- 循环直到用户确认整体满意

### 5. 保存文档

- 确保 `docs/requirements/` 目录存在
- 保存为 `docs/requirements/YYYY-MM-DD-<项目名>.md`
- 告知用户文件位置，提示下一步可调用 `/dev-review` 进行需求审核

## 关键行为

- 探讨阶段不急躁，确保充分理解后再产出
- 产出时不遗漏探讨中确认的任何需求点
- 文档中的每个需求都有对应的验收条件
- 范围说明中的"不包含"要明确列出并说明原因