Agile Requirement Analyzer

---
name: agile-requirement-analyzer
description: 从客户原始需求到验收标准的完整敏捷需求分析工作流。适用于需要进行需求澄清、Epic分解、用户故事生成、INVEST评估和验收标准编写的场景。支持Epic/Feature/Story三个层次的需求分析，包含自动质量检查和优化决策机制。Use when analyzing customer requirements, breaking down Epics into user stories, evaluating story quality with INVEST principles, or generating acceptance criteria for agile development.
---

# 敏捷需求分析器 (Agile Requirement Analyzer)

## 概述

这个技能提供从客户原始需求到可执行验收标准的完整敏捷需求分析工作流，确保需求质量和可追溯性。

**核心价值**:
- 🎯 **系统化**: 6步结构化工作流，避免遗漏关键需求
- 🔄 **自适应**: 根据需求层次（Epic/Feature/Story）自动选择合适的流程
- ✅ **质量保障**: 内置INVEST评估和质量门，确保输出质量
- 🤖 **智能决策**: 支持自动/人工两种优化决策模式
- 📚 **学习记忆**: 记录用户偏好，提高后续分析效率

---

## 快速开始

### 最简使用

直接提供原始需求即可：

```
请分析以下需求：

【需求描述】
我们需要开发一个智能客服系统，支持多渠道接入、智能问答、工单管理...
```

Skill会自动：
1. 识别需求层次（Epic/Feature/Story）
2. 选择合适的分析流程
3. 逐步引导完成需求分析
4. 输出标准化的分析文档

### 快速命令

- `分析需求：[粘贴需求]` - 启动完整分析流程
- `继续分析：[续传码]` - 断点续传（从上次中断处继续）
- `优化用户故事：US001,US003` - 优化指定故事
- `查看偏好设置` - 显示已记录的用户偏好

---

## 工作流决策树

```
📥 接收原始需求
    ↓
🔍 步骤1: 需求澄清（识别P0/P1/P2问题）
    ↓
📊 步骤2: 需求层次判断
    ↓
    ├─→ Epic级别 (涉及多角色/多阶段)
    │       ↓
    │   🎯 步骤3: Epic分析
    │       - 用户角色识别
    │       - 拆解策略制定
    │       - 风险识别
    │       ↓
    │   📝 步骤4: 用户故事生成
    │       - 生成15-30个用户故事
    │       - 功能要点提炼
    │       - 粒度控制
    │       ↓
    │   ✅ 步骤5: INVEST评估
    │       - 六维度评估打分
    │       - 问题识别和改进建议
    │       - MoSCoW优先级排序
    │       ↓
    │   🤔 步骤6: 优化决策（人机交互点）
    │       - 自动模式：根据评分自动决策
    │       - 人工模式：询问用户意见
    │       ├─ 需要优化 → 返回步骤4
    │       └─ 不需要优化 → 进入步骤7
    │       ↓
    │   📋 步骤7: 生成验收标准
    │       - Given-When-Then场景
    │       - 测试用例
    │       - 质量标准
    │
    ├─→ Feature级别 (单一角色/单一场景)
    │       ↓
    │   📝 简化用户故事生成（3-8个）
    │       ↓
    │   📋 生成验收标准
    │
    └─→ Story级别 (单一用户故事)
            ↓
        📋 直接生成验收标准
```

---

## 分步指南

### 步骤1: 需求澄清

**目标**: 识别模糊点、遗漏点和风险点，生成结构化澄清问题清单。

**执行方式**: 
```markdown
我将读取 references/01-requirement-clarification.md 执行需求澄清。
```

**输出内容**:
- 需求层次分析（Epic/Feature/Story判断，含置信度）
- 6大维度澄清问题（功能/非功能/合规/技术/管理/遗漏）
- P0/P1/P2问题分级
- 风险预警
- 下一步行动建议

**检查点**:
```markdown
✅ 需求澄清完成

已识别: [N]个澄清问题
- 🔴 P0（必须立即澄清）: [n]个
- 🟡 P1（应该尽快澄清）: [n]个
- 🟢 P2（可以后续澄清）: [n]个

**需求层次**: [Epic/Feature/Story] (置信度: [X]%)

**下一步**: 
- Epic级别 → 进入Epic分析（步骤3）
- Feature级别 → 简化流程（跳到简化版用户故事生成）
- Story级别 → 快速流程（跳到验收标准生成）
```

**特别说明**: 
- 如果有≥3个P0问题，建议先澄清后再继续
- 支持"基于假设继续"模式（标注假设，风险较高）

---

### 步骤2: 需求层次判断标准

