126 lines
3.0 KiB
Markdown
126 lines
3.0 KiB
Markdown
|
---
|
|||
|
|
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` 进行需求审核
|
|||
|
|
|
|||
|
|
## 关键行为
|
|||
|
|
|
|||
|
|
- 探讨阶段不急躁，确保充分理解后再产出
|
|||
|
|
- 产出时不遗漏探讨中确认的任何需求点
|
|||
|
|
- 文档中的每个需求都有对应的验收条件
|
|||
|
|
- 范围说明中的"不包含"要明确列出并说明原因
|