Files

T

2026-04-27 17:45:20 +08:00

3.0 KiB

Raw Blame History

name, description

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

需求分析

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

调用方式

/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. 产出需求文档

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

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

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

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

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

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

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

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

审阅规则：

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

5. 保存文档

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

关键行为

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

3.0 KiB Raw Blame History Unescape Escape