Requirements Analyst

将模糊需求转换为清晰、可执行的需求文档。

如何使用

触发方式

直接向 Claude 描述你的需求，例如：

code

我需要一个用户登录功能

code

帮我分析这个需求：用户可以在平台上发布和浏览商品

code

写一份用户系统的 PRD

使用流程

•描述需求 - 用自然语言描述你想要的功能（可以模糊、不完整）
•选择格式 - 助手会询问输出格式（用户故事 / PRD）
•回答问题 - 助手会提出澄清问题，选择或输入你的答案
•获取文档 - 助手输出结构化的需求文档
•确认调整 - 根据需要要求修改或补充

示例对话

用户输入：

我需要一个购物车功能

助手响应：

•识别缺失信息（用户类型、功能范围、边界条件）
•
提出澄清问题：
- •购物车是否支持游客使用？
- •MVP 需要哪些功能？（增删商品/保存/优惠券）
- •有商品数量上限吗？
•根据回答生成用户故事：

markdown

## 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 检查清单验证故事完整性
•如果故事过大，提供拆分选项
•与用户确认并接受反馈

快速开始

典型需求分析流程：

•用户提供模糊需求
•助手识别缺失信息，提出澄清问题
•用户回答问题
•助手生成格式化用户故事和验收标准

输出格式

用户故事格式

markdown

## User Story: [简短标题]

**As a** [用户类型/角色]
**I want** [功能/能力]
**So that** [价值/收益]

### Acceptance Criteria
- [ ] Given [上下文], when [操作], then [预期结果]
- [ ] Given [上下文], when [操作], then [预期结果]

### Notes
- [假设说明]
- [识别的依赖]
- [排除范围]

PRD 格式

markdown

# [产品/功能名称] 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. 开放问题
[待决策事项]