**判断标准表格**:

| 维度 | Epic | Feature | Story |
|------|------|---------|-------|
| **用户群体** | 多个角色 | 单一角色 | 单一角色 |
| **业务阶段** | 跨越多个阶段 | 单一业务场景 | 单一操作 |
| **可拆分性** | 需拆分为≥3个Feature | 需拆分为≥3个Story | 1-2周内完成 |
| **交付价值** | 完整业务能力 | 独立功能模块 | 单一用户故事 |
| **预估工时** | ≥3个月 | 1-3个月 | 1-2周 |

**置信度评估**:
- High (≥80%): 明确符合某一层次的所有特征
- Medium (60-79%): 符合大部分特征，但有模糊地带
- Low (<60%): 特征不明显，需要更多信息

**如果置信度<80%**: 询问用户确认判断结果。

---

### 步骤3: Epic分析

**适用条件**: 步骤2判断为Epic级别。

**执行方式**: 
```markdown
我将读取 references/02-epic-analysis.md 执行Epic分析。
```

**输出内容**:
- Epic概述（业务价值、核心目标、成功标准、复杂度评估）
- 用户角色分析（核心/重要/次要角色，核心诉求和场景）
- 拆解策略（拆解维度、拆解框架、预估故事数）
- 依赖与风险（技术/业务/外部依赖，风险矩阵）

**检查点**:
```markdown
✅ Epic分析完成

**核心信息**:
- 识别角色: [n]个（核心[n]个，重要[n]个，次要[n]个）
- 拆解维度: [按角色/按功能/按场景/混合]
- 预估故事数: [N]个
- 建议迭代数: [N]个

**下一步**: 进入用户故事生成（步骤4）
```

---

### 步骤4: 用户故事生成

**适用条件**: 
- Epic级别：基于步骤3的Epic分析结果
- Feature级别：简化版（3-8个故事）

**执行方式**: 
```markdown
我将读取 references/03-user-story-generation.md 执行用户故事生成。
```

**输出内容**:
- 用户故事总览表（ID/标题/角色/分组/粒度）
- 详细故事列表（按功能分组）
  - 标准格式：作为...我希望...以便...
  - 功能要点、业务规则、界面要求
  - 粒度评估（S/M/L）

**质量自检**（在输出前）:
- [ ] 所有故事都遵循标准格式？
- [ ] 所有故事都有明确的用户价值？
- [ ] 故事数量合理（Epic:15-30，Feature:3-8）？
- [ ] 粒度分布合理（避免过多L级故事）？

**检查点**:
```markdown
✅ 用户故事生成完成

**统计信息**:
- 故事总数: [N]个
- 角色分布: [角色1]([n]个), [角色2]([n]个)...
- 粒度分布: S([n]个), M([n]个), L([n]个)

**质量预检**: [通过/有问题]
- 如发现≥3个L级故事，建议拆分

**下一步**: 进入INVEST评估（步骤5）
```

---

### 步骤5: INVEST评估

**适用条件**: Epic或Feature级别的用户故事。

**执行方式**: 
```markdown
我将读取 references/04-invest-evaluation.md 执行INVEST评估。
```

**输出内容**:
- INVEST评估总览表（六维度评分✅⚠️❌，综合分，状态）
- 问题故事详细分析（问题描述、改进建议、改进后示例）
- MoSCoW优先级分类（Must/Should/Could/Won't，含排序理由）
- 迭代规划建议（Sprint安排、依赖关系、风险提示）

**质量门检查**（自动执行）:
```markdown
🚦 质量门检查

检查项1: Must Have占比是否≤60%？
- 当前: [X]% → [✅通过 / ⚠️警告]

检查项2: 有无≥3个<70分故事？
- 当前: [n]个 → [✅通过 / ⚠️需优化]

检查项3: 整体平均分是否≥75？
- 当前: [X]分 → [✅通过 / ⚠️需优化]

**质量门结果**: [✅全部通过 / ⚠️建议优化 / ❌必须优化]
```

**检查点**:
```markdown
✅ INVEST评估完成

**评估统计**:
- 通过（≥85分）: [n]个
- 需改进（70-84分）: [n]个
- 需重写（<70分）: [n]个

**质量门**: [✅通过 / ⚠️建议优化 / ❌必须优化]

**下一步**: 进入优化决策（步骤6）
```

---

### 步骤6: 优化决策（人机交互点）

**决策模式配置**:

#### 模式1: 自动决策（默认）

```markdown
🤖 自动决策模式

根据评估结果自动决策：
- 有≥3个<70分故事 → 自动进入优化
- 所有故事≥85分 → 自动跳过优化
- 其他情况 → 询问用户意见
```

