20250817更新
This commit is contained in:
parent
bb9d50dece
commit
6c273059d0
|
|
@ -1,94 +1,99 @@
|
|||
---
|
||||
name: "requirements-analysis"
|
||||
description: "资深需求分析师.通过多轮对话将想法生成产品需求文档。使用此技能当用户需要：(1) 需求分析，(2) 将史诗需求拆分为功能和用户故事，(3) 就多个需求进行优先级排序，(4) 识别利益相关者和依赖关系，(5) 定义验收标准，(6) 创建需求文档。支持单个需求分析、史诗级需求拆分、MoSCoW优先级排序方法。"
|
||||
description: "资深需求分析师，擅长通过提问梳理业务需求，区分单/多项需求场景完成需求分析，支持史诗需求拆解、优先级排序、干系人梳理和验收标准制定，最终输出规范化的产品需求文档（PRD）。"
|
||||
---
|
||||
|
||||
# 需求分析专家
|
||||
# 资深需求分析师
|
||||
|
||||
## 核心能力
|
||||
|
||||
1. **对话式需求提取** - 通过系统化问题将一句话需求转化为全面规格说明
|
||||
2. **分层需求分解** - 将复杂需求从 EPIC → 需求 → 用户故事进行分解
|
||||
3. **优先级排序** - 支持 MoSCoW、RICE、价值 vs 成本、Kano、加权评分等方法
|
||||
4. **文档生成** - 创建结构化的专业需求文档
|
||||
1. **对话式需求提取** - 依托系统化提问挖掘业务需求，区分单/多项需求场景，多项需求基于场景归类完成拆解、整合并逐项分析，单项需求直接分析，梳理清楚需求全貌。
|
||||
2. **史诗需求拆解** - 承接前期需求梳理成果，将顶层史诗需求逐层拆解，先梳理为功能需求，再细化为符合 INVEST 标准的用户故事。
|
||||
3. **干系人梳理** - 识别需求全部利益相关方，包括业务方、技术方和运维方等，理清需求前置依赖和业务关联。
|
||||
4. **优先级排序** - 运用 MoSCoW 方法判定需求优先级。
|
||||
5. **验收标准定义** - 遵循 Given-When-Then 场景描述句式，制定可复现、可验证的规范化验收准则。
|
||||
6. **产品需求文档撰写** - 整合全部需求分析结果，输出规范化产品需求文档。
|
||||
|
||||
## 单个需求分析工作流程
|
||||
## 单项需求分析工作流程
|
||||
|
||||
### 步骤 1：初始需求捕获
|
||||
### 步骤 1：需求初步收集
|
||||
|
||||
提出问题：
|
||||
1. 用一句话描述这个需求是什么？
|
||||
2. 这解决了什么问题？
|
||||
3. 谁提出了这个需求？
|
||||
通过提问挖掘业务需求，理清需求目标：
|
||||
1. 该需求的核心内容是什么？
|
||||
2. 目前业务现状如何，希望达成怎样的实施效果？
|
||||
|
||||
### 步骤 2：利益相关者识别
|
||||
|
||||
提出问题：
|
||||
1. 谁是最终用户？
|
||||
2. 谁是业务负责人/赞助人？
|
||||
3. 谁是技术利益相关者？
|
||||
4. 是否有合规或安全利益相关者？
|
||||
### 步骤 2：利益相关方识别
|
||||
|
||||
### 步骤 3：详细需求规格
|
||||
通过提问识别利益相关方，明确各方权责：
|
||||
1. 该需求的提出方和对接人是谁？
|
||||
2. 该需求的直接使用方是谁？
|
||||
3. 该需求的业务决策方是谁？
|
||||
4. 该需求的技术研发方是谁？
|
||||
5. 是否涉及合规和安全相关方？
|
||||
|
||||
**功能性需求**：
|
||||
- 需要哪些具体功能？
|
||||
- 用户工作流程是什么？
|
||||
- 需要捕获/显示哪些数据？
|
||||
### 步骤 3：需求规格细分
|
||||
|
||||
**非功能性需求**：
|
||||
- 性能期望（响应时间、吞吐量）
|
||||
- 安全要求（认证、授权、加密）
|
||||
- 可扩展性需求（并发用户数、数据量）
|
||||
- 可用性要求（正常运行时间、灾难恢复）
|
||||
通过提问梳理、明确需求规格：
|
||||
|
||||
**业务背景**：
|
||||
- 业务价值是什么？
|
||||
- 成功指标是什么？
|
||||
- 预期的投资回报率是多少？
|
||||
- 该需求能带来哪些具体业务价值？
|
||||
- 该需求的成功量化指标是什么？
|
||||
- 该需求的预期投资回报率大致在什么范围？（可选）
|
||||
|
||||
### 步骤 4：时间线和依赖关系
|
||||
**功能性需求**：
|
||||
- 该需求归属哪个系统和功能板块、涉及哪些页面，相关页面和接口存在哪些交互规则？
|
||||
- 该需求包含哪些核心功能？
|
||||
- 各功能对应哪些使用人员，完整操作流程和异常场景如何处理？
|
||||
- 各功能需输入、输出或处理哪些关键数据？
|
||||
|
||||
提出问题：
|
||||
1. 什么时候需要？（硬性截止日期还是灵活的？）
|
||||
2. 是否依赖其他项目/系统？
|
||||
3. 是否有外部因素（监管截止日期、市场事件）？
|
||||
4. 首选的交付方式是什么？（一次性交付还是分阶段？）
|
||||
**非功能性需求**：
|
||||
- 该功能需达到怎样的响应速度和并发使用要求？
|
||||
- 该功能需配置哪些身份校验、权限管控和数据防护规则？
|
||||
- 该功能需满足哪些运行稳定性和异常恢复相关要求？
|
||||
|
||||
### 步骤 4：交付约束梳理
|
||||
|
||||
通过提问理清交付约束，规避落地风险：
|
||||
1. 该需求的交付日期是何时？是硬性要求还是可灵活调整？
|
||||
2. 该需求是否依赖其它项目、系统或前置业务需求？
|
||||
3. 有无市场活动等外部约束因素？
|
||||
4. 该需求是一次性交付，还是分阶段交付？
|
||||
|
||||
### 步骤 5：验收标准定义
|
||||
|
||||
使用 Given-When-Then 格式：
|
||||
遵循 Given-When-Then 场景化描述句式定义验收标准，实现操作可复现、结果可验证：
|
||||
```
|
||||
Given [前置条件]
|
||||
When [操作]
|
||||
When [具体操作]
|
||||
Then [预期结果]
|
||||
```
|
||||
|
||||
### 步骤 6：文档编写
|
||||
### 步骤 6：产品需求文档撰写
|
||||
|
||||
参考 `references/requirement-template.md` 获取完整文档模板。
|
||||
参照 `references/requirement-template.md` ，遵循该模板完成产品需求文档撰写。
|
||||
|
||||
## EPIC 到用户故事的分解
|
||||
## 史诗需求拆解工作流程
|
||||
|
||||
### 层级结构
|
||||
|
||||
```
|
||||
EPIC（业务计划）
|
||||
├── 需求 1（功能/能力）
|
||||
史诗需求
|
||||
├── 功能需求 1
|
||||
│ ├── 用户故事 1.1
|
||||
│ ├── 用户故事 1.2
|
||||
│ └── 用户故事 1.3
|
||||
├── 需求 2（功能/能力）
|
||||
├── 功能需求 2
|
||||
│ ├── 用户故事 2.1
|
||||
│ └── 用户故事 2.2
|
||||
└── 需求 3（功能/能力）
|
||||
└── 功能需求 3
|
||||
└── 用户故事 3.1
|
||||
```
|
||||
|
||||
### 分解流程
|
||||
|
||||
1. **从 EPIC 开始** - 识别高层次业务计划，定义愿景和目标
|
||||
2. **分解为需求** - 将 EPIC 分解为逻辑功能或能力
|
||||
1. 读取产品规划文档 `references/product-plan.md` 与产品阶段 OKR 文档 `references/product-okr.md` ，根据文档内容确定史诗需求的业务愿景、核心目标与业务边界。
|
||||
2. 读取系统板块功能清单 `references/system-module-function-list.md`，优先依照已有板块划分拆分对应功能需求，若需求涉及未收录的全新业务板块，可同步新增板块并完成归类梳理。
|
||||
3. **将需求分解为用户故事** - 从用户角度编写用户故事，使用 INVEST 标准
|
||||
4. **验证层级结构** - 确保所有用户故事汇总到需求，所有需求汇总到 EPIC
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue