Requirement decomposition

需求拆解

将模糊、宏大的需求转化为一连串具体、可执行、可验证的小任务。

核心框架：三步递进

澄清需求 → 拆解需求 → 验证需求

---

第一步：澄清需求

目标：确保完全理解需求本质，而非表面方案。

1.1 统一语言

与业务方对齐关键术语：

• 确认核心实体的属性（如"订单"包含：订单号、商品、总价、状态）
• 确认业务规则和边界条件

1.2 挖掘真实动机（5W2H法）

维度	问题
Why	为什么做？解决什么问题？
Who	谁会用？直接/间接用户？
What	核心问题是什么？
Where	在哪里用？环境特点？
When	什么时候用？频率？
How	期望怎么做？

1.3 定义具体目标

将模糊目标转化为可量化指标：

模糊目标	具体目标
提升点单效率	平均每单点单时间缩短至1分钟以内，错误率降低到5%以下

---

第二步：拆解需求

目标：将需求分层拆解为可开发的用户故事和具体任务。

层级1：特性 → 用户故事

按核心流程或功能模块拆分，用户故事格式：

"作为<角色>，我想要<活动>，以便于<商业价值>"

层级2：用户故事 → 任务

将每个用户故事拆分为具体技术任务：

任务类型	示例
前端任务	UI设计、组件开发、交互实现
后端任务	数据模型、API接口、业务逻辑
测试任务	测试用例编写、功能验证

拆解技巧

• 按工作流拆分：如"点单 → 支付 → 出餐"
• 按功能模块拆分：如"商品管理"、"订单管理"、"会员管理"
• 按技术架构拆分：前端界面、后端逻辑、数据库设计
• 按操作类型拆分：增、删、改、查

---

第三步：验证需求

目标：与需求方确认理解一致，避免后续返工。

3.1 定义验收标准（DoD）

使用 Given-When-Then 格式：

Given  前置条件
When   操作行为
Then   预期结果

示例：

• Given 店员已选择了一杯"珍珠奶茶"
• When 店员增加了"珍珠"配料并选择"无糖"
• Then 系统应显示"珍珠奶茶(无糖, +珍珠)"，总价增加1元

3.2 反向串讲

拿着原型图或流程图，让需求方扮演用户模拟操作，提前发现理解偏差。

3.3 例外情况测试

主动思考异常流程：

• 顾客在支付前想取消订单怎么办？
• 某个配料卖完了，界面如何显示？
• 打印小票时没纸了，系统如何提示？

---

使用场景

当用户提供模糊需求时，主动调用此skill进行需求拆解：

1. 用户说"帮我做一个商城系统"
2. 用户说"需要一个项目管理工具"
3. 用户说"开发一个社交App"
4. 用户的需求过于笼统，需要具体化

输出格式

完成拆解后，输出以下结构化内容：

## 需求澄清
- 核心目标：...
- 关键术语：...
- 5W2H分析：...

## 拆解结果
### 特性1：...
- 用户故事：...
- 任务列表：...

### 特性2：...
...

## 验收标准
- 用户故事1的DoD：...
- 用户故事2的DoD：...
...