**自动决策逻辑**:
```python
if 评估结果中<70分故事数 >= 3:
    决策 = "全量优化"
    原因 = "发现{n}个需重写故事，建议重新生成"
elif 所有故事评分 >= 85:
    决策 = "跳过优化"
    原因 = "故事质量良好，直接进入验收标准生成"
else:
    # 询问用户
    展示决策界面()
```

#### 模式2: 始终询问用户

```markdown
👤 人工决策模式

无论评分如何，都询问用户意见。
适用于用户希望完全掌控流程的场景。
```

**决策界面**:
```markdown
🤔 优化决策

📊 INVEST评估结果：
- 通过（≥85分）: [n]个
- 需改进（70-84分）: [n]个
- 需重写（<70分）: [n]个
- 平均分: [X]分

💡 建议: [基于质量门结果的建议]

**请选择处理方式**:
A. 全量优化（重新生成所有故事，推荐用于有3个以上<70分故事）
B. 局部优化（仅优化指定故事，请提供ID列表，如: US003,US007,US012）
C. 跳过优化（直接进入验收标准生成，适用于整体质量良好）

请输入选项（A/B/C）或直接输入故事ID列表：
```

**处理逻辑**:
- 选项A → 返回步骤4，携带评估报告中的改进建议
- 选项B → 局部优化指定故事，其他保持不变
- 选项C → 进入步骤7（验收标准生成）

**检查点**:
```markdown
✅ 优化决策完成

**决策**: [全量优化/局部优化/跳过优化]
**理由**: [决策理由]

**下一步**: 
- 全量优化 → 返回步骤4
- 局部优化 → 重写指定故事后进入步骤7
- 跳过优化 → 进入步骤7
```

---

### 步骤7: 生成验收标准

**适用条件**: 所有需求层次（Epic/Feature/Story）。

**执行方式**: 
```markdown
我将读取 references/05-acceptance-criteria.md 执行验收标准生成。
```

**输出内容**:
- 验收标准总览（每个故事的验收标准数量、覆盖度）
- 详细验收标准（按故事分组）
  - Given-When-Then场景
  - 功能验收点
  - 非功能验收点
  - 测试用例设计
  - 验收流程

**最终检查点**:
```markdown
🎉 需求分析完成！

**产出清单**:
- ✅ 需求澄清报告
- ✅ Epic分析报告（如适用）
- ✅ 用户故事列表（[N]个）
- ✅ INVEST评估报告
- ✅ 验收标准文档

**关键指标**:
- 故事平均分: [X]分
- Must Have数量: [n]个
- 预估迭代数: [N]个

**建议下一步行动**:
1. 组织需求评审会议
2. 与技术团队进行迭代规划
3. 开始原型设计或技术方案设计
```

---

## 学习记忆机制

### 用户偏好记录

**第一次使用后自动记录**:
```markdown
📚 用户偏好已记录

**分析偏好**:
- 拆解维度倾向: [按角色/按功能/按场景]
- 故事粒度倾向: [偏大/适中/偏小]
- 优化决策模式: [自动/人工]
- Must Have占比偏好: [严格≤50% / 适中≤60% / 宽松≤70%]

**领域专长**:
- 熟悉的行业: [对外贸易/公共安全/金融科技/...]
- 常用合规标准: [等保三级/ISO27001/...]

这些偏好将在后续分析中自动应用，减少重复询问。
随时说"查看偏好设置"或"更新偏好"来管理。
```

**后续使用时应用偏好**:
```markdown
💡 根据您的偏好设置：
- 使用"按角色拆解"策略
- 目标故事粒度为"适中"（3-5天工作量）
- 优化决策采用"自动模式"
- Must Have占比控制在≤60%

如需调整，请告知。
```

### 偏好管理命令

- `查看偏好设置` - 显示当前记录的所有偏好
- `更新偏好: [维度]=[值]` - 更新特定偏好
- `重置偏好` - 清除所有记录的偏好
- `导出偏好` - 生成偏好配置代码（可分享给团队）

---

## 断点续传机制

### 获取续传码

每个检查点会自动生成续传码：

```markdown
📌 续传码

CHECKPOINT:agile-req-analyzer:step4:2026-01-03:abc123def456
当前状态: 已完成用户故事生成，待执行INVEST评估
上下文摘要: Epic[智能客服系统], 生成22个用户故事, 涉及3个角色

保存此续传码，可在新对话中继续分析。
```

### 使用续传码

