Requirements Analyst
将模糊需求转换为清晰、可执行的需求文档。
如何使用
触发方式
直接向 Claude 描述你的需求，例如：
我需要一个用户登录功能
帮我分析这个需求：用户可以在平台上发布和浏览商品
写一份用户系统的 PRD
使用流程
- 描述需求 - 用自然语言描述你想要的功能（可以模糊、不完整）
- 选择格式 - 助手会询问输出格式（用户故事 / PRD）
- 回答问题 - 助手会提出澄清问题，选择或输入你的答案
- 获取文档 - 助手输出结构化的需求文档
- 确认调整 - 根据需要要求修改或补充
示例对话
用户输入：
我需要一个购物车功能
助手响应：
- 识别缺失信息（用户类型、功能范围、边界条件）
- 提出澄清问题：
- 购物车是否支持游客使用？
- MVP 需要哪些功能？（增删商品/保存/优惠券）
- 有商品数量上限吗？
- 根据回答生成用户故事：
## User Story: 添加商品到购物车
**As a** 网站访客或注册用户
**I want** 将商品添加到购物车
**So that** 我可以继续浏览并稍后一起结账
### Acceptance Criteria
- [ ] Given 用户在商品详情页，when 点击"加入购物车"，then 商品被添加且显示成功提示
- [ ] Given 购物车已有该商品，when 再次添加，then 数量增加而非重复添加
分析工作流程
Phase 1: 理解阶段
- 接收需求 - 读取用户提供的原始需求文本
- 识别关键要素:
- 用户角色 (Who) - 明确或隐含的用户类型
- 期望结果 (What) - 用户想要实现什么
- 业务价值 (Why) - 为什么需要这个功能
- 约束条件 - 技术、时间、资源限制
- 标记模糊点 - 识别需要澄清的部分
Phase 2: 澄清阶段
使用 AskUserQuestion 解决模糊点。按优先级提问：
- 关键未知 - 没有这个信息无法编写故事
- 范围澄清 - 边界条件和边缘情况
- 验收细节 - 如何验证功能完成
提问原则：
- 批量提问 (3-5 个问题一组)
- 提供选项而非开放式问题
- 说明如果不回答会采用的默认假设
Phase 3: 生成阶段
根据选择的输出格式生成文档：
- 用户故事: 按照 USER_STORY_TEMPLATE.md 生成
- PRD: 按照 PRD_TEMPLATE.md 生成
Phase 4: 确认阶段
- 使用 INVEST 检查清单验证故事完整性
- 如果故事过大，提供拆分选项
- 与用户确认并接受反馈
快速开始
典型需求分析流程：
- 用户提供模糊需求
- 助手识别缺失信息，提出澄清问题
- 用户回答问题
- 助手生成格式化用户故事和验收标准
输出格式
用户故事格式
## User Story: [简短标题]
**As a** [用户类型/角色]
**I want** [功能/能力]
**So that** [价值/收益]
### Acceptance Criteria
- [ ] Given [上下文], when [操作], then [预期结果]
- [ ] Given [上下文], when [操作], then [预期结果]
### Notes
- [假设说明]
- [识别的依赖]
- [排除范围]
PRD 格式
# [产品/功能名称] PRD
## 1. 概述
### 1.1 背景
[为什么要做这个功能]
### 1.2 目标
[业务目标和用户目标]
### 1.3 成功指标
[如何衡量成功]
## 2. 用户分析
### 2.1 目标用户
[用户画像]
### 2.2 用户痛点
[当前问题]
### 2.3 用户场景
[典型使用场景]
## 3. 功能需求
### 3.1 功能列表
[功能清单和优先级]
### 3.2 功能详情
[每个功能的详细说明]
### 3.3 用户故事
[对应的用户故事]
## 4. 非功能需求
[性能/安全/兼容性要求]
## 5. 数据需求
[数据模型和流转]
## 6. 开放问题
[待决策事项]
参考资料
用户故事模板
何时加载: 生成用户故事时
- 标准用户故事格式
- INVEST 检查清单
- 故事拆分策略
PRD 模板
何时加载: 生成 PRD 文档时
参见 PRD_TEMPLATE.md:
- 完整 PRD 结构
- 各部分编写指南
- PRD vs 用户故事对比
验收标准指南
何时加载: 编写验收标准时
- Given-When-Then 格式
- 不同类型验收标准示例
- 编写原则
提问策略
何时加载: 需要向用户提问时
参见 CLARIFICATION_QUESTIONS.md:
- 何时提问 vs 何时假设
- 按类别分类的问题库
- 问题模板