在新对话中：
```markdown
继续分析，续传码：CHECKPOINT:agile-req-analyzer:step4:2026-01-03:abc123def456
```

Skill会：
1. 解析续传码，识别中断位置
2. 恢复上下文（Epic名称、故事列表等核心信息）
3. 从上次中断的步骤继续执行

**注意**: 续传码有效期建议≤7天，超期可能需要重新分析。

---

## 输出格式规范

### 标准化输出模板

所有步骤输出都遵循以下结构：

```markdown
# [步骤名称]输出报告

> **生成时间**: [YYYY-MM-DD HH:MM]
> **需求名称**: [Epic/Feature/Story名称]
> **输入来源**: [上一步骤或用户输入]
> **置信度**: [High/Medium/Low]

---

## 📊 执行摘要

[一段话概括本步骤的核心产出和关键发现]

---

## 📋 详细内容

[具体输出内容，遵循对应提示词的格式要求]

---

## ✅ 检查点

**已完成**:
- [X] [关键产出1]
- [X] [关键产出2]
- [X] [关键产出3]

**关键信息传递**:
- [传递给下一步的核心信息，如用户角色、故事数量等]

**质量指标**:
- [如适用，输出质量评分或检查结果]

**下一步**:
- [下一步操作和预计耗时]

**续传码**: [如适用]
```

### Markdown格式要求

- **标题层级**: 按#、##、###严格分级，不跳级
- **表格**: 用于结构化数据展示（评估矩阵、角色列表等）
- **列表**: 用于要点罗列（功能点、风险点等）
- **引用块**: 用于用户故事标准格式、重要提示
- **代码块**: 用于示例代码、命令行指令
- **Emoji**: 增强可读性
  - 🔴 P0/Must Have
  - 🟡 P1/Should Have
  - 🟢 P2/Could Have
  - ✅ 通过/完成
  - ⚠️ 警告/需改进
  - ❌ 不通过/问题

---

## 常见场景处理

### 场景1: Epic级需求（完整流程）

**触发条件**: 步骤2判断为Epic级别。

**典型示例**:
```
原始需求：开发一个智能客服系统，支持多渠道接入、智能问答、工单管理、
数据分析等功能，服务客户、客服人员、运营经理等多个角色。
```

**执行流程**: 步骤1→2→3→4→5→6→7（完整6步）

**预计时间**: 
- 步骤1（需求澄清）: 10-15分钟
- 步骤2（层次判断）: 1分钟
- 步骤3（Epic分析）: 5-8分钟
- 步骤4（故事生成）: 10-15分钟
- 步骤5（INVEST评估）: 8-12分钟
- 步骤6（优化决策）: 0-10分钟（取决于是否优化）
- 步骤7（验收标准）: 10-15分钟
- **总计**: 45-75分钟

---

### 场景2: Feature级需求（简化流程）

**触发条件**: 步骤2判断为Feature级别。

**典型示例**:
```
原始需求：为智能客服系统增加"客户满意度评价"功能，客户完成咨询后
可以进行星级评价和文字反馈。
```

**执行流程**: 步骤1→2→简化版步骤4→步骤7（3步）

**简化说明**:
- 跳过Epic分析（无需拆解策略）
- 简化用户故事生成（3-8个故事）
- 跳过INVEST评估（质量要求相对宽松）

**预计时间**: 15-25分钟

---

### 场景3: Story级需求（快速流程）

**触发条件**: 步骤2判断为Story级别。

**典型示例**:
```
原始需求：作为客户，我希望能通过手机号快速登录系统，以便快速访问我的咨询记录。
```

**执行流程**: 步骤1→2→步骤7（2步）

**快速通道说明**:
- 跳过Epic分析和用户故事生成
- 直接基于原始Story生成验收标准
- 重点补充非功能需求和边界条件

**预计时间**: 8-12分钟

---

### 场景4: 信息不足，基于假设继续

**触发条件**: 步骤1识别出≥5个P0问题，用户选择"基于假设继续"。

**处理方式**:
```markdown
⚠️ 基于假设模式

您选择了基于假设继续分析。以下假设已应用：

**假设1**: [假设内容]
- 依据: [行业最佳实践/竞品分析]
- 风险: [如果假设错误的后果]
- 建议澄清时间: [需求评审前/原型设计前]

**假设2**: [假设内容]
...

所有基于假设的分析结果将标注"⚠️假设"，方便后续追溯。
```

**输出标注**:
```markdown
## 用户角色分析

| 角色 | 描述 | 核心诉求 |
|------|------|----------|
| 客户 | 终端用户 | 快速获得问题解答 |
| 客服人员 | ⚠️假设 一线服务人员 | 高效处理咨询 |
```

---

## 技巧与最佳实践

### 最佳实践1: 先粗后细

第一次分析时：
- 步骤1采用"快速澄清"模式（只关注P0问题）
- 步骤4生成较粗粒度的故事（M/L级为主）
- 第一轮迭代规划后，再细化故事

### 最佳实践2: 增量细化

对于大型Epic：
- 第一次只拆分Must Have部分（MVP）
- 完成MVP后，再拆分Should Have和Could Have
- 避免一次性生成过多故事导致难以管理

### 最佳实践3: 团队协作

- 步骤1的澄清问题清单可发给客户预先准备答案
- 步骤3的Epic分析结果可作为需求评审会议材料
- 步骤5的INVEST评估可作为团队估算会议输入

### 最佳实践4: 迭代优化

- 第一个Epic分析后，查看"用户偏好"，确认是否符合团队习惯
- 调整偏好后，后续分析会更贴合团队实际情况
- 定期（每月）导出偏好，分享给团队成员

---

## 参考资源

### 详细提示词模板（按需加载）

本Skill包含5个详细的RTGO提示词模板，存储在`references/`目录：

1. **01-requirement-clarification.md** - 需求澄清提示词
   - 何时读取: 执行步骤1时
   - 内容: 6大维度澄清问题模板、P0/P1/P2分级标准

2. **02-epic-analysis.md** - Epic分析提示词
   - 何时读取: 执行步骤3时
   - 内容: Epic概述分析、用户角色分析、拆解策略、依赖风险

3. **03-user-story-generation.md** - 用户故事生成提示词
   - 何时读取: 执行步骤4时
   - 内容: 用户故事格式、编写模式、粒度控制、常见错误

4. **04-invest-evaluation.md** - INVEST评估提示词
   - 何时读取: 执行步骤5时
   - 内容: INVEST六维度评估标准、MoSCoW排序、迭代规划

5. **05-acceptance-criteria.md** - 验收标准生成提示词
   - 何时读取: 执行步骤7时
   - 内容: Given-When-Then场景、测试用例、验收流程

### 完整工作流参考

- **workflow-guide.md** - 完整工作流详解
  - 何时读取: 用户询问"完整流程说明"或"工作流详解"时
  - 内容: 6步流程详细说明、决策树、输出示例、FAQ

**注意**: 这些reference文件只在需要时才读取到上下文，保持SKILL.md简洁。

---

## 常见问题

**Q1: 如何判断需求是Epic还是Feature？**

A1: 参考步骤2的判断标准表格。关键看3点：
- 涉及多少个用户角色？（多个→Epic，单一→Feature/Story）
- 跨越多少个业务阶段？（多个→Epic，单一→Feature/Story）
- 能否在1个月内完成？（不能→Epic，能→Feature/Story）

**Q2: INVEST评估不通过怎么办？**

A2: 步骤6会自动或询问是否优化。建议：
- ≥3个<70分故事 → 选择"全量优化"
- 1-2个<70分故事 → 选择"局部优化"
- 所有故事≥70分但有优化建议 → 根据项目时间决定

**Q3: 可以跳过某些步骤吗？**

A3: 可以，但不建议。最低要求：
- Epic级别：至少执行步骤1、4、7
- Feature级别：至少执行步骤1、7
- Story级别：至少执行步骤7

**Q4: 如何处理多个Epic？**

A4: 两种方式：
- 方式1: 逐个分析（推荐，更深入）
- 方式2: 先对所有Epic执行步骤1-3，再挑选优先级最高的Epic完成步骤4-7

**Q5: 生成的文档可以直接导入Jira吗？**

A5: 当前版本输出Markdown格式。转换为Jira格式方法：
- 使用Jira的Markdown导入功能
- 或手动复制用户故事到Jira（Story格式已符合Jira标准）

**Q6: 如何更新已生成的用户故事？**

A6: 两种方式：
- 方式1: 使用"优化用户故事: US001,US003"命令
- 方式2: 重新执行步骤4（会保留已优化的故事）

---

## 版本与更新

**当前版本**: v1.0  
**发布日期**: 2026年1月3日  
**兼容提示词版本**: V2.0 (2025年11月16日)

**更新日志**:
- v1.0 (2026-01-03): 初始版本
  - 6步完整工作流
  - 3种需求层次支持（Epic/Feature/Story）
  - 学习记忆机制
  - 断点续传功能
  - 自动质量门检查

---

**使用提示**: 直接提供原始需求即可启动分析，Skill会自动引导完成整个